Every guide ends with “listen to your page”. Here it is, written down.

The honest accessibility test is to turn a screen reader on and listen to your own site, and almost nobody does it — because it means installing NVDA, learning its keys, and sitting through forty minutes of your own header. So paste a page instead and read the transcript: every line a screen reader produces, in the order it is heard, with the ones that announce “button” and stop marked in place.

Free, instant, no signup and no card. We read the HTML your server sends, and nothing is stored.

Try your homepage first, then the page with a form on it — a checkout, a sign-up, a contact page. Free, instant, no signup and no card, and nothing is stored.

A report grouped by criterion is not what a listener experiences

Every automated accessibility tool — ours included — returns a list sorted by success criterion: four 1.1.1 findings, two 4.1.2, one 2.4.2. That is the right shape for an auditor filling in a VPAT and the wrong shape for understanding what is wrong, because nobody uses a website by criterion. They use it in order, one announcement after another, and a defect only matters in the place it lands.

“Four images are missing alt text” is abstract. Line 9: “graphic, hero-final-v2-compressed.png” is not — that is the export history of a design file, read out loud, in the position where the page was supposed to say what the picture shows. The transcript is the same information with the abstraction taken out, and it is the only view that shows you the thing an auditor cannot put in a report: how much of your page the listener gets through before anything useful is said.

What a broken reading sounds like

1   "Home | Acme Inc — Official Website of Acme Inc"
2   "banner landmark"
3   "link"                        <- the logo. An <a> with an <svg> in it.
4   "button"                      <- the menu. No name anywhere.
5   "navigation landmark"
6   "link, Products"
7   "link, Pricing"
8   "main landmark"
9   "heading level 1, Pricing"
10  "graphic, pricing-table-v3-FINAL.png"
11  "edit, blank"                 <- the coupon field. A placeholder only.
12  "button"                      <- the apply button. An icon.
13  "link, https://acme.com/terms-and-conditions-2026-v2"

Lines 3, 4, 11 and 12 are controls this person cannot use.
Nothing on the screen looks wrong. Nothing warns anybody.
Each of the four is one attribute.

Notice line 1. The title puts the company name twice and the page’s own name last, so a listener with six tabs open hears “Acme Inc” six times and learns nothing. And notice that lines 2 to 7 are the layout — they repeat exactly like this on every page of the site, which is why one unnamed icon in a shared header is one finding on this page and several hundred across the property.

What this reads, and what it deliberately does not

A button is read out as the word "button" and nothing else

Failure

WCAG 2.1 SC 4.1.2 Name, Role, Value (Level A)

A button in the transcript carries no text, no value, no aria-label and no aria-labelledby. It is announced as "button" — the role, and nothing about what pressing it would do. This is the single most common automated finding on the web and it is almost always an icon: a hamburger, a magnifying glass, a close X, a play triangle. The icon reads perfectly to anybody who can see it and is a blank to anybody who cannot.

The fix: Name it in one attribute: <button aria-label="Open menu">. Keep the name to what the control does rather than what the icon is — "Open menu", not "hamburger icon". If the SVG inside carries a <title>, that is not enough on its own; add aria-hidden="true" to the icon and name the button.

A link is read out as the word "link" and nothing else

Failure

WCAG 2.1 SC 2.4.4 Link Purpose (Level A) / SC 4.1.2 Name, Role, Value (Level A)

A link in the transcript has no text, no aria-label, no title and no image with alt text inside it — so the whole line is the word "link". A screen reader user pulling up the links list for this page gets a row they cannot tell apart from any other empty one, and there is nothing on it to decide by. The usual cause is an icon-only link: a social icon, a close button that is really an anchor, a card image wrapped in a link that already has its own text elsewhere.

The fix: Give it words. Either put visually hidden text inside it — <a href="/x"><svg aria-hidden="true">…</svg><span class="sr-only">Close</span></a> — or name it with aria-label="Close". If the link is a second copy of one that already has text, the better fix is to delete it and wrap the text link around both.

A form field is read out as "edit, blank"

Failure

WCAG 2.1 SC 3.3.2 Labels or Instructions (Level A) / SC 4.1.2 (Level A)

A text field, select or textarea in the transcript has no <label for>, no wrapping <label>, no aria-label and no aria-labelledby. The reader hears "edit, blank" and has to guess what goes in it from whatever was said before — which is often nothing, because the visible label may be a <div> that is not associated with anything. A placeholder is not a label: several screen readers do not announce it at all, and every browser deletes it the moment a character is typed.

The fix: Associate a real label: <label for="email">Email</label><input id="email">. If the design has no room for visible text, the field still needs a name — aria-label="Search" on a search box is correct and is what the pattern is for.

An image is read out as its own filename

Failure

