Fixing Screen Reader Problems on Your Website

Screen reader problems on a website almost always come from the code rather than from the screen reader. A screen reader announces the structure, names and states that the page exposes to the browser, so a heading styled as bold text, an image with no alternative text or a button made from a plain div reaches the listener as silence or noise. Each of those faults maps to a specific WCAG 2.2 success criterion, which makes them straightforward to find and fix once you know where to look. They are also among the first things checked in any programme of WCAG 2.2 AA accessibility for business websites.

The sections below cover seven common problems, from headings and alt text to ARIA misuse and content that changes without a page reload. Each one names the success criterion involved, describes what the listener hears and sets out the fix, followed by how to test the result with NVDA, VoiceOver and TalkBack and how to stop the problems returning.

How a Screen Reader Reads a Website

A screen reader reads a website in a straight line, one element at a time, using the code behind the page rather than its visual layout. WebAIM’s guide to designing for screen reader compatibility explains that audio interfaces present content linearly and that users speed this up by jumping between headings, landmarks, links and form controls.

That jumping is how experienced users move around a page, so the markup decides how quickly they can find anything. A page with no headings has to be read from the start, a list of links that all say “read more” gives no clue where each one goes and an unlabelled field is announced only by its type. The table below maps each common problem to its WCAG 2.2 success criterion and to what the listener hears.

Most of these failures sit at Level A, the lowest level of WCAG 2.2, so a website with any of them cannot meet Level AA either. Fixing them in the theme templates rather than page by page clears the problem on every page that uses the template.

Fix Headings That Do Not Describe the Page

Fix headings by using real heading elements in a logical order, with wording that describes the content beneath each one. The W3C explanation of Success Criterion 1.3.1 Info and Relationships requires structure that is shown visually, such as headings, lists and tables, to be available in the code as well, so a screen reader can present it when the visual formatting is gone.

The common faults are text styled to look like a heading without the heading tag, heading levels chosen for their font size and decorative text marked up as a heading. Screen readers announce the level of each heading, so a page that jumps from H2 to H5 or uses H1 for every section title presents a confusing outline. The wording matters too, because Success Criterion 2.4.6 Headings and Labels asks for headings that describe the topic or purpose of the content they introduce.

In WordPress the fix usually sits in two places. Theme templates should output one H1 per page with section headings at H2 and below, while editors should pick heading levels in the block editor by structure rather than by size, leaving the theme’s CSS to control how each level looks.

Write Alt Text That Matches the Image’s Purpose

Alt text should say what an image contributes to the page, while a purely decorative image should carry empty alt text so screen readers skip it. The W3C guidance on Success Criterion 1.1.1 Non-text Content requires a text alternative that serves the equivalent purpose for every image that carries information. Decorative images must be implemented so that assistive technology can ignore them.

The usual faults are missing alt attributes, file names used as alt text and alt text stuffed with keywords. An image with no alt attribute at all may be announced by its file name, depending on the listener’s settings, which tells them nothing useful. An image used as a link needs alt text that describes where the link goes, because that text becomes the name of the link.

WordPress stores alt text against each image in the media library, but the alt text that counts is the one printed on the page. Check that the theme outputs the alt field rather than the image title or caption. Images placed by custom templates need checking as well, since a template can print an empty alt attribute whatever the media library holds.

Give Every Link and Button a Clear Name

Every link and button needs an accessible name that says what it does, because screen reader users often hear links and buttons away from the text around them. The W3C explanation of Success Criterion 2.4.4 Link Purpose (In Context) notes that assistive technology can give users a list of the links on a page. Meaningful link text helps them choose from that list.

Ten links reading “read more” or “click here” are useless in that list, so the link text itself should name the destination, such as “read the hospital wayfinding case study”. Buttons built from icons alone, such as a magnifying glass for search or a cross that closes a menu, need a text name as well, provided by visually hidden text or an aria-label.

Custom controls are where many naming problems start. Success Criterion 4.1.2 Name, Role, Value requires every user interface component to expose its name and role to assistive technology. The same guidance notes that standard HTML controls already meet the requirement when used according to the specification, so a real button element is the simplest fix for a clickable div.

The visible label and the accessible name should also match. Success Criterion 2.5.3 Label in Name asks for the visible text of a control to form part of its accessible name, which matters for speech recognition users who say the label they can see. An aria-label that swaps “Get a quote” for “Submit enquiry form” breaks that link between what people see and what the code announces.

Connect Form Labels to Their Fields

Every form field needs a visible label that is connected to it in the code, so a screen reader announces the label when the field receives focus. The W3C guidance on Success Criterion 3.3.2 Labels or Instructions requires labels or instructions wherever content asks for input, while the connection between a label and its field in the code falls under Success Criterion 1.3.1.

Placeholder text is a common substitute for a label. It disappears once someone starts typing and is not a dependable name for the field, so the label should be a label element tied to the field’s id, or a fieldset with a legend for a group of radio buttons or checkboxes. When a field receives focus, a screen reader should announce each of the details below.

• The visible label, read as the name of the field
• The type of field, such as an edit field, checkbox or combo box
• Whether the field is required, set with the required attribute rather than shown by an asterisk alone
• Any hint about the format expected, linked to the field with aria-describedby
• The error message once validation fails, connected to the field rather than shown only in red

