AccessivePath
Download sales proposal

A walkthrough from AccessivePath

Accessibility, explained from zero.

A plain-language walkthrough of what web accessibility actually means. Who needs it, how a visually impaired person uses a screen reader to navigate, what keys they press, what their computer reads out loud, and why a normal-looking website can be impossible to use without the right markup. Then a live, side-by-side comparison of an inaccessible vs accessible interface, with audio.

Read it top to bottom in ~10 minutes. Headphones recommended for the demo.

~285M

visually impaired people worldwide (WHO)

~43M

severely visually impaired, rely on screen readers

96%

of homepages fail WCAG (WebAIM 2024)

70%

of WCAG fails are invisible to automated scans

Section 1 — definition

So what is accessibility?

Web accessibility means that a website or app works for every person, on every device, with every assistive technology — not only for a sighted, mouse-using person on a fast laptop.

That is not charity. It is the simple recognition that a quarter of the planet, about 1.3 billion people, has a permanent disability of some kind, and roughly everyone else has a temporary or situational one (a broken wrist, a noisy train, an old phone, sunlight on the screen). Building for the edges improves the experience in the middle.

The World Wide Web Consortium (W3C) wrote a standard for this called the Web Content Accessibility Guidelines, or WCAG, currently at version 2.2. It is the same standard every government in the world (US ADA, EU EAA, Section 508, India RPD Act) actually points to when they say a digital product must be accessible. WCAG defines 86 success criteria across four principles (see the next section).

In one line

Accessibility is the same product, usable by anyone who shows up. At the keyboard, with a screen reader, with a switch, with low vision, with no hearing, with a tremor, or just having a bad day.

Who actually benefits?

  • Visual

    Visually impaired (no vision or low vision) and colour-blind users. Use screen readers (NVDA, VoiceOver), screen magnifiers, high-contrast modes, larger text. ~285M people worldwide.

  • Hearing

    Deaf, hard of hearing. Rely on captions, transcripts, sign-language interpretation, visual notifications. ~466M people worldwide.

  • Motor

    Limited or no use of hands, tremor, paralysis, missing limbs. Use keyboard-only, switch controls, voice input (Dragon), eye-tracking, head sticks.

  • Cognitive

    Dyslexia, ADHD, autism, memory loss, brain injury. Need plain language, predictable layouts, no time pressure, no auto-playing media, clear error messages.

  • Situational

    You, in a bright park trying to read a screen. You, holding a baby with one hand. You, at 65 with bifocals. Everyone is "temporarily disabled" multiple times a year.

That last category, Situational, is why building accessibly ends up benefiting everyone, not just the 1.3 billion with permanent disabilities.

Section 2 — the four big rules

P · O · U · R, in plain English.

Every WCAG rule fits into one of four buckets: Perceivable, Operable, Understandable, Robust. The official wording sounds like a treaty. Here it is the simple way, with what each one means for the code you actually write.

Perceivable

Can the user notice it at all?

WCAG official wording

“Information and user interface components must be presentable to users in ways they can perceive.”

What it actually means

If a user cannot see it, they need to hear it. If they cannot hear it, they need to read it. If the text is too small, they need to zoom. Whatever you put on the page must reach at least one of their working senses.

In your day-to-day code

  • Every image needs a description in code so a screen reader can say "photo of a customer at her laptop" instead of staying silent.

  • Every video needs captions so a deaf user can read the words being spoken.

  • Colour cannot be the only signal a red dot for "error" must also have an icon or the word "Error" next to it. About 1 in 12 men cannot tell red from green.

  • Text must still work when zoomed to 200% because a low-vision user often keeps zoom on all day.

  • Text must have strong contrast with the background or someone with low vision, age-related sight loss, or just sunlight on the phone cannot read it.

Operable

Can the user actually use it?

WCAG official wording

“User interface components and navigation must be operable.”

What it actually means

Every action on your site must work with every input device. Mouse. Keyboard alone. Voice command. Switch button. Eye tracker. If any of them fails, that group of users is locked out.

