Accessibility testing checklist (2026)

TL;DR

A useful accessibility testing checklist combines automated rules with keyboard, screen reader, zoom, contrast, form, motion, and mobile checks. Prioritize blocked tasks and missing information, map findings to requirements, and retest the complete user journey after fixes.

Key Takeaways

• Start with keyboard operation, visible focus, names, roles, states, headings, forms, contrast, zoom, and reflow.
• Use WCAG success criteria as traceable requirements, while testing real tasks with representative assistive technology.
• Automated scanners find valuable rule violations, but they cannot judge usability, logical reading order, or meaningful text.
• Test component states and complete journeys, including errors, loading, dialogs, notifications, and session limits.
• Record the user impact, affected criterion, reproduction steps, evidence, and recommended behavior in every defect.
• Make accessibility part of design review, component acceptance, continuous integration, and release decisions.

An accessibility testing checklist helps a QA team determine whether people with visual, hearing, motor, speech, and cognitive disabilities can complete important tasks. Begin with keyboard access, programmatic names and roles, visual presentation, form instructions, errors, zoom and reflow, then test critical journeys with assistive technology. A scanner is useful evidence, but it is not a verdict on accessibility.

This guide turns that principle into a practical 2026 workflow. It is written for testers working on web applications, responsive sites, and component libraries. The checklist supports WCAG-based work without pretending that conformance can be reduced to a single score. Your product, applicable policy, supported platforms, and organization must define the formal target.

TL;DR

1. Accessibility Testing Checklist Scope and Test Strategy

Define the target before opening a scanner. Identify the applicable accessibility standard and level, product surfaces, supported browsers, devices, languages, user roles, and assistive technologies. For many web teams, WCAG provides the technical success criteria, but legal obligations and procurement rules depend on product context and jurisdiction. QA should trace to the approved requirement rather than make a legal conclusion.

Inventory user journeys, not just pages. Registration, sign-in, search, purchase, document upload, settings, consent, help, and logout may cross several routes and dynamic states. Rank them by user impact, business criticality, usage, change frequency, and known component risk. Include public pages, authenticated application screens, transactional email, generated documents, and embedded third-party content when they are in scope.

Create a coverage matrix with each journey on one axis and accessibility concerns on the other. Include keyboard, focus, semantics, headings, landmarks, text alternatives, color and contrast, resize and reflow, forms, errors, status messages, time limits, motion, media, language, and mobile gestures. Record which checks are automated, manual, assistive-technology based, or require specialist review.

Choose representative combinations instead of claiming every possible device. A reasonable project matrix might include current Chromium, Firefox, and WebKit-based experiences, plus the screen reader and browser combinations that the organization formally supports. Test operating-system settings such as increased text size, reduced motion, forced colors, and display scaling. State gaps clearly so a pass does not imply untested combinations.

2. Keyboard Accessibility Testing and Focus Order

Disconnect the mouse and complete every critical journey using the keyboard. On a typical desktop web interface, use Tab and Shift+Tab to move, Enter or Space to activate according to control semantics, arrow keys inside widgets that define them, and Escape where a dismissible layer supports dismissal. Do not require every custom control to respond to every key. Compare behavior with the established pattern for that widget.

Every interactive element must receive focus unless an intentional composite-widget pattern manages descendants. Focus order should follow the meaningful reading and operation sequence. Watch for focus moving into hidden content, skipping an action, looping unexpectedly, or returning to the browser chrome. A visually rearranged CSS grid can create a mismatch between the displayed order and DOM order. Test at narrow and wide viewports.

Visible focus must remain distinguishable against adjacent colors and must not be clipped by overflow, sticky headers, or overlays. Check controls in default, hover, focused, selected, disabled, error, and high-contrast states. A global outline: none declaration is a severe warning. A replacement focus style is acceptable only when it stays clear across themes and backgrounds.

When a dialog opens, focus should move to an appropriate location inside it, keyboard interaction should remain within the modal context, and closing should usually restore focus to the invoking control. When content is inserted or removed, focus should not disappear or jump without reason. Skip links should become visible on focus and move to the intended main region. Document the exact key sequence in defects because a vague note such as "keyboard issue" is difficult to reproduce.

3. Semantics, Structure, Names, Roles, and States

Inspect the page as an accessibility tree, not only as pixels. Native HTML elements usually provide stronger semantics and keyboard behavior than generic elements with click handlers. Confirm that buttons are buttons, navigation is navigation, form controls have associated labels, lists are structured as lists, and data tables expose header relationships. ARIA can express necessary semantics, but it does not repair missing behavior or poor content.

