Accessibility is a testing problem

Accessibility gets treated as a specialist discipline requiring expert audits. Parts of it are. Most of what actually breaks is mechanical, catchable automatically, and would be fixed if it failed the build.

what automated tooling catches#

Roughly a third to a half of real accessibility issues are detectable by a linter or a test:

• Images without alternative text.
• Form inputs without associated labels.
• Insufficient color contrast.
• Missing document language.
• Heading levels that skip.
• Buttons and links with no accessible name.
• ARIA attributes that are invalid or applied to the wrong role.
• Interactive elements not reachable by keyboard.
• Duplicate or missing landmark regions.

Every one of those is a fixed rule with a fixed check, and every one of them is a real barrier for someone.

Getting the automatable third fixed is not the whole job and it is a much better place than most applications are.

the setup#

// component test
import { axe } from 'vitest-axe';

test('checkout form has no automatically detectable a11y violations', async () => {
  const { container } = render(<CheckoutForm />);
  expect(await axe(container)).toHaveNoViolations();
});

Plus a linter for the static cases:

{ "extends": ["plugin:jsx-a11y/recommended"] }

Plus a crawl of key pages in CI against the built site.

That is an afternoon of setup. It will find violations on day one — every codebase has them — so run it in report-only mode first, fix the backlog, then make it blocking. Making it blocking with a hundred existing violations gets it disabled within a week.

what tooling cannot catch#

Being honest about the limits matters, because "we run axe" becomes a claim of compliance that it does not support.

**Whether the alt text is good.** alt="image" passes. It is useless. A screenshot of a chart needs a description of what the chart shows, not the word "chart."

Whether the reading order makes sense. CSS can visually reorder content while the DOM order stays wrong, and a screen reader follows the DOM.

Whether focus management works. Open a modal — where does focus go? Close it — does it return? Navigate to a new route — is focus reset and announced? These are the most common real-world failures in single-page applications and no automated check catches them.

Whether dynamic content is announced. A live region that updates too often is worse than one that does not update at all.

Whether it is actually usable. A page can pass every automated check and be completely impractical to navigate.

the manual checks worth doing routinely#

Three, each a few minutes, on every significant feature:

1. Unplug the mouse. Navigate the entire flow with Tab, Shift+Tab, Enter, Space, arrows, and Escape. Can you complete the task? Can you always see where focus is? Does focus ever get trapped, or jump somewhere unexpected?

This single test finds more real problems than any automated tool.

2. Zoom to 400%. Browser zoom, at a 1280px viewport. Does content reflow, or does it require horizontal scrolling? Is anything cut off? This is a WCAG requirement and it is failed constantly.

3. Turn on a screen reader for five minutes. VoiceOver on macOS (Cmd+F5), NVDA on Windows. You will be bad at it and that is fine — you are not evaluating your skill, you are listening to whether your page announces anything coherent.

Most developers who do this once are permanently changed by it, because the experience of hearing your own interface read aloud as "button, button, button, link, clickable" is clarifying.

the framing that gets it prioritized#

Not "it is the right thing to do." That is true and it does not survive a prioritization meeting.

It is a legal requirement in many jurisdictions, with an enforcement trend that is going up rather than down, and in the EU the European Accessibility Act now applies to a broad category of consumer-facing digital services.

It is a larger market than most product managers assume. Roughly one in six people has a disability. Not all of those affect software use; enough do.

It overlaps with quality generally. Semantic HTML, keyboard support, and clear focus states make interfaces better for everyone. Keyboard shortcuts are an accessibility feature that power users love.

It is much cheaper to build in than to retrofit. An audit that finds two hundred issues in a shipped product is a quarter of remediation work. Catching them at the component level costs minutes.

the single highest-value practice#

Use semantic HTML.

A <button> is focusable, keyboard-activatable, announced as a button, and works with every assistive technology, for free. A <div onclick> requires you to add a role, a tabindex, key handlers for Enter and Space, and focus styles — and you will get one of them wrong.

The overwhelming majority of accessibility problems in modern web applications come from reimplementing native elements badly. Use the element. It already works.