In your day-to-day code

  • Tab must reach every button if Tab cannot reach your "Buy now" button, your visually impaired customers cannot buy.

  • No traps a keyboard user must always be able to leave any control they entered. Otherwise they reload the page.

  • No tight time limits a 30-second session timeout will lock out anyone slower than a typical sighted user.

  • Nothing flashing more than 3 times a second this triggers seizures in people with photosensitive epilepsy.

  • Tap targets at least 24 by 24 pixels so users with tremor, parkinsonian symptoms, or fat thumbs can hit them.

  • A "Skip to content" link at the top so keyboard users do not Tab through 40 menu links on every single page.

Understandable

Does the user know what is happening?

WCAG official wording

“Information and the operation of user interface must be understandable.”

What it actually means

The page must make sense. Labels must be honest. Errors must explain what went wrong AND how to fix it. The site must not surprise the user with sudden navigation, sudden layout changes, or words they do not know.

In your day-to-day code

  • Form labels say what users say use "Email" not "Field 1". Use "Phone number" not "Tel."

  • Errors explain the fix not "Invalid input" but "Email must include an @ sign. Example: you@company.com."

  • Page language is declared in the HTML so the screen reader uses the right pronunciation.

  • Saving something is confirmed out loud after Save, say "Settings saved." Silence makes users click Save five more times.

  • Navigation is in the same place on every page surprises break the mental map.

  • Plain language, short sentences legal jargon and abbreviations leave behind anyone with a cognitive disability.

Robust

Will it still work tomorrow, on any device?

WCAG official wording

“Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.”

What it actually means

Write the kind of HTML that the next screen reader, the next browser, and the next iOS update will all still understand. If you reinvent buttons as plain divs, today's screen reader cannot see them. Neither can tomorrow's.

In your day-to-day code

  • Use real HTML elements use the actual <button>, <a href>, <input>, <label>, <table>, <nav>, <main> tags. They come with accessibility built in.

  • When you need ARIA, use it correctly role="button" plus tabindex="0" plus an Enter/Space handler. All three, or none.

  • Test with more than one screen reader NVDA with Firefox, JAWS with Edge, VoiceOver with Safari, TalkBack with Chrome. They sometimes disagree.

  • Follow the W3C ARIA Authoring Practices Guide it tells you exactly how to build a tab, a combobox, a dialog. Do not improvise.

  • Valid HTML broken markup makes assistive tech guess. Guessing always loses.

Miss one of the four and you lock out a whole group of people. Hit all four and your product is what the regulators around the world actually call “accessible.”

Section 3, a real user

Meet Ramesh. He is a customer, just like you.

Ramesh is 42 years old. He works in a school office. He has very low vision because of an eye condition. Most days the screen looks like a blur of shapes to him. He is not a developer. He is not technical. He is a regular customer of about a dozen websites and apps every week. He could be your customer.

This morning, before leaving for work, Ramesh did six normal things on his phone and laptop. He could not see the screens properly. He still finished every task.

  • He opened his banking app, heard his balance read out loud, and transferred this month's rent to his landlord.
  • He paid the electricity bill on the utility company's website.
  • He booked a train ticket to visit his parents next weekend.
  • He ordered groceries from a delivery app: milk, dal, vegetables.
  • He replied to two emails and a WhatsApp from his daughter's school.
  • He checked the weather to see if he should take an umbrella.

He does all of this with help from a piece of software called a screen reader. The screen reader looks at the page and reads it out loud. Every heading, every button, every form field, every total. While the screen reader speaks, Ramesh moves around with the keyboard. He hears the page. He never sees it clearly.

He does not touch the mouse. He uses the keyboard for everything.Tab jumps to the next button or link.Arrow keys read each line.H jumps to the next heading.Enter activates a button. Every key press triggers a little phrase of speech, telling him where he is and what he can do next.

On a well-built banking app, Ramesh transfers rent in under a minute. On a well-built grocery site, he reorders his weekly basket in three clicks.

On a badly-built one, the screen reader says “button” with no name. Or “edit, blank” with no label. Or reads the entire menu twice before reaching the bill amount. Ramesh cannot finish the task. He moves to a competitor. Maybe yours.

Ramesh is one of 285 million visually impaired people in the world. Every one of them is a customer of someone. Every accessibility decision you make in your code shows up in their day.

Section 4, the magic helper

What is a screen reader, exactly?

A screen reader is a small program that runs in the background. It looks at what is on the screen and reads it out loud, while the user moves around with the keyboard. Think of it like having a friend next to you who reads every button and word out loud, in the order you point at them. That is what a screen reader does, just much faster.

NVDA

Free, on Windows

Short for NonVisual Desktop Access. Free, open-source, and one of the two most-used screen readers on Windows. Many visually impaired users prefer NVDA because they can install it on any computer, even without admin permission.

JAWS

JAWS

Paid, on Windows

Short for Job Access With Speech. The big-business standard since 1995. Common in government, banking, and large insurance offices. Same idea as NVDA, different company, costs about $1000.

VoiceOver

Built into Mac and iPhone

Apple's built-in screen reader. Already on every Mac and every iPhone. Turn it on with Cmd plus F5 on a Mac, or triple-press the side button on an iPhone. Almost every visually impaired iPhone user uses VoiceOver.

TalkBack

Built into Android

Google's built-in screen reader for Android phones. The most-used screen reader in countries where iPhones are uncommon. Same idea as VoiceOver, slightly different gestures.

Seeing them in action

What it looks like on the user’s screen

Both NVDA and VoiceOver can show the speech they are reading aloud as a floating caption on the screen. It is useful for sighted teammates, training, and QA. Press the button on each mockup below and watch how each tool announces the same page.

NVDA on Windows

running on Firefox, headphones recommended

Speech Viewer
https://yourbank.example.com

Email address

NVDA Speech Viewer

Home, link

Click to hear it.

VoiceOver on macOS and iOS

running on Safari, press Cmd+F5 to turn on

Caption Panel
https://yourbank.example.com

Email address

VoiceOver Caption Panel

“Home, link, 1 of 3”

Click to hear it.

Why screen readers exist at all

A computer screen is made of pixels. Pixels are for eyes. A visually impaired person cannot use those pixels. The screen reader is a translator: it takes the pixels and turns them into speech (or into braille, on a special keyboard). The user hears or feels what the screen shows, and uses the keyboard to act on it.

Without screen readers, a visually impaired person could not use a computer at all. With screen readers, they can do anything a sighted person can. As long as the developer wrote the right HTML. That is the deal. Software is only as accessible as the code we ship.

Section 5, the keys they press

The keys a screen-reader user actually presses.

A screen reader user moves around the whole web from the keyboard. No mouse, ever. The keys below are the ones they press hundreds of times every day. Every button, link, and form on your site has to respond to them correctly. If even one does not, the user is stuck.

Universal navigation

  • Tab

    Move to next interactive control

  • ShiftTab

    Move to previous interactive control

  • Enter

    Activate the current link or button

  • Space

    Activate a button / toggle a checkbox / scroll the page

  • Esc

    Close a menu, dialog, or pop-up

Inside a screen reader

  • H

    Jump to next heading (H1, H2, H3…)

  • 123

    Jump to next heading of that specific level

  • K

    Jump to next link

  • F

    Jump to next form field

  • B

    Jump to next button

  • L

    Jump to next list

  • T

    Jump to next table

  • InsF7

    Open the "Elements list" of every heading, link, landmark

  • ↓

    Read next line

  • ↑

    Read previous line

  • InsSpace

    Switch between "browse" and "focus" mode

Inside a control

  • Arrow keys

    Move within radio group / tab list / menu / combobox options

  • HomeEnd

    Jump to first / last item in a list, menu, or combobox

  • Letter key

    Type-ahead, jump to first item starting with that letter

  • Esc

    Close menu / combobox / dialog and return focus to trigger

Most sighted developers learn these only when their accessibility audit fails. Most visually impaired users learn them in the first week they ever touch a computer, often around age 6.

Section 6, what the user hears

What the screen reader actually says.

When the user lands on something, the screen reader always says three things in order. The label (what is this called?), the role (what kind of thing is it?), and the state (is it on? required? selected?). Get all three right and your page is usable. Miss any one and the user has to guess.