Every control needs an accessible name that describes its purpose. Compare the programmatic name with the visible label. Icon-only actions such as search, close, edit, or delete need a meaningful name, and repeated controls may require context such as "Delete invoice 1042." Avoid names that expose file names, framework terms, or unrelated tooltip text. Images that convey information need equivalent text, while decorative images should be ignored by assistive technology.

Check roles and states during interaction. An expandable control should expose whether it is expanded, a checkbox should expose its checked state, a tab should identify selection, and a validation error should be associated with its field. Test state changes rather than inspecting only the initial DOM. Confirm that hidden or inert content is not accidentally exposed and that visible content is not incorrectly hidden.

Headings should describe sections and form a useful outline. Heading levels need not be mechanically perfect, but skipped levels and styling-only headings often make navigation confusing. Landmarks such as header, navigation, main, complementary, and footer should divide the page without excessive or duplicate unnamed regions. Set the page language, identify meaningful language changes, and give each route a specific title. The manual testing interview questions guide can help testers practice explaining these observation and evidence skills.

4. Visual Contrast, Color, Zoom, Reflow, and Text Spacing

Test text and meaningful graphics against their actual backgrounds in every theme and state. Use a contrast analyzer with sampled or computed colors, then confirm gradients, images, transparency, antialiasing, and overlays visually. Placeholder text, disabled controls, charts, focus indicators, validation borders, icons, and visited links are frequently missed. Follow the project requirement for the exact WCAG contrast thresholds rather than memorizing one ratio for all content.

Never rely on color alone to communicate status or required action. A red border may supplement an error icon and message, but cannot replace them. Charts need labels, patterns, direct values, a data table, or another equivalent. Links inside paragraphs must be distinguishable in context, including when color perception or forced-color settings change the presentation.

At 200 percent browser zoom, content should remain readable and operable without overlap, clipping, or loss of controls. At the reflow viewport defined by the requirement, avoid two-dimensional scrolling except where the content genuinely requires it, such as a complex map or data table. Test browser zoom, responsive resizing, and operating-system text scaling separately because they can expose different failures.

Apply increased text spacing through a bookmarklet, browser tool, or controlled stylesheet and inspect clipped labels, fixed-height buttons, overlapping cards, and truncated validation text. Do not accept a tooltip as the only way to reveal essential clipped content because touch and keyboard users may not reach it. Test dark mode, high contrast or forced colors, 400 percent zoom for content that must support it, and both portrait and landscape layouts. Record the settings and viewport in evidence so developers can reproduce the exact condition.

5. Forms, Authentication, Errors, and Status Messages

Forms deserve journey-level testing because small accessibility failures can block account creation, payment, applications, and support requests. Every input needs a persistent, programmatically associated label. Placeholder text may demonstrate format, but it should not be the only label or instruction. Associate helper text and constraints when users need them before submission. Group related choices with an appropriate group name.

Test required, optional, minimum, maximum, format, and cross-field rules. Trigger one error and several errors. The message should identify the field, explain the problem in plain language, and suggest recovery when the correction is not obvious. Move or manage focus intentionally after submission, and provide an error summary for long forms when it improves recovery. Ensure screen readers are informed without announcing the same message repeatedly.

Status messages such as "Saved," "Three results found," or "Upload complete" may need programmatic announcement when focus does not move. Test slow responses and repeated operations. Overly assertive live regions can interrupt users, while silent updates leave them uncertain. Choose the least disruptive mechanism that communicates the result.

Authentication should support password managers and paste where appropriate. Do not create memory tests or inaccessible puzzles as the only path. Check session timeout warnings, extension controls, reauthentication, and preservation of entered data. CAPTCHA and third-party identity flows require equivalent accessible paths and must be tested as integrated experiences. Validate field behavior with voice input and speech-friendly visible labels when those combinations are supported. A useful companion is the exploratory testing techniques guide, which shows how to vary state and workflow beyond scripted happy paths.

6. Screen Reader Testing Guide for Critical Journeys

Screen reader testing is task-based. Learn the supported reader's core commands, then begin from a known state with a documented browser and operating system. Navigate by headings, landmarks, controls, form fields, links, and tables before following the normal reading sequence. Listen for purpose, structure, state, required information, and changes. Do not judge the product only by whether every visible word is spoken.

Run a short orientation pass first. Can the user identify the page, locate main content, understand available regions, and find the primary task? Then complete a journey without looking at the screen as much as practical. Verify that accessible names match visible language, repeated links make sense in context, custom widgets announce role and state, and focus follows interaction. Check browse or reading mode and forms or focus mode when the reader uses them.

