How to Test Web Accessibility

A high automated score means only that some machine-testable rules did not report errors. Real accessibility testing also asks whether tasks work without a mouse, content remains usable when zoomed, errors are explained clearly, and screen readers can understand page structure.

A high automated score means only that some machine-testable rules did not report errors. Real accessibility testing also asks whether tasks work without a mouse, content remains usable when zoomed, errors are explained clearly, and screen readers can understand page structure.

01 Do Not Treat One Scan as Complete Testing

Some issues are machine-detectable, such as missing labels, low contrast, and conflicting structural attributes. Others require human judgment: a button has a name but the name is meaningless, focus order conflicts with visual order, or an announced error remains impossible to understand.

A more reliable sequence is: use automated scans to remove baseline defects, keyboard and zoom tests to validate operation, screen readers to check semantics, and real assistive-technology users to validate critical workflows. Each layer answers different questions and cannot replace the others.

02 Select Critical Workflows Before Testing

Do not inspect every page evenly starting from the home page. Identify the most important, highest-risk tasks: login, registration, search, payment, forms, file upload, approval, billing, and support.

Prepare normal, error, and empty states for every workflow. Products often test correct entry and successful submission while ignoring whether users can recover from form errors, expired sessions, or insufficient access.

03 Layer One: Automated Scans for Baseline Defects

Run automated tools at page and component levels and add them to continuous integration, while reviewing every result instead of pursuing “zero errors” mechanically.

Automated scans should cover:

• Whether page language, title, and primary regions are defined;
• Whether images have purpose-appropriate text and decorative images are ignored;
• Whether form controls have accessible names;
• Whether headings, lists, and tables have sound structure;
• Whether text-to-background and control-to-background contrast meets the target level;
• Whether ARIA attributes are invalid, conflicting, or reference nonexistent elements;
• Baseline defects such as duplicate IDs, empty links, and empty buttons.

A tool report is a clue. The presence of an alt attribute does not mean the description is useful; “Click here” may pass some rules while lacking context.

04 Layer Two: Complete Tasks With Keyboard Only

Remove the mouse or keep your hand off the trackpad and begin from the browser address bar. At minimum, check:

Do not press Tab a few times and stop. Complete the full task, including menus, edits, error triggers, cancellation, and dialog close.

05 Layer Three: Zoom, Reflow, and Non-Color Communication

Zoom to 200% and check that text, controls, and content remain usable. At a narrow viewport, confirm reflow and avoid simultaneous horizontal and vertical scrolling. For data tables that truly require horizontal movement, preserve row and column relationships and critical actions.

Temporarily ignore color. State, error, required, and selected cannot rely on red versus green, shade, or colored blocks. Add text, icons, shapes, or structural position, and verify high-contrast mode.

06 Layer Four: Forms and Error Recovery

Forms concentrate accessibility barriers. Intentionally omit fields, enter invalid formats, and submit duplicate data, then observe:

• Whether labels remain visible instead of relying on placeholders;
• Whether required fields are explained before entry;
• Whether errors are associated with specific fields;
• Whether focus or an error summary leads users to problems after submission;
• Whether messages explain how to fix the problem instead of saying only “Invalid input”;
• Whether autosave, timeouts, and CAPTCHA have usable alternatives;
• Whether correctly entered values remain after an error.

07 Layer Five: Validate Semantics With a Screen Reader

You do not need to test the entire site first. Choose one or two common combinations that match the audience and focus on critical tasks.

A Reusable Test Script

1. Do not read every word; inspect structure through headings or regions.

2. Find the primary navigation and current page title.

3. Locate the key form or data region.

4. Complete one successful submission.

5. Create and repair an error.

6. Open a dialog, menu, or expanded row and confirm the state change is announced.

7. Return to the original position and continue.

Record more than whether it is “readable.” Ask whether the announced name, role, state, and value support the next decision. An icon control announced only as “Button” is focusable but unusable.

08 Layer Six: Test Critical Workflows With Real Users

Internal teams find many problems but cannot replace people who regularly use screen readers, voice control, magnification, or other assistive technology. High-risk products, public services, and core transactions should include relevant users on their own devices and settings.

Real-user testing is especially valuable for complex tables, charts, drag-and-drop, custom editors, identity verification, long forms, and cross-page workflows.

09 Write Defects Engineering Can Fix

An accessibility defect should include:

Do not paste only a rule number. Engineering needs the task context and whether a fix might affect other components.

10 Prioritize Blockers, Then Coverage

JVDS recommends priority by user impact:

• Blocker: a critical task cannot be completed and no alternative exists;
• High: core information is unintelligible, focus is lost, or errors cannot be repaired;
• Medium: the task completes, but efficiency and comprehension cost rise substantially;
• Improvement: local consistency, redundant announcements, or noncritical experience issues.

Also assess component coverage. An accessible-name issue in a shared button may seem minor on one page but appear hundreds of times, so fix it in the design system first.

11 Minimum Pre-Launch Acceptance Checklist

• Critical tasks pass automated scans with no unexplained severe issue;
• Full workflows work by keyboard only, with visible, persistent focus;
• Content remains readable and operable at 200% zoom and narrow widths;
• Form labels, requirements, errors, and success feedback are perceivable;
• States do not depend on color alone;
• Page titles, heading hierarchy, regions, and link names are meaningful;
• Screen readers understand key components and dynamic changes;
• Repairs receive regression tests and shared components are updated.

Frequently Asked Questions

Must accessibility testing wait until development is finished?

No. Information architecture, color, focus order, copy, and component behavior can be checked in design and prototypes. Semantic markup, keyboard implementation, and assistive-technology compatibility require a working version. Earlier discovery costs less.

Is one automated tool enough?

Tools vary and can be combined, but more tools do not replace manual review. Deduplicate findings, confirm impact, and establish stable regression tests.

Must every project meet exactly the same standard?

Define applicable laws, industry requirements, and the target level, but minimum compliance does not guarantee usable critical workflows. Evaluate formal conformance in the real task and audience.

12 Put Research and Design Into Product Decisions