HTML you wroteWhat NVDA / VoiceOver saysWhy that matters
<h1>Account Dashboard</h1>

"Account Dashboard, heading level 1"

Heading level tells the user where they are in the page outline.
<a href="/orders">Orders</a>

"Orders, link"

Role + name. User knows pressing Enter will navigate.
<button>Save changes</button>

"Save changes, button"

Role + name. User knows pressing Enter or Space will do something here.
<input type="email" required>
<label>Email address</label>

"Email address, required, edit, blank"

Label + state + role + current value. User knows the field, what to type, that it is empty.
<button role="switch" aria-checked="true">

"Email notifications, on, switch"

Label + state + role. User knows it is a toggle and is currently on.
<div role="tab" aria-selected="true">Profile</div>

"Profile, tab, 1 of 3, selected"

Role + position + state. User knows there are 3 tabs and they are on the first.
<img alt="Approved by IAAP" src="/badge.png">

"Approved by IAAP, image"

Alt text describes the image. Without alt, screen reader says nothing useful.
<div onclick="…">Refresh</div>  ❌

(silence, nothing announced)

A plain div has no role. It is invisible to the screen reader. The user has no idea this button exists.

Once you remember the label, role, state rule, you can predict what the screen reader will say from any HTML. And you can fix any silent or wrong announcement by adding the missing piece.

Section 7, what the user actually feels

What inaccessibility actually does to a user.

“Inaccessible” is not a fancy word. It is the exact moment a real person cannot finish a task. They wanted to pay a bill. Read a balance. Apply for a job. Each card below is a real failure. Click any “Try it” button and feel what your visually impaired customer feels.

  • The button that does not exist

    Hurts: Locks out every screen-reader user

    The developer used the wrong HTML tag while coding the Refresh button. To your eyes it still looks like a normal button, and a mouse user can click it. But the underlying code never told the computer “this is a button”, so the screen reader does not know it is there. Tab skips right over it, as if the button were not on the page at all.

    Press the orange button below to watch Tab move through the row.

    Home↻ RefreshSign out

    Tap the orange button. Watch the amber focus ring move.

  • The form field with no name

    Hurts: Locks out screen-reader and cognitive-disability users

    Only a placeholder, no real label. The moment the user types, the hint vanishes. They forget which field they are in.

    Press the button. Listen to what the screen reader says.

  • The red dot you cannot see

    Hurts: 1 in 12 men, 1 in 200 women (colour-blind)

    Status shown by colour only. A colour-blind user cannot tell red from green. They miss the error completely.

    Payment failed
    Two-factor active

    Click to see what a colour-blind user sees.

  • The modal you cannot escape

    Hurts: Every keyboard user, disabled or not

    A dialog opens. Escape does nothing. Tab walks back into the page behind it. The only way out is to refresh.

  • The text you cannot read

    Hurts: Anyone with low vision, age over 60, or sunlight on the screen

    Pale grey text on white. Just 2.7 ratio of contrast. Click the button to see what a low-vision user sees.

    Sign in

    Enter the email address linked to your account.

    Forgot password? Need help? Contact support.

    Click to see what a low-vision user sees.

  • The spin that triggers a migraine

    Hurts: People with vestibular disorders (about 35 percent of adults at some point)

    A spinner that ignores the user's reduce-motion setting. Some users get nausea within seconds.

    Click to start the spinner.

Section 8, interactive demo

Inaccessible vs accessible. Try it yourself.

Three pairs of mini-screens. The broken one on the left, the fixed one on the right. They look almost the same. They feel completely different. Press the highlighted keys on your keyboard. Your computer will read out what a real screen reader would say, and a log on the right keeps every announcement. Headphones recommended.

1. Modal dialog you can vs. cannot escape

Both open a confirmation pop-up. The bad one has no Escape key support and the X button has no name. A keyboard user opens it and is trapped. The good one moves focus into the dialog, Escape closes it, and the X has a label.

How to use this demo

Open the bad pop-up, then press the Escape key. Hear what happens. Then open the good one and try Escape again. Hear the difference.

