How a screen reader reads a web page

A screen reader is software that presents a page as speech or braille. W3C describes screen readers as tools that can read the information on the screen out loud or present it in braille (how people with visual disabilities use the web). That makes the code the interface: visual styling alone does not tell a screen reader what something is, and a heading that is only bold text is not a heading to the listener. For the wider picture, start with what web accessibility is.

From markup to speech

Browsers convert markup into the DOM tree, then build an accessibility tree from it, which platform accessibility APIs pass to assistive technologies such as screen readers (MDN's accessibility tree entry). Each object in the tree has four properties: a name (what to call it), a description, a role (what kind of thing it is) and a state, such as checked or collapsed. A link whose text is "Pricing plans" has the name "Pricing plans" and the role link.

Native HTML fills in the tree for you. The HTML Accessibility API Mappings specification maps h1 to h6 to the heading role, an a element with an href to the link role and button to the button role. An a element with no href maps to the generic role, which says nothing about being a link, and an img with an empty alt maps to the none or presentation role, so it is left out of the speech.

Information carried only by styling does not reach the tree. WCAG 1.3.1 Info and Relationships asks that information, structure and relationships conveyed through presentation can be programmatically determined or are available in text (W3C's Understanding page). And a control can look perfect and still reach the tree as plain text, as the last row shows.

In what order does a screen reader read a page?

In the order of the code. WebAIM notes that audio interfaces present content linearly, one item at a time, so the sequence in the code is the sequence a listener gets. CSS can move a sidebar or a price somewhere else on screen without changing the sequence in the source, and a screen reader generally follows the source. WCAG 1.3.2 Meaningful Sequence asks that when order affects meaning, a correct sequence can be determined by software.

Two details shape what a listener hears first. Screen readers announce the page title when a page loads, so a clear page title is what a listener hears on arrival. The lang attribute on the html element tells the screen reader which language to speak, because every language has its own pronunciation rules (WebAIM; see the lang attribute guide).

How people move through a page

Many listeners do not start at the top and wait. In WebAIM's Screen Reader User Survey #11, the most common first move on a lengthy page was to navigate through the headings, and 51.9% of respondents found heading levels very useful and 36.4% somewhat useful. WebAIM notes its sample was not controlled, so these are respondents' reports, not a count of all users.

Screen readers make this fast with single keys. In NVDA's browse mode, these keys jump to the next element of a type, and adding Shift jumps to the previous one (NVDA user guide; WebAIM's NVDA guide).

VoiceOver, built into Mac, iPhone and iPad, does the same job with a different interface. On a Mac, its web rotor opens with VO+U and lists element types such as headings and links, and VO+Command+H and VO+Command+L jump to the next heading and link (WebAIM's VoiceOver guide). TalkBack is Google's screen reader for Android. In WebAIM's survey, JAWS and NVDA were the two most used primary desktop screen readers, followed by VoiceOver, and WebAIM advises building to accessibility standards and generally accepted techniques, because differences between screen readers do not typically change coding practices. A skip link lets a listener pass the repeated header and menu.

Browse mode and focus mode

Reading a page and typing into a form need different keystrokes, so NVDA has two modes. In browse mode, which NVDA uses for web pages, the page is a flat representation you move through with the cursor keys as if it were a normal text document, plus single letters such as H. In focus mode, almost every key goes straight to the control, so typing works. NVDA switches to focus mode when you Tab or click to a control that needs it, switches back when you Tab or click to one that does not, and Escape switches back to browse mode if focus mode was switched to automatically (NVDA user guide).

A custom widget has to tell the truth about itself, because the screen reader works from what each control exposes. WCAG 4.1.2 Name, Role, Value asks that the name and role of every interface component, including components generated by scripts, can be determined by software (W3C's Understanding page). The ARIA basics guide covers adding that information when native HTML cannot.

What a screen reader skips, and what it reads that you cannot see

• Images with an empty alt. W3C says decorative images should get a null alt so assistive technology can ignore them, and that when the attribute is not provided, some screen readers announce the file name of the image instead (W3C: decorative images). See our decorative images guide.
• Images that carry meaning. The alt text is what gets read, and a linked image with no alt text is generally read by its link destination, or its file name (WebAIM). Alt text that is present but false is read just as confidently, so good alt text has to be true of the image.
• Hidden content. WebAIM says content hidden with display: none or visibility: hidden is ignored by screen readers, while text positioned off-screen is still read (invisible content). The ARIA specification defines aria-hidden as indicating whether an element is exposed to an accessibility API and warns to use extreme caution when hiding visible content (WAI-ARIA 1.2). A hidden element that can still take focus is a trap: see aria-hidden and focusable elements.
• Data tables. With correct markup, screen readers read the column or row heading as the user enters each cell (WebAIM). See accessible data tables.

How a control gets its name

The name is what a listener hears for a link, a button or a field. The ARIA Authoring Practices Guide describes an accessible name as a short string, typically 1 to 3 words, that authors associate with an element, and says names convey what an element is for and tell it apart from others (APG, names and descriptions). The Accessible Name and Description Computation 1.2 specification sets the order a browser follows, in simplified form:

1. aria-labelledby, if present.
2. aria-label, if the name is still empty.
3. Native markup, such as the alt attribute or a label element.
4. The element's own content, for roles that allow it.
5. The tooltip attribute (title), only if nothing else has provided a name.

Links and buttons are named from their content: the WAI-ARIA 1.2 role list includes both among the roles that support name from content, and both require a name. So a link reading "Read more" is announced as "Read more", and an icon-only button with no text, label or alt is announced as a button with nothing to say about its purpose.

APG's rules of thumb: rely on HTML naming techniques where you can, prefer visible text for the name, and leave the role out of the name, because the screen reader already announces it. A navigation landmark labeled "Site Navigation" is announced as "Site Navigation Navigation" (APG, landmark regions).

Names matter for links in particular. WebAIM says users can obtain a list of the links on a page, arranged alphabetically, and that links should make sense when read out of context, so ten "Read more" links make a list of ten identical entries. See WCAG 2.4.4 Link Purpose for the criterion. Naming failures are common: the 2026 WebAIM Million, with data from February 2026, found empty links on 46.3% of home pages, empty buttons on 30.6% and missing form input labels on 51%.

Common faults and what they sound like

Unnamed links, buttons and fields are among the most common accessibility errors, and skipped heading levels were present on 41.8% of all pages in the same WebAIM Million.

Listen to your own page

NVDA is free and runs on Windows, and VoiceOver comes with Mac, iPhone and iPad. WebAIM suggests testing with default or minimally customized settings.

1. Set a comfortable speech rate. In NVDA, press NVDA+Ctrl+Up or Down arrow (WebAIM's NVDA guide).
2. Load the page and listen for the page title.
3. Press H repeatedly. Does the sequence of headings read like an outline of the page?
4. Press K repeatedly. Does each link say where it goes?
5. Press D, then Tab through the form fields. Are landmarks and field names clear?
6. Note every place that sounds like nothing, a bare "button" or "link", or the wrong order.

Listening is a check, not proof that a page meets WCAG or any law. Our guide to how to test website accessibility puts it beside the other checks, and the 5-minute keyboard test covers the keyboard side.

Check it yourself

These free tools find the structural problems that change what a screen reader says:

• Heading checker draws the outline a screen reader user navigates by and flags a missing H1, more than one H1, skipped levels and empty headings.
• Link text checker lists every link with the name a screen reader announces and flags links with no name, vague text, bare URLs and repeated text that goes to different places.
• Alt text checker judges whether alt text is true of the image, which matters because the screen reader reads it as fact.
• Accessibility bookmarklet checks the live page in your own browser, including headings added by script.
• Scan my site for free runs 16 rule-based checks on the HTML your server sends, including missing alt attributes and unnamed links, buttons and form fields.

None of them says how a page sounds. They find what could make it sound wrong.

Keep it checked

Hearing a page once tells you how it sounds today. A redesign or a template change can alter that next week. GotAlt checks the pages you monitor every week. It runs its rule checks, which include links and buttons with no accessible name and form fields with no label, compares the alt text of images with the images themselves (up to six per page), opens monitored pages in a browser for contrast and other checks that need a rendered page (see what we check), and reports what changed. Plans are from $69 a month: Audit my whole site from $69/mo. Automated checks cover part of WCAG, so listening to your key pages stays worth doing.