WCAG 2.1 SC 1.1.1 Non-text Content (Level A)

An image in the transcript has no alt attribute at all. A missing alt is not the same as alt="" — an image with no alt is not silent, it is announced, and what gets announced is the src: "graphic, hero dash final dash v 2 dash compressed dot p n g". The reader gets the export history of your design file. This is the most common failure on the web by count, and the gap between it and the correct fix is one attribute.

The fix: Decide which of the two it is. If the image carries meaning, write alt="…" describing what it shows. If it is decoration — a texture, a divider, an icon beside text that already says the same thing — write alt="" exactly, and it goes silent the way it should.

An embedded frame is announced with no name

Failure

WCAG 2.1 SC 4.1.2 Name, Role, Value (Level A)

An <iframe> in the transcript carries no title, no aria-label and no aria-labelledby, and it is not hidden. The reader is told there is a frame here and nothing about what is in it — and because a frame takes focus, they can tab straight into somebody else's page without being told they have.

The fix: Add one attribute: title="Booking calendar", title="Map of our Denver office". Name what the embed IS.

A link recites its own address

Review

WCAG 2.1 SC 2.4.4 Link Purpose (Level A)

A link's only name is a URL, so the line is read out character group by character group: "h t t p s colon slash slash" and onward through the path. A forty-character address takes several seconds to say and carries no more meaning at the end of it than at the start. This is what an unnamed link falls back to, and it is also what happens when a CMS pastes a bare address into the body of a post.

The fix: Replace the address with what is at the other end of it. If the URL genuinely has to be visible — a citation, a docs reference — keep it on screen and give the link an aria-label saying where it goes.

The page has no title, so the reading opens with your domain

Failure

WCAG 2.1 SC 2.4.2 Page Titled (Level A)

The first thing a screen reader says on arrival is the document title, before any of the page. This page has no <title>, or has an empty one, so what is said instead is the browser's fallback — the URL. A reader with six tabs open has six identical ones, and somebody arriving from search is told nothing about where they landed.

The fix: Add a <title> that names this page first and the site second: <title>Pricing — Acme</title>. Front-load it; screen reader users and tab strips both truncate from the right.

The page never says what language to read it in

Failure

WCAG 2.1 SC 3.1.1 Language of Page (Level A)

The <html> element carries no lang attribute, or an empty one. The screen reader has no instruction about which voice to use, so it keeps whatever the user last had — which for a reader whose system language is not yours means your English page read aloud by a Spanish or German synthesizer, phonetically, word by word. It is one of the few defects that makes a page not merely awkward but genuinely unintelligible.

The fix: Add it to the root element: <html lang="en">. One attribute, on every page, and use the region form (en-GB, pt-BR) only where the pronunciation genuinely differs.

There is nothing in the transcript to jump between

Review

The reading contains no landmarks — no banner, no navigation, no main, no contentinfo. Landmarks are how a screen reader user skips: one keystroke to main content, one to the nav. Without them the only way through this page is from the top, every time, through the whole header and menu before reaching a word of content. It is not a conformance failure on its own, and it is the single largest difference between skimming a page and reading all of it.

The fix: Use the elements you already have semantically: <header>, <nav>, <main>, <footer>. One <main> per page around the content is the one that matters most, and it costs a tag change.

There is no heading in the reading at all

Review

The transcript contains no headings. After landmarks, headings are the second navigation structure a screen reader offers — the H key walks them, and a reader uses that list the way a sighted reader uses the shape of the page. A page with none reads as one undifferentiated block. Text styled large with CSS does not count: what makes a heading is the element, not the size.

The fix: Mark the text that is already acting as a heading as one. If a <div class="title"> introduces a section, it is an <h2>.

The reading has headings but never says level 1

Review

There are headings here and none of them is an <h1>, so the transcript has no top of the document — the heading list opens at level 2 or lower and a reader jumping to the first heading lands inside a section rather than at the start. Not a WCAG failure: no criterion requires an h1. It is a convention every screen reader user navigates by.

The fix: Promote the heading that names the page to <h1>, one per page. If the visual design wants it smaller, style it — the level is structure, not size.

We cannot read this page from here

Cannot tell from here

The HTML your server sent is close to empty — it looks like a client-rendered shell that mounts its real markup once JavaScript has run. A screen reader reads the rendered page, not this, so a transcript taken from here would be a transcript of nothing. This is an honest "cannot tell" rather than a pass: every defect this tool finds is still possible once the app has mounted.

The fix: Read it in a browser instead: the free site-wide scan renders every page in a real browser before it reads it, which sees the markup your scripts mount.