WordPress form plugins differ in how they print labels and error messages, so check the HTML each one produces rather than its settings screen. Our guide to designing accessible forms with clear labels and error messages covers labels, error handling and validation in more detail.

Add Landmarks So Users Can Jump Around the Page

Landmarks let screen reader users jump straight to the main content, menu, search or footer, so every page should wrap those regions in the matching HTML elements. The W3C ARIA Authoring Practices guide to landmark regions explains that screen readers use landmark roles to offer keyboard navigation to the important sections of a page. HTML elements such as header, nav, main and footer create those landmarks without any extra ARIA.

Repeated blocks such as the main menu are the other half of the problem. Success Criterion 2.4.1 Bypass Blocks requires a way to skip content that repeats across pages, which is usually met with a skip link to the main content alongside a main landmark. Where a page has two menus, such as a main menu and a footer menu, give each one a distinct label so the list of landmarks makes sense.

Landmarks are a quick fix on most WordPress themes because they live in the header, footer and page templates. One change to those files corrects every page, which makes this one of the fastest screen reader fixes to complete.

Stop ARIA From Hiding or Overriding Content

ARIA should only be added where HTML has no native element for the job, because incorrect ARIA overrides what the browser would otherwise announce correctly. The W3C ARIA Authoring Practices page No ARIA is better than Bad ARIA describes a role as a promise, so role="button" on a div also commits the author to building the keyboard behaviour a real button provides.

The faults that do most damage are aria-hidden="true" on content or controls people need, aria-label text that replaces useful visible text and roles that change the meaning of a native element. The same W3C page shows how an aria-label on a link means screen reader users hear only the label and never the link text. A role such as log on a table stops it being perceived as a table at all.

Removing bad ARIA often fixes more than adding new ARIA. When a component misbehaves in a screen reader, start by deleting roles and attributes that duplicate native HTML, then retest before adding anything back.

Announce Content That Changes Without a Page Reload

Content that changes without a page reload needs to be announced through a live region, or a screen reader user may never know it appeared. The W3C guidance on Success Criterion 4.1.3 Status Messages requires status messages to be identified in the code so assistive technology can present them without moving focus, with examples such as a search reporting how many results it returned.

Typical failures are a form that shows a thank you message without reloading, a basket count that updates silently and a filter that refreshes a product list with no confirmation. Each needs a short message in a container marked with role="status" for polite updates, or role="alert" for errors that need attention straight away. The container should be on the page before the message is inserted, because screen readers can miss text added to a region that did not exist when the page loaded.

Screen readers handle live regions in slightly different ways. Apple’s guide to moving around web pages using live regions explains that VoiceOver can detect them even when focus is elsewhere on the page and speak their content as it changes, so test each message in more than one screen reader.

How to Test With NVDA, VoiceOver and TalkBack

Test with at least one desktop and one mobile screen reader, completing the main tasks on the website without looking at the screen. GOV.UK guidance on testing with assistive technologies lists NVDA with Chrome, Firefox or Edge, VoiceOver on iOS with Safari and TalkBack with Chrome among the combinations a public service must work with, alongside JAWS.

The same guidance says to read every element and heading, tab through every link, check every landmark, check the use of ARIA and fill in and submit any forms. That list works as a test script for each template on the website, which covers far more ground than testing pages at random.

NVDA is a free and open source screen reader for Windows. Its user guide lists the single letter keys used in browse mode, such as H for the next heading, D for the next landmark, K for the next link and F for the next form field. Pressing the NVDA key with F7 opens the elements list of links, headings, form fields, buttons or landmarks, which is the quickest way to hear the outline of a page.

VoiceOver comes with macOS and starts when you press Command and F5, as Apple’s guide to turning VoiceOver on or off explains. The VoiceOver rotor opens when you press Control, Option and U together, then lists headings, links and landmarks in much the same way as the NVDA elements list.

TalkBack is the Google screen reader included on Android devices. Google’s help page on using TalkBack to browse the web with Chrome explains how to swipe down then up to choose a reading control such as headings, links or controls, then swipe down to move between them.

Testing in house catches many structural faults, but people who use a screen reader every day work faster and in different ways from someone switching one on for a test. The GOV.UK guidance also recommends including users of assistive technologies in user research. Any setup those participants bring will show how well the website works in practice.

Keeping Screen Reader Fixes in Place

Screen reader fixes stay in place when they are built into templates, components and editor training rather than applied page by page. New content is the usual route back in, since a single image uploaded without alt text or a heading picked for its size undoes the work on that page.

Automated checkers make a sensible first pass because they catch missing alt attributes, empty links and unlabelled fields across a whole website quickly. They cannot judge whether a name makes sense when read aloud, so manual testing with a screen reader and a keyboard still belongs in every release. Our guide to keyboard accessibility and how to test it covers the keyboard checks that run alongside screen reader testing.

Overlay widgets that promise to fix accessibility with a line of script do not repair the underlying markup, which is where screen reader problems live. The hidden dangers of accessibility overlays and plugins explain why fixing the code is the more reliable route. Visual checks belong in the same review, because people with low vision who read the screen rather than listen to it depend on colour contrast for accessibility instead.

Priority Pixels designs and develops all WordPress websites to WCAG 2.2 AA standard as a minimum, with a team that works inside axe, WAVE, screen readers and manual audit checklists. Whoever does the work, the test is the same, with every page making sense to someone who can only hear it.