Free tool · No sign-up
Screen reader simulator: what does your page announce?
Enter a page address and get a transcript of what a screen reader would come across, line by line in reading order, plus the lists of headings, landmarks, links and controls that screen reader users jump around with. Missing names, vague links and skipped headings are flagged.
It is a preview built from Chrome's accessibility tree, the same data screen readers start from. It is not NVDA, JAWS, VoiceOver or TalkBack, which phrase things differently and have behaviour of their own. Use it to find problems fast, then test with a real screen reader.
How the preview is made
Browsers build an accessibility tree for every page: each element's role (heading, link, button), its accessible name, and its states, such as expanded, checked or required. Screen readers read that tree through the operating system and then decide for themselves how to present it.
This tool loads your page in headless Chrome, waits for it to settle, scrolls it so lazy sections load, and reads the full tree through the Chrome DevTools Protocol. It then walks the tree in reading order and writes one line per stop in plain wording: “heading level 2, Pricing”, “link, Contact us”, “edit, Email, required”, “list, 5 items”, and the start and end of each landmark. Text that a link or button already uses as its name is not read twice, and a label next to the field it names is not repeated.
Reading order is the order of the tree, which follows the page source. Content that CSS moves around visually still reads in source order here, as it does for screen reader users, which is often where a confusing page comes from.
What it cannot tell you is how a particular product will sound, or whether the page works when you use it. The screen reader testing guide covers how to check a page with NVDA, JAWS, VoiceOver and TalkBack.
What gets flagged
| List | Flagged | WCAG |
|---|---|---|
| Headings | No level 1 heading, empty headings, and skipped levels such as h2 to h4. More than one h1 is noted but not counted as a problem. | 1.3.1, 2.4.6 |
| Landmarks | No main landmark, more than one main, and several navigation landmarks with no names to tell them apart. | 1.3.1 |
| Links | No accessible name, a web address used as the text, vague text such as "click here" or "read more", and the same text going to different places. | 2.4.4, 4.1.2 |
| Form fields | Fields with no accessible name. | 4.1.2 |
| Buttons | Buttons with no accessible name. | 4.1.2 |
| Images | Images with no text alternative that are not marked decorative. An unnamed icon inside a named link or button is not flagged. | 1.1.1 |
The criteria are 1.3.1 Info and Relationships, 2.4.4 Link Purpose (In Context), 2.4.6 Headings and Labels and 4.1.2 Name, Role, Value, with 1.1.1 Non-text Contentfor images. A flag is a lead to check, not a verdict: whether a heading describes its section, or a link's context makes its purpose clear, still needs a person.
Limits worth knowing
- Content inside iframes is not included. Each frame is listed with its title so you can check it separately.
- Images, video and audio files are not downloaded. Text alternatives still come through; media players show without their own controls.
- The page is read as it loads. Menus, dialogs and tabs that need a click are read in their closed state, and nothing is typed or submitted.
- Live region announcements, focus changes and descriptions linked with aria-describedby are not read out.
- Pages behind a sign-in, and sites that block automated browsers, cannot be checked.
- The transcript stops at about 1,500 lines on very long pages. The lists of headings, landmarks, links and controls still cover the whole page.
Frequently Asked Questions
Is this the same as using NVDA, JAWS, VoiceOver or TalkBack?
No. It is a preview built from Chrome's accessibility tree, the same data screen readers start from, written out in plain wording. NVDA, JAWS, VoiceOver and TalkBack each phrase roles and states their own way, decide for themselves what to read in browse mode, and have their own settings for punctuation, verbosity and tables. VoiceOver usually runs with Safari, whose tree differs from Chrome's in places. Use the preview to find problems quickly, then confirm them with a real screen reader.
Where does the transcript come from?
We load the page in headless Chrome, scroll it so lazy sections load, and read the full accessibility tree through the Chrome DevTools Protocol. That tree holds each element's role, accessible name and states, which is what Chrome passes to screen readers through the operating system. The tool walks it in reading order and writes one line per stop, for example 'heading level 2, Pricing' or 'button, Menu, collapsed'.
Why is something I can see on the page missing from the transcript?
Usually because it is hidden from assistive technology, with aria-hidden or a role of presentation, or because it is a CSS background image. Content inside an iframe is not included, and anything that only appears after a click, such as a closed menu or an unopened tab, is read in its closed state. If visible text is missing and it is not in a frame, look for aria-hidden on it or on a parent.
Why does every line of a card start with 'link'?
When one link wraps a heading, a summary and a date, screen readers read each part as part of that link, so every line of it is marked as link. The heading still appears in the headings list. A link that only wraps text is announced once, with its name, and the text inside it is not read again.
Does link text such as 'read more' always fail WCAG?
Not always. 2.4.4 Link Purpose (In Context), Level A, allows the purpose to come from the sentence, list item, table cell or heading around the link. It is flagged because screen reader users often move through a list of links, where that context is gone and the list reads 'read more, read more, read more'. 2.4.9 Link Purpose (Link Only), Level AAA, needs the link text to make sense on its own.
Will the speech clash with my own screen reader?
It should not. Speech uses your browser's built-in voices and only starts when you press Play. The transcript is not a live region, so your screen reader does not also read each line as it is spoken. When you move the virtual cursor with the buttons, the new line is announced once. If you already use a screen reader, the buttons are usually the better way through.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences