Why accessibility matters, legally and practically

Four modules of this course have already been quietly teaching accessibility — semantic elements, alt text, scope on tables, real labels, :focus-visible, prefers-reduced-motion. This module is where it stops being a side note.

It starts with the argument, because "be accessible" without a reason produces box-ticking, and box-ticking produces the aria-label on a <div> that the next lesson exists to talk you out of.

Who this is about

The mental image is usually a blind person with a screen reader. That is one group, and a small one. The actual population is much larger and mostly invisible to you:

Around 4 to 5 percent of people cannot distinguish red from green. Mostly men. Nothing about their browsing looks unusual — they simply cannot see that your "required field" hint is red.

Far more people have low vision than are blind. They zoom to 200%, or set a larger default font size, or use a high-contrast mode. Every one of those is a thing your CSS can break, and all three were covered in earlier modules.

Motor impairments make a mouse imprecise or impossible. That includes permanent conditions, and also a broken wrist, a tremor, or holding a baby. These people use the keyboard, and a keyboard-hostile site is simply unusable.

Cognitive differences — dyslexia, ADHD, memory difficulties — are the largest group of all, and the least catered for. They are helped by plain language, consistent layout, and not being hurried by a timeout.

Deaf and hard-of-hearing visitors need captions for anything with speech.

And the group nobody counts: everybody, sometimes. Sunlight on a phone screen is a contrast problem. A noisy bus is a captions problem. One hand on a train is a motor problem. Tiredness is a cognitive one. Accessibility work is the same work as making the site usable in bad conditions, which is most conditions.

In India specifically, the 2011 census counted about 2.7 crore people with disabilities, and the Rights of Persons with Disabilities Act 2016 requires accessible government and public services. The numbers are widely held to be undercounted.

The practical argument

It is the same work as good engineering. Semantic HTML, keyboard support and real labels are what make a site testable, scriptable, printable and indexable. The module 1 argument — that a div-soup page is unusable — was an accessibility argument wearing ordinary clothes.

Search engines are the largest screen reader in the world. They read your page without seeing it, exactly as assistive technology does. Heading structure, alt text and link text are read by both.

Retrofitting costs far more. Adding keyboard support to a finished custom dropdown means rebuilding it. Choosing <details> or <dialog> at the start costs nothing — which is why module 1 taught them.

It is a legal requirement in a growing number of places — the RPwD Act in India, the ADA in the United States, the European Accessibility Act. Accessibility lawsuits are now common enough to be a business risk, and "we did not know" has never been a defence.

And it is the right thing. That is not a weaker argument than the others, it just persuades fewer managers.

WCAG, briefly

The Web Content Accessibility Guidelines are the standard everybody means by "accessible". Three conformance levels:

• A — the minimum. Failing it usually means something is unusable.
• AA — the practical target, and what nearly every law references. Aim for AA.
• AAA — stricter, and not achievable for all content. Nobody asks for it site-wide.

The criteria are organised under four principles, which are worth knowing as a checklist for your own work:

"POUR". The mnemonic is not important; the four questions are.

What automated tools can and cannot find

This matters early, because a green Lighthouse score is frequently mistaken for a finished job.

Automated tools find roughly a third of issues. They are very good at the mechanical ones: a missing alt, a form field with no label, insufficient contrast between two declared colours, a missing lang, a duplicate id, invalid ARIA.

They cannot judge anything that needs a human. Whether alt="chart" describes the chart. Whether the heading order makes sense. Whether the focus order is logical. Whether your error message tells somebody what to do. Whether a link called "read more" means anything.

So the split is:

• Run axe or Lighthouse to catch the mechanical third automatically.
• Use the keyboard and a screen reader for the rest.

The final lesson of this module is entirely about doing both, because a testing habit is worth more than any list of rules.

The overlay trap

You will be sold a JavaScript "accessibility overlay" — a widget promising compliance in one line of script. They do not work. Disability advocacy organisations campaign against them, hundreds of accessibility practitioners have signed a public statement opposing them, and sites using them have still been sued successfully.

They cannot work, for a structural reason: a script cannot know that your <div> was meant to be a button, or what your image was of. The information is not in the page. Nothing can retrofit meaning that was never written down.

What this module covers

Deliberately not a re-run of modules 1 to 4:

• semantic-structure — headings and landmarks as a navigation system, which is how they are actually used.
• keyboard-and-focus — tab order, focus management, skip links, and the traps.
• contrast-and-colour — the ratios, how to compute them, and not relying on colour.
• aria-basics — mostly a lesson in not using ARIA, and the five rules.
• testing-accessibility — keyboard, screen reader and axe, hands on.

Check your work

Who accessibility is for. Far more people than blind screen reader users: colour vision deficiency, low vision, motor and cognitive differences, deaf visitors — and everybody in bad conditions.

Why it is the same as good engineering. Semantic HTML and keyboard support make a site testable, printable and indexable.

The largest screen reader in the world. A search engine — it reads without seeing.

Why retrofitting is expensive. A finished custom dropdown has to be rebuilt.

Which WCAG level to aim for. AA.

The four principles. Perceivable, operable, understandable, robust.

How much automation catches. Roughly a third, and only the mechanical third.

What automation cannot judge. Whether alt text is right, whether heading order makes sense, whether focus order is logical.

Why overlays cannot work. A script cannot know your <div> was a button or what your image showed.

Practice

1. Open any site and turn off your mouse — unplug it or sit on your hands. Try to complete one task.
2. Zoom a page you built to 200% and then 400%. Note what becomes unusable.
3. Emulate a colour vision deficiency in the devtools Rendering panel and look for anything that stops making sense.
4. Read the four WCAG principles and write one thing from your own page under each.
5. Run Lighthouse's accessibility audit on a page you built. Note the score.
6. Then tab through the same page and find one problem Lighthouse did not report. This is the exercise that makes the point.
7. Find alt text on a real site that is technically present and useless.
8. Look up the WCAG 2.2 AA criteria list once, just to see how long it is.
9. Find a site using an accessibility overlay widget. Tab through it and judge whether the widget helped.
10. Ask somebody who uses a screen reader, a magnifier or keyboard-only navigation what annoys them most. If you do not know anybody, search for a recent account written by somebody who does.

Official documentation

• W3C WAI — Introduction to web accessibility — The case, the standards, and how they fit together.
• W3C — WCAG 2.2 at a glance — The four principles on one page, as a starting map.
• W3C — How to meet WCAG (Quick Reference) — Filterable by level and by technology. The page to keep open while building.
• MDN — Accessibility — The developer-facing version, organised by what you are building.
• Overlay fact sheet — The signed statement from accessibility practitioners on why overlay widgets do not work.

Next: headings and landmarks, which are a navigation system rather than decoration.