Headphones recommended. Your computer’s text-to-speech voice reads each announcement out loud.

🔴 Inaccessible

No role=dialog, no aria-modal. The X button has no accessible name. Escape does nothing. A keyboard user is trapped.

🟢 Accessible

role=dialog + aria-modal. Focus moves into the dialog. Tab cycles inside. Escape closes. Focus returns to the trigger.

Keys to press

Pressed key lights up. Try these on the focused demo above.

TabShift+TabEscEnter

Screen-reader transcript

What NVDA / VoiceOver would say at each step.

  1. (No announcements yet. Press a key in one of the demos above.)

The speech you hear is your computer's text-to-speech voice reading scripted announcements that mirror what NVDA or VoiceOver would say in this scenario. The principle is identical.

Section 9 — the overlay trap

Why “accessibility overlay” widgets do not work, in court or with users.

An overlay is a small JavaScript widget you paste into your site. It pops up an accessibility menu (font size, contrast toggle, “dyslexia font”) and promises one-line ADA compliance. The screen-reader community, the W3C, the US DOJ, and the courts have all reached the same conclusion: overlays do not fix the underlying HTML, do not stop lawsuits, and frequently make the user experience worse for the very people they claim to help.

Overlay widget

Sticker on a broken door

yoursite.com
♿Accessibility menu
  • Does not fix the underlying HTML
  • Visually impaired users frequently disable it
  • No legal protection — sites still get sued
  • DOJ March 2022: not a substitute
  • Adds 200–500 KB of JavaScript
  • Annual fee: $490–$5,000+
Real audit + remediation

Fix the door

yoursite.com
✓ button label fixed
✓ input got a label
✓ dialog focus-traps + Esc
✓ live region announces save
  • Fixes the underlying HTML at the source
  • Improves the experience for every assistive tech
  • Produces evidence courts and procurement accept
  • Aligned with WCAG 2.2 AA, ADA, EAA, Section 508
  • No JavaScript added at runtime
  • One-time audit, then CI keeps it that way

The vendors who sell the overlay promise

Four companies dominate the “automated overlay” market. They are not the same as a real accessibility audit. They are not a defence in court. Sites running their widgets still get sued, repeatedly.

  • accessiBe

    accessiBe

    Founded 2018

    "AI overlay" — most lawsuits

  • UUserWay

    UserWay

    Founded 2016

    "AI widget"

  • AudioEye

    AudioEye

    Founded 2005

    Public company

  • EqualWeb

    EqualWeb

    Founded 2017

    "Automated solution"

Active litigation pattern

Sites running an overlay are not protected.

  • 4,605

    ADA Title III website lawsuits filed in 2023 (Seyfarth Shaw tracker)

  • 1 in 4

    of those sites were already running an overlay when sued

  • March 2022

    DOJ guidance: automated widgets are not a substitute for compliance

  • 2019

    SCOTUS lets Robles v. Domino's stand — ADA applies to websites

Named lawsuits the overlay vendors do not mention

CaseCourtOutcome
Murphy v. Eyebobs (overlay user)S.D.N.Y., 2021Settled despite overlay installed
Robles v. Domino's PizzaSCOTUS cert denied, 2019ADA applies to websites — landmark
Suarez v. Camacho Auto SalesC.D. Cal., 2022Overlay defence rejected
Andrews v. Blick Art Materials2nd Cir., 2017Established website-as-place-of-public-accommodation

The defensible answer in court is not a widget. It is a documented audit against WCAG 2.2 AA, source-level fixes, and an IAAP-format Conformance Report.

What a defensible accessibility programme actually looks like

When a complaint lands on your legal team’s desk, this is the evidence they need. Not a widget badge.

  1. Source-level remediation

    Real HTML fixes shipped in your codebase, reviewed in pull requests.

  2. IAAP-format ACR / VPAT report

    Procurement-grade Accessibility Conformance Report mapping every WCAG criterion.

  3. Evidence pack

    Screen-reader transcripts, keyboard logs, contrast measurements, dated and signed.

  4. Human pair review

    IAAP-credentialed auditor signs off on every finding flagged by the AI.

  5. Continuous CI checks

    Automated regression checks on every deploy so the fix sticks.

  6. Documented accessibility statement

    A public page disclosing standards followed, AT tested with, and contact for accessibility issues.