For tables, identify the caption or purpose, navigate headers and cells, and verify that row and column context is available. For dynamic applications, test route changes, loading, errors, notifications, expanded content, and virtualized lists. A visually updated single-page application may need a deliberate title change or announcement, but adding live regions everywhere usually creates noise.

Use representative combinations because behavior can differ between screen readers and browsers. A workaround that helps one pair can harm another. Separate product defects, browser defects, assistive-technology behavior, and tester learning errors through reduced examples and comparison. Screen reader output is evidence, not the entire requirement. The strongest finding connects that output to a task impact, such as being unable to identify which shipping method is selected.

7. Images, Media, Documents, Motion, and Timing

Classify images by purpose. Informative images need concise equivalent text. Functional images need a name that describes the action or destination. Decorative images should not add noise. Complex charts, diagrams, and infographics need a nearby explanation or structured data that conveys the same important relationships, not a paragraph that merely repeats the title. Avoid putting essential text inside images when real text can provide better scaling and personalization.

Prerecorded video with meaningful audio generally needs accurate captions, and meaningful visual information may need audio description or an equivalent. Audio-only content needs a transcript when required. Check caption synchronization, speaker identification, sound cues, terminology, and player keyboard operation. Automatically generated captions require human review because a caption track can exist while still being unusable.

Generated PDFs, tickets, reports, and statements are separate outputs. Inspect tags, title, language, heading structure, reading order, tables, link text, form fields, and document security settings. A web page cannot compensate for an inaccessible document that users must download. Include document generation in regression coverage when templates or libraries change.

Animation should respect reduced-motion preferences where the requirement applies, especially for parallax, zoom, flashing, and movement triggered by interaction. Users must be able to pause, stop, or hide certain moving content. Avoid content that flashes at unsafe rates. Test carousels for keyboard control, pause behavior, focus stability, and announcements. For time limits, verify warning, extension, and exception behavior. Media autoplay, session expiry, and timed quizzes each carry different user and business constraints, so test the approved design rather than applying a generic timer rule.

8. Mobile and Responsive Accessibility Testing Checklist

Mobile accessibility includes more than shrinking a desktop browser. Test native screen readers when a mobile app or mobile web experience is supported. Explore by swipe order, touch exploration, headings, controls, and rotor or navigation categories. Confirm that custom gestures have simpler alternatives and that actions do not depend only on path-based movement, multipoint gestures, or device motion.

Touch targets need enough size and separation under the selected requirement. Test dense headers, calendar controls, map pins, dismiss icons, and inline validation actions. Rotate the device unless orientation is essential. Increase platform text size and display scaling, then check loss of content, clipped navigation, horizontal overflow, and controls that move off screen. On-screen keyboards must not cover the focused field, error, or submit control.

Verify accessible names, roles, hints, values, and state for native or hybrid controls. Reading order can differ from visual layout when containers or accessibility properties are misconfigured. Test bottom sheets, drawers, alerts, permission prompts, web views, share sheets, and transitions between application and operating-system UI. Deep links and authentication redirects should restore understandable focus and context.

Responsive web checks still include keyboard at narrow widths because users may zoom a desktop browser or use an external keyboard with a tablet. Hover-only content needs another discovery path. Pointer cancellation and drag operations need careful coverage. Test both coarse and fine pointers, screen magnification, reduced motion, color schemes, and forced-color modes where available. Keep device, OS, browser, orientation, text setting, and assistive technology in the result.

9. Accessibility Automation With Playwright and axe-core

Automate deterministic checks at stable states, but preserve manual testing for meaning and usability. Good candidates include missing accessible names, invalid ARIA relationships, certain contrast violations, duplicate IDs where relevant, document language, and component-specific contracts. Run checks after important state transitions, not only on the home page. Suppress a rule only with an owner, reason, narrow scope, and review date.

