Accessibility testing works best as a mix of automated checks and manual review. Automated tools can quickly find some code-level problems, but they cannot tell you whether a person can complete an important task with a keyboard, screen reader, magnification, or other assistive technology.
Use this guide to build a repeatable accessibility check into development and release work. It is not a legal-compliance certification: a tool score, checklist, or single test cannot establish that a site meets every applicable obligation.
Start with a current accessibility target
The Web Content Accessibility Guidelines (WCAG) 2.2 are a useful technical reference for web content. The earlier WCAG 2.1 recommendation linked in the original guide remains available, but use WCAG 2.2 when setting a new test plan. Choose the conformance level and requirements that fit your product and jurisdiction; legal obligations differ, and this guide is not legal advice. The US Department of Justice's web accessibility guidance explains the ADA context for businesses and state and local governments.
Before running tools, use the W3C's Easy Checks for a quick first look at page titles, headings, image text alternatives, contrast, and keyboard access. These checks help uncover obvious barriers; they do not replace a full evaluation.
Where automated tools help
An automated checker can flag certain detectable issues, such as missing accessible names, invalid ARIA attributes, and some color-contrast failures. Add checks to representative page templates and important flows, and run them again after significant changes.
- axe-core is an open-source accessibility testing engine that can be used in browser checks and automated test suites.
- Storybook's accessibility testing can help teams catch issues while building and reviewing individual components.
- eslint-plugin-jsx-a11y provides lint rules for common accessibility patterns in JSX. It checks source patterns, not the complete experience rendered in a browser.
- Browser extensions and services such as Accessibility Checker can be useful for an initial scan. Treat any score as a tool-specific summary of detected checks, not a measure of legal risk or proof of compliance.
For related frontend development tools and references, browse our JavaScript resources.
Automated findings are leads to investigate, not a pass/fail verdict for the whole site. A clean report does not mean every issue has been found; do not rely on a universal percentage for how much automation can detect.
A practical manual testing workflow
Test a representative set of pages and the complete tasks that matter to your users. Include shared components and states such as menus, dialogs, validation messages, loading states, and errors.
1. Navigate with a keyboard
Put the mouse aside and try the page with a keyboard:
- Use Tab and Shift+Tab to reach interactive controls in a sensible order.
- Confirm that the current focus is visible and is not hidden behind sticky headers, dialogs, or other content.
- Use Enter and Space on links and buttons; check arrow-key behavior for widgets that use it.
- Open and close menus and dialogs, and check that focus moves into them, stays usable, and returns to the trigger when they close.
- Look for a way to skip repeated navigation and reach the main content.
If an essential task cannot be completed without a mouse, record the exact step and control where it fails.
2. Check text resizing and reflow
Increase browser zoom and text size. Text should remain readable at 200% without losing content or functionality. Also test a narrow viewport equivalent to 320 CSS pixels; at that width, ordinary content should reflow without requiring two-direction scrolling. Some content, such as a data table, may need its own accessible scrolling treatment.
See the WCAG explanations for Resize Text and Reflow for the criteria and their exceptions. Check that dialogs, forms, navigation, and fixed-position elements still work at these sizes.
3. Review names, structure, and feedback
Inspect the page with a screen reader, especially around navigation, forms, and dynamic updates. Check that:
- Headings and landmarks provide a useful structure.
- Links and controls have names that describe their purpose.
- Form fields have associated labels, and errors identify the affected field and explain how to fix the problem.
- Important status changes are announced, and meaning is not conveyed by color alone.
- Custom controls expose their role, name, value, and state, and work with the keyboard.
Try the screen reader and browser combinations that your audience uses. Automated snapshots and a quick screen-reader pass are useful, but neither substitutes for evaluating a real task with people who use assistive technology, especially for complex workflows.
4. Check contrast and focus
Verify text and interface contrast rather than judging it by appearance alone. WCAG's minimum contrast guidance gives the applicable ratios and exceptions. Also check that focus indicators and selected, disabled, and error states remain distinguishable. Do not use color as the only way to communicate required information.
5. Record, fix, and retest
For each finding, record the page or component, steps to reproduce, expected behavior, actual barrier, and who is affected. Prioritize blockers in essential tasks, then fix shared components before individual pages. Re-run the automated checks and repeat the manual steps after a fix so that a correction has not introduced a new problem.
Keep the checks close to the code: lint JSX where relevant, run automated tests for reusable components and critical flows, and include keyboard, resizing, and assistive-technology review in release work. Accessibility is ongoing maintenance, not a one-time scan.
Cover photo by Bich Tran from Pexels.