WebView · mobile web · desktop web
Development
WCAG
The reference point for accessible web apps is still the W3C Web Content Accessibility Guidelines (WCAG).
Its success criteria come in three conformance levels:
- Level A — the floor: basic, easy-to-meet requirements;
- Level AA — enough accessibility for the majority of people with disabilities;
- Level AAA — advanced and often specialized requirements.
Level AA is the baseline you ship. It covers the largest share of critical, commonly encountered barriers, and it is the bar most policies and procurement checklists assume.
Maps that make it easier to navigate specific criteria per level:
ARIA
ARIA attributes are a semantic extension of HTML markup that makes your UI legible to assistive technology. The reasoning behind them lives in its own specification.
Working with ARIA comes down to four rules:
- If you can avoid ARIA, avoid it. Proper semantic markup wins. Native
<button>,<a>,<label>, real headings, lists, tables, and visually hidden text (a.visually-hiddenclass, for example) work far better with assistive technology than a pile ofaria-*attributes. - Do not override native semantics unless you genuinely have no alternative.
- Every interactive ARIA control must be keyboard-operable.
- Never put
role="presentation"oraria-hidden="true"on a focusable element.
APG patterns
For complex widgets — menus, tabs, dialogs, accordions, carousels, comboboxes, sliders, and friends — follow the established markup and keyboard patterns from the ARIA Authoring Practices Guide (APG).
WAI tutorials
When you are building a specific component, go to the official material from the W3C Web Accessibility Initiative (WAI), the part of the W3C dedicated to accessibility:
Practical WAI guides:
- General development advice: WAI Tips
- Quick manual checks: Easy Checks
Component libraries and UI kits
The best accessibility advice is usually the least glamorous: reach for a mature component library that has already worked through the ARIA, focus, and screen reader details.
Popular UI kits with accessibility out of the box:
These libraries typically handle focus management for you (focus-lock / focus-trap), get the semantics and ARIA right, and have been tested against the mainstream screen readers. Roll your own components and you own all of that — the mechanics, the rules, and the screen reader testing.
Many of these kits also ship dedicated accessibility helpers. Chakra UI, for instance, has SkipNavLink for skipping navigation and VisuallyHidden for hiding text visually while keeping it available to screen readers.
Testing and debugging
Automated scanners find only 30% to 60% of accessibility issues in an application, so manual testing and debugging are unavoidable.
axe-core automatically detects an average of 57% of WCAG issues. Source: dequelabs/axe-core
Checking accessibility by hand with real assistive technology is critical — it is the only way to judge the actual experience of users with disabilities.
Test with screen readers, without exception:
- Mobile:
- Android: TalkBack (preinstalled)
- iOS: VoiceOver (preinstalled)
- Desktop:
- NVDA (Windows) — free, and the most popular option among testers
- JAWS (Windows) — commercial, widespread in enterprise environments
- VoiceOver (macOS) — built into the system
- Less common, but still worth a pass:
- Orca (Ubuntu / Linux)
- Narrator (Windows) — the built-in basic reader
For current usage numbers, see the WebAIM Screen Reader User Survey.
Audit tools
The best accessibility audit tool on the market is Deque axe, available as a DevTools extension.
Useful companions:
- WAVE by WebAIM — an online service for checking semantics, content structure, tab order, and contrast
- Colour Contrast Analyser (CCA) by Vispero/TPGi — a desktop app that makes it easy to sample contrast anywhere on screen
- Sim Daltonism — a macOS app for reviewing color and contrast through various color vision deficiencies (built-in alternative on iOS/macOS: Settings → Accessibility → Display & Text Size → Color Filters)
Other popular accessibility scanners:
- Lighthouse (Accessibility section) — built into Chrome DevTools
- WebHint (Accessibility hints, running the same Deque axe engine under the hood)
Static analysis
The cheapest way to automate accessibility checks at the code level is static analysis. Nearly every popular linter offers a solid set of baseline accessibility rules. At the very least you reach a state where no image ships without alt text and no div or span sneaks through with an onClick handler and no matching semantic role.
The most common linters and their accessibility rule sets:
- ESLint — eslint-plugin-jsx-a11y
- Oxlint — jsx-a11y settings
- Biome — a11y rules
Tests and automation
CI/CD
A pricier, more resource-hungry option is auditing pages directly in your CI/CD pipeline. Both Deque axe and Lighthouse plug in there:
Runtime
In a test environment or during local development you can run axe-core programmatically and print audit results straight to the console:
if (isDevEnv() || isStageEnv()) {
// Let the app settle after re-renders so axe reports fewer false positives
const AXE_DEBOUNCE_MS = 6000;
void Promise.all([import('@axe-core/react'), import('react-dom')]).then(([axe, ReactDOM]) => {
axe.default(React, ReactDOM, AXE_DEBOUNCE_MS);
});
}End-to-end tests
The more pragmatic move is to put accessibility checks inside the automated tests you already run — almost every popular framework exposes an API for it:
- Playwright
- Cypress
- WebdriverIO
Unit tests
Whatever runner you configure your JavaScript unit tests with, reach for Testing Library — it is built accessibility-first.
Its API nudges you toward correct semantics and markup on its own: queries like getByLabelText, getByRole, and getByAltText test the component and, as a side effect, its accessibility.
AI integration and agents
AGENTS.md
If AI agents touch your UI code, spell out your accessibility coding rules explicitly.
Most LLMs are trained on the open web, and a large share of that web has serious accessibility problems. For inspiration, look at how open source projects write these sections in their AGENTS.md.
Every section of this guide above also makes a decent starting point for drafting those rules.
Agent skills
Skills can be a powerful tool in their own right — both for building accessibility into new code and for auditing an existing codebase.
Example skills:
At Google I/O 2026, Chrome announced Modern Web Guidance — open guides plus a skill pack for AI agents, accessibility guide included. One command to install:
npx modern-web-guidance@latest installIt works with the popular agents: Vercel AI SDK, Claude Code, Copilot CLI, Antigravity CLI, and others. In Cursor you can pull it in as a plugin from the marketplace.
Here is what using it looks like:
npx modern-web-guidance@latest search "create a dialog modal backdrop"Output:
[{"id":"accessibility","description":"Actionable coding guidelines for building accessible web applications, covering semantic HTML, focus management, forms, media, and testing. Use this skill when auditing or implementing accessibility features, keyboard navigation, or ARIA.","category":"accessibility","tokenCount":7129,"similarity":0.5102}]Then pull the guide itself:
npx modern-web-guidance@latest retrieve "accessibility"Related notes
- A practical web accessibility audit in five steps (no dogma)
- Accessibility audit of Priorbank’s web app
- Wildberries accessibility audit. Can a blind user buy the Batmobile?
- Skip links — a quiet mark of good craft
- Web accessibility is not hype — it is responsibility
- The web and tactile typography
- When accessibility features break the design — and sometimes accessibility itself