Two silences are correct and are never reported. An image with alt="" is decoration and is supposed to be skipped — we count those and say how many. And anything inside an aria-hidden="true" subtree is removed from the reading, which is what makes the most common correct icon pattern — <a><svg aria-hidden></svg><span class="sr-only">Close</span></a> — read as “link, Close” rather than as a defect.

Where to listen for real, once the empty lines are gone

A transcript tells you which lines say nothing. It cannot tell you whether the page makes sense in that order, and that is a judgement only listening produces. Both of the readers you need are free and one of them is already installed: NVDA on Windows, and VoiceOver on macOS at Cmd+F5 or on iOS under Accessibility. Turn one on, close your eyes, and try to reach your own checkout. The first thing you will notice is how far down the page the content starts, which is the landmark problem, and the second is how many of the controls you recognise only because you built them.

Our screen reader testing guide walks the keystrokes, and the NVDA and JAWS comparison covers where the two disagree about what to say.

Questions

Is this actually a screen reader, or a simulation of one?

Neither, and the distinction matters. It is a transcript: we read the HTML your server sends and compute the accessible name and role of every element a screen reader would announce, then print them in document order as lines. What you get is the sequence of phrases, not audio. That is deliberately the useful half — the thing people cannot get without installing NVDA is not the voice, it is the order and the content of the announcements, and the voice is what makes listening to your own page for the first time take forty minutes.

Why is my image not in the reading?

Because it has alt="", which is the documented, correct way to make a decorative image silent. Those images are counted with the result and never listed as a problem — a checker that reported them would put a finding on almost every correct page on the web. An image with NO alt attribute is a different thing entirely and it does appear: it is not silent, it is announced, and what gets announced is the filename.

There are headings on my page and the transcript skipped some.

A heading with no text in the served HTML is not announced as a heading, so it is not a line. The usual cause is a heading whose content is an image with no alt, or one filled in by JavaScript after the page loads. The second case is the general limit here: we read what your server sent, so anything your app builds in the browser is invisible from this side. A page whose HTML is an empty shell gets an honest "cannot read this from here" rather than a pass.

Why does the reading open with my page title before anything on the page?

Because that is what happens. On arrival a screen reader announces the document title first, before the landmark, before the heading, before anything visible — it is the only orientation the listener gets about where they are. That is why SC 2.4.2 Page Titled is a Level A criterion and why a title that opens with your company name rather than the page's name wastes it: a listener with six tabs open hears the same eight words six times.

My page has no landmarks and you did not call it a failure. Why not?

Because no WCAG criterion requires them, and we do not put the word failure on things the standard permits. It is still probably the largest single change to how long your page takes to use: landmarks are what the skip keys skip to. Without a <main>, a listener reaching your content has to sit through the entire header and menu on every single page view, every visit. We report it in the review band, which is where things that are legal and slow belong.

An icon button with a <title> inside its SVG — is that named?

Sometimes, unreliably, and you should not depend on it. Browser and screen reader support for computing a name from an SVG <title> is inconsistent enough that the accepted practice is to name the button instead: aria-hidden="true" on the icon, aria-label on the button. This tool does read an SVG <title> as a last-resort name so that it does not accuse a page that has one — but if you are choosing, put the name on the control.

Does a placeholder count as a label?

No. Several screen readers do not announce it, and every browser deletes it the moment the first character is typed — so it is a label that disappears exactly when somebody needs to check what they are filling in. A field whose only labelling is a placeholder reads here as "edit, blank", because that is what a listener gets. If the design has no room for visible text, aria-label on the field is the correct pattern.

You read my whole page and stopped partway. Why?

There is a cap on the transcript at 120 lines, because past that it is not something a person reads. When it is hit, every count we print says "at least" rather than a total — a number we have stopped counting toward is never printed as a finished one. The counts of defects are complete for the lines that were read, and the pages with more than 120 announced elements are usually the ones where the site-wide scan is the right instrument anyway.

Which screen reader is this? They do not all announce the same thing.

They do not, and the differences are real — JAWS, NVDA and VoiceOver word landmarks and roles differently, and each has verbosity settings that change what gets said. The lines here follow the common shape: role plus name, with the document first. Where the three disagree it is about phrasing, not about content, and a line that is empty here is empty in all of them, which is the part this tool is for.

Does this replace a real audit, or a real screen reader?

No to both, and for different reasons. It reads one page and only the things a screen reader announces, so it says nothing about contrast, focus order, zoom, motion or timing. And listening with a real screen reader tells you something no transcript can — whether the page makes sense in that order, which is a judgement. What it does replace is the excuse: you can read your own page back in ten seconds without installing anything, and if a line in it says "button" you already know. The site-wide scan renders every page in a real browser and names every WCAG violation by criterion with the failing element on the page it is on.

Other free checks

Each of these reads one thing properly, and each of them reads a thing this transcript cannot.