How we actually do it

From broken to compliance-ready, in four stages.

End-to-end. You hand over a URL, we hand back a defensible accessibility programme. Here is the path, stage by stage.

  1. 01

    End-to-end audit

    1 to 4 hours

    You give us a URL or a build. Our AI auditor crawls every page in scope and runs a full WCAG 2.2 AA evaluation: automated rules, keyboard traversal, ARIA semantics, contrast, and NVDA-backed screen-reader simulation. Findings are mapped to WCAG success criteria, severity-rated, and bundled into an IAAP-format Conformance Report.

    You receive

    • IAAP ACR / VPAT report (PDF + JSON)
    • Evidence pack: screen-reader transcripts, keyboard logs, contrast measurements
    • Severity-ranked findings list with selector and remediation hint
  2. 02

    Consultation & prioritisation

    1 to 2 days

    We walk your engineering, design, compliance, and legal teams through the findings in a live session. We rank each issue by user impact, business impact, and effort to fix. The output is a sequenced remediation roadmap aligned to your sprint cadence and procurement deadlines.

    You receive

    • Findings review session (recorded + transcribed)
    • Prioritised remediation roadmap
    • Sprint-ready ticket bundle (JIRA / Linear / GitHub Issues)
  3. 03

    Remediation

    2 to 6 weeks

    Either our accessibility engineers ship the fixes directly, or we pair-review your team's pull requests against the IAAP report. Every change is source-level: real <label>s, real semantic HTML, real focus management. Design-system components get patched once so the fix compounds across every screen.

    You receive

    • Merged pull requests with WCAG criterion linked in each diff
    • Design-system component patches
    • Per-fix verification screenshot + screen-reader transcript
  4. 04

    Compliance-ready & continuous

    Ongoing

    A final re-audit confirms WCAG 2.2 AA conformance. We co-sign the public accessibility statement, wire continuous CI checks so regressions cannot slip through, and stay on retainer for the inevitable production drift. You finish defensible against ADA, EAA, Section 508, and your procurement RFPs.

    You receive

    • Final IAAP ACR / VPAT, signed and dated
    • Public accessibility statement (drafted with your legal team)
    • CI integration with per-PR blocking thresholds
    • Quarterly drift report + on-demand re-audit

The compounding part

Once stages 1 to 4 land, every new deploy stays compliant by default. The CI checks block regressions, the design-system patches keep new screens accessible by inheritance, and the quarterly drift report keeps your accessibility statement honest. You buy compliance-ready once, and continuous compliance forever.

Section 10 — what we do

What we offer, finding what your users feel.

Every issue you saw in the demos above is exactly the kind of thing our AI auditor finds across your live site, described the way a real user would feel it. Not the way a static rule-checker would flag it. The result is a procurement-grade IAAP report your legal, compliance, and engineering teams can act on the same day.

Compared to a traditional audit

Traditional manual audit

  • • 6 to 12 weeks calendar time
  • • Static PDF, no audio evidence
  • • Repeat next quarter
  • • $20K to $50K per cycle
  • • Regressions ship between audits

AccessivePath AI audit

  • • Hours to deliver the report
  • • Audio and visual evidence per finding
  • • Re-runs on every deploy via CI
  • • Self-serve tiers, transparent pricing
  • • Continuous, not a quarterly snapshot

Next step

Want this for your own product?

We will audit one URL of your choice. Free. No card, no signup. You get the same kind of evidence you saw in the demos above: real screen-reader transcripts, keyboard traversal logs, contrast measurements, and a procurement-ready IAAP report.

Run a free audit on accessivepath.com →Book a 20-minute walkthrough⬇ Download sales proposal

Sales proposal: opens in a new tab and auto-launches the print dialog so you can save it as PDF with pricing, ROI, and next steps for procurement.
Information: downloads the educational walkthrough on this page (what accessibility is, screen readers, the demos).

founders@accessivepath.com · accessivepath.com