The following Playwright test uses the supported @axe-core/playwright builder. In an empty Node project, run npm init -y, npm install -D @playwright/test @axe-core/playwright, and npx playwright install chromium. Save the test as accessibility.spec.js, add "type": "module" to package.json, then run npx playwright test accessibility.spec.js.

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('example page has no automatically detectable violations', async ({ page }) => {
  await page.setContent(`
    <html lang="en">
      <head><title>Newsletter</title></head>
      <body>
        <main>
          <h1>Newsletter</h1>
          <form>
            <label for="email">Work email</label>
            <input id="email" name="email" type="email" required>
            <button type="submit">Subscribe</button>
          </form>
        </main>
      </body>
    </html>`);

  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

A zero-violation result does not prove that "Work email" is the correct business label, focus order is logical across a real application, error recovery works, captions are accurate, or a task is usable with a screen reader. Pair the gate with component keyboard tests and a manual journey schedule. Publish raw rule details as diagnostic artifacts, not a misleading percentage score.

10. Defect Reporting and Release Decisions for an Accessibility Testing Checklist

Write findings around user impact. A strong title is "Keyboard focus moves behind the payment dialog, blocking checkout," not "WCAG focus issue." Include environment, user role, preconditions, exact key or assistive-technology commands, actual result, expected behavior, frequency, affected components, screenshots or short video, accessibility tree evidence, and the relevant success criterion. Remove sensitive data from recordings.

Severity combines task impact, reach, frequency, workaround quality, and affected population. A keyboard trap in account payment can be release-blocking even if only one page is affected. Repeated heading-level problems may have broader reach but lower immediate severity. Do not calculate severity solely from a scanner label. Align with the team's defect policy and explain the impact.

Retest the specific fix, component variants, surrounding focus sequence, and complete journey. Accessibility fixes can introduce regressions, such as duplicate announcements, invisible focus, or an ARIA role that removes native semantics. Add stable regression coverage at the lowest effective layer, then keep periodic manual checks because automation cannot preserve every behavior.

Release reporting should state target, scope, environments, combinations, passed journeys, open issues by impact, accepted exceptions, untested risks, and owners. Avoid an unconditional "accessible" badge based on one scan. A defensible conclusion is bounded, such as: critical checkout journeys passed the documented keyboard and screen reader checks, with two known moderate issues and one untested document export.

Interview Questions and Answers

Q: Why is automated accessibility testing insufficient?

Automation can detect rule patterns in rendered code, but it cannot reliably judge meaningful alternative text, logical reading order, clear instructions, sensible focus movement, caption accuracy, or whether a complete task is usable. I use automation for repeatable breadth and manual assistive-technology testing for intent and interaction.

Q: How would you prioritize an accessibility regression suite?

I prioritize critical journeys, shared components, legal or contractual requirements, and defects with severe user impact. Fast semantic rules and component keyboard tests run on changes, while representative screen reader, zoom, and mobile journeys run on a defined cadence and before high-risk releases.

Q: What do you check in a modal dialog?

I check its accessible name, initial focus, keyboard containment, reading context, close methods, background interaction, Escape behavior when supported, error states, and focus restoration. I also check zoom, narrow viewports, and nested popovers because clipping and focus loss often appear there.

Q: How do you test a form error?

I trigger errors by keyboard and assistive technology, verify visible and programmatic identification, confirm the message explains recovery, and check association with the field. For multiple errors, I assess the summary, focus strategy, preservation of values, and repeated submissions.

Q: What makes an accessibility defect report useful?

It connects a reproducible behavior to a user task and expected outcome. It includes the exact environment and commands, programmatic evidence, affected requirement, severity rationale, and enough context to retest without prescribing a brittle implementation.

Q: What is the first manual accessibility test you perform?

I usually perform a keyboard-only pass through a critical journey because it quickly exposes unreachable controls, poor focus visibility, broken order, traps, and custom-widget problems. I then inspect semantics and run targeted screen reader and visual adaptation checks.

Common Mistakes

• Treating an automated score as proof of conformance or usability.
• Testing only a static page while ignoring dialogs, errors, loading, route changes, and completed workflows.
• Applying ARIA roles without implementing the keyboard behavior and state management the pattern requires.
• Recording a criterion number but omitting the blocked user task and exact reproduction commands.
• Using one screen reader and browser result to make claims about every platform combination.
• Checking normal contrast while missing hover, focus, disabled, placeholder, forced-color, and dark-mode states.
• Fixing the reported node without retesting the shared component, surrounding focus sequence, and journey.
• Postponing accessibility until release, when design, content, and architecture changes are most expensive.

Build accessibility into stories, design reviews, component contracts, test data, and the definition of done. The risk-based testing guide provides a useful model for choosing depth when time and device coverage are limited.

Conclusion

A durable accessibility testing checklist combines requirements, user journeys, automation, keyboard operation, semantics, visual adaptation, assistive technology, and evidence-based release decisions. It asks whether people can perceive, understand, navigate, operate, and recover, not whether a scanner produced a reassuring number.

Start with one critical journey. Document its keyboard path, names and states, form recovery, zoom and reflow behavior, and screen reader outcome. Automate stable rules, report remaining risks honestly, and expand the checklist through shared components and production learning.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Building an accessibility test checklist (2026)
• Accessibility Testing Basics for QA
• Accessibility testing with Cypress (2026)
• Accessibility testing with Playwright (2026)
• Testing keyboard navigation (2026)
• Testing with a screen reader (2026)