Dirigo Interactive · Training sample

Screen Reader Demo: Bad and Good Examples

Five side-by-side comparisons for a live screen reader walkthrough. Each pair has a deliberately inaccessible Bad example and an accessible Good example, with a note on what a screen reader should announce.

How to use this page

Tip: the Elements List (Insert + F7 in NVDA) is the fastest way to show the difference. A list of links full of "click here," or a page with no headings, tells the story instantly.

1. Buttons announced with meaningful names

Listen for: does the button announce what it does, or just say "button"?

Bad example

Search field with an icon-only button that has no accessible name:

Announces: "button" (no name). The user has no idea what it does.

Good example

The same icon button with an accessible name via aria-label:

Announces: "Search, button."

2. Link text: descriptive or not

Listen for: pull up the links list (Insert + F7). Do the links make sense out of context?

Bad example

For the 2025 accessibility report, click here.

To learn more about our services, read more.

In the links list: "click here, link" and "read more, link." Out of order, they mean nothing.

Good example

Download the 2025 accessibility report (PDF, 320 KB).

Learn more about our accessibility services.

In the links list: each link states its own purpose, no surrounding sentence needed.

3. Form fields: labelled or unlabelled

Listen for: when focus lands on the field, does the screen reader say what to type?

Bad example

Visible text sits above the field but is not linked to it:

Full name

Announces: "edit, blank." The label is invisible to the screen reader.

Good example

A real <label> tied to the field with for:

Announces: "Full name, edit."

4. Form errors: associated or not

Listen for: focus each email field. Is the error read aloud, or is it silent?

Bad example

The error is shown in red near the field, but nothing connects them:

Enter a valid email address, for example name@example.com

Announces on focus: "Email address, edit." The error is silent to the screen reader, and the field is not marked invalid.

Good example

The field is marked invalid and points to the error with aria-describedby:

Error: Enter a valid email address, for example name@example.com

Announces on focus: "Email address, invalid, edit, Error: Enter a valid email address..." The user hears the problem and how to fix it.

5. Headings: real and in order

Listen for: press H to move by heading, or open the headings list. Do the section titles show up, in a sensible order?

Bad example

Section titles are just big, bold text, not real headings:

Applying to CivicPortal

Start your application from the resident dashboard.

Required documents

Upload proof of residency and a photo ID.

Pressing H: note that one of the visual headings is not marked up/coded as a heading, and the other heading skips a heading level.

Good example

The same titles as real, properly nested headings:

Applying to CivicPortal

Start your application from the resident dashboard.

Required documents

Upload proof of residency and a photo ID.

Pressing H: "Applying to CivicPortal, heading level 3," then "Required documents, heading level 4." The user can jump straight to the section they need.