05 — Accessibility Checklist#

Verify that essential product experiences are perceivable, operable, understandable, and robust for people using a range of input methods and assistive technologies. The intended standard and conformance level must be explicitly defined for each project.

Scope: Frontend-specific. This file is one part of the 05_Accessibility.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

Project / product:
Release / version / environment:
Scope and applicable jurisdictions / markets:
Target standard, version, and level (if applicable):
Supported input devices / assistive technologies:
Reviewer / owner:
Review date:
Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

Copy the shared template into project-specific review records; leave all checkboxes here unchecked.
Select the applicable accessibility standard and evaluation scope before review. WCAG 2.2 Level AA is a useful reference for web projects when appropriate, but legal or contractual requirements may differ.
Mark [x] only after verifying an item with manual tests, automated results, design inspection, user research, or other credible evidence. Record failed items and N/A with a reason in project-specific notes or issues using their A11Y IDs.
Test with representative browsers, devices, and assistive technologies. Automated scanning alone does not demonstrate full accessibility or WCAG conformance.
Complete ## API Checks and ## Frontend Checks separately when relevant. Re-evaluate after significant changes to UI, forms, content, media, or user journeys.

Accessibility goals and target standard#

A11Y-006 Identify supported browsers, operating systems, input devices, screen readers, zoom settings, and other assistive-technology combinations to evaluate.
A11Y-007 Include users with visual, auditory, motor, cognitive, speech, and multiple disabilities when planning representative research.
A11Y-001 Define the accessibility scope by product, platform, version, region, and critical user journey, including authenticated and error states.
A11Y-002 Identify the applicable accessibility standards, legal/contractual obligations, and target conformance level with qualified reviewers when needed.
A11Y-003 Adopt a documented baseline (for example WCAG 2.2 Level AA for applicable web content), including its Level A requirements.
A11Y-004 Map accessibility requirements to user stories, design acceptance criteria, and relevant WCAG success criteria where applicable.
A11Y-005 Assign accessibility ownership across product, design, content, engineering, QA, and third-party integrations.
A11Y-008 Inventory critical templates, components, documents, interactive widgets, media, and external services that need evaluation.
A11Y-009 Specify whether mobile apps, PDFs, kiosks, embedded content, and third-party experiences require a different evaluation standard or method.
A11Y-010 Define pass/fail rules and severity for barriers that prevent completion of important tasks, independently of cosmetic defects.
A11Y-011 Record known accessibility constraints, third-party dependencies, exceptions, accountable owners, and planned remediation in project-specific records.
A11Y-012 Include accessibility acceptance criteria in design and engineering reviews before implementation rather than only at release.
A11Y-013 Set requirements for accessible procurement and vendor-delivered components, documents, and services where applicable.
A11Y-014 Ensure any public accessibility statement or conformance claim is supported by an actual scoped assessment rather than a tool score.
A11Y-015 Plan a repeatable evaluation approach for changing flows, with a representative sample and an issue-resolution process.
A11Y-016 Establish an accessible way for users to report barriers and a responsible path to triage and respond.

Semantic structure and keyboard use#

A11Y-017 Use native HTML elements for buttons, links, forms, tables, and headings wherever their semantics match the function.
A11Y-019 Use a logical heading hierarchy and recognizable navigation, main-content, search, and other landmarks as relevant.
A11Y-021 Preserve meaningful reading order when CSS layouts, responsive rearrangement, or client rendering changes visual position.
A11Y-022 Ensure all functionality is available through a keyboard interface without requiring pointer-only gestures.
A11Y-024 Provide a visible keyboard focus indicator and check that fixed headers, dialogs, or overlays do not obscure it.
A11Y-025 Provide a mechanism to bypass repeated blocks such as global navigation where required.
A11Y-026 Ensure keyboard focus can move into and out of dialogs, menus, popovers, and composite widgets without traps.
A11Y-027 Implement keyboard behavior for custom widgets consistent with the relevant WAI-ARIA Authoring Practices pattern.
A11Y-029 Do not add redundant or contradictory ARIA attributes to native controls; use ARIA only when necessary and valid.
A11Y-034 Ensure focus order, route changes, and error-state transitions remain understandable when content is added dynamically.
A11Y-035 Make keyboard shortcuts discoverable and avoid interfering with native browser or assistive-technology shortcuts.
A11Y-036 Test that hidden, disabled, and offscreen controls are exposed or removed from focus and accessibility trees appropriately.
A11Y-018 Ensure page and view titles describe the purpose or topic of the current content.
A11Y-020 Ensure information and relationships expressed visually remain available as text or programmatic semantics.
A11Y-023 Verify tab order follows the intended interaction and does not produce confusing jumps or inaccessible controls.
A11Y-028 Expose accessible names, roles, values, expanded/selected/checked states, and state changes for interactive components.
A11Y-030 Use descriptive link and button labels whose purpose is clear in context, including image-only controls.
A11Y-031 Do not make essential instructions depend only on position, shape, color, orientation, or sound.
A11Y-032 Provide accessible alternatives to dragging gestures and avoid requiring complex multipoint gestures where not essential.
A11Y-033 Verify pointer target dimensions or adequate spacing meet the chosen WCAG target, with documented exceptions where allowed.

Perceivable and understandable content#

A11Y-041 Provide audio description or another permitted accessible alternative for important visual information in video as required.
A11Y-043 Ensure media-player controls, captions, volume, pause, and transcript access work with keyboard and assistive technology.
A11Y-044 Use sufficient text and non-text contrast under the chosen WCAG criteria and avoid conveying meaning through color alone.
A11Y-045 Allow text to resize and layout to reflow without loss of content or functionality within the applicable WCAG constraints.
A11Y-051 Identify input errors in text and communicate correction guidance that does not rely on color or visual position alone.
A11Y-053 Make navigation and component behavior consistent across related screens and predictable after input or focus changes.
A11Y-059 Ensure status messages and confirmations communicate important outcomes without depending solely on a fleeting visual notification.
A11Y-037 Provide concise alternative text for informative images that conveys their purpose or essential information.
A11Y-038 Mark purely decorative images appropriately so they do not create redundant assistive-technology announcements.
A11Y-039 Ensure charts, diagrams, and complex images have a textual explanation or alternative presenting equivalent essential information.
A11Y-040 Provide accurate captions for prerecorded video with meaningful audio, and live captions when required by the applicable level.
A11Y-042 Provide transcripts or other accessible alternatives for audio-only and other media where the chosen criteria require them.
A11Y-046 Support changes in text spacing without clipped labels, hidden actions, or lost relationships.
A11Y-047 Ensure content remains usable when users prefer portrait or landscape orientation unless a specific orientation is essential.
A11Y-048 Avoid uncontrolled audio, flashing, moving content, and animations that create safety risks or prevent concentration.
A11Y-049 Allow users to pause, stop, hide, or control auto-updating/moving content when required.
A11Y-050 Make visible labels, instructions, and required-field status understandable before users submit data.
A11Y-052 Preserve entered data and provide review, correction, or reversal mechanisms for high-impact submissions where the applicable criteria require them.
A11Y-054 Provide understandable page language and programmatic language changes for localized or multilingual content.
A11Y-055 Ensure instructional content and help are accessible without relying exclusively on images, hover, or inaccessible documents.
A11Y-056 Support accessible authentication without forcing a cognitive-function test when alternatives are required by WCAG 2.2.
A11Y-057 Keep persistent or repeated help mechanisms in a consistent order across relevant pages where required.
A11Y-058 Give users sufficient time to complete tasks and allow extension or adjustment of timed sessions when required.

Assistive-technology evaluation#

A11Y-062 Manually complete critical user journeys using keyboard-only navigation, including errors and recovery.
A11Y-063 Evaluate critical journeys with screen readers and supported browser/operating-system combinations.
A11Y-065 Test zoom, text resizing, text-spacing overrides, and narrow viewport reflow without loss of meaningful content.
A11Y-066 Check display contrast and focus indication using appropriate techniques and not only automated color sampling.
A11Y-060 Define a representative evaluation sample that includes complete processes, shared templates, key states, and higher-risk custom controls.
A11Y-061 Conduct automated accessibility scans across representative pages and components, recording tool versions and known limitations.
A11Y-064 Inspect the accessibility tree for accessible names, roles, state, descriptions, and hidden content of representative controls.
A11Y-067 Test forms for programmatic labels, descriptions, required fields, error association, and recovery after failed submission.
A11Y-068 Test dialogs, popovers, notifications, dynamic lists, route changes, and live regions with manual assistive-technology checks.
A11Y-069 Evaluate captions, transcripts, audio descriptions, and media-player controls when media is present.
A11Y-070 Include user evaluation with people with disabilities when feasible, particularly for critical or complex tasks.
A11Y-071 Inspect third-party widgets and embedded content in the complete user journey rather than assuming vendor conformance.
A11Y-072 Report each finding with applicable criterion, affected context, reproduction steps, user impact, and responsible owner in project-specific records.
A11Y-073 Retest remediated issues with the input methods and assistive technologies that originally exposed them.
A11Y-074 Review the representative sample and criteria after new components, workflows, content types, or platforms are introduced.
A11Y-075 Document assessment scope, methodology, limitations, evaluator, date, and conformance conclusion without claiming universal coverage.

Frontend Checks#

A11Y-091 Use semantic HTML and native controls by default, introducing ARIA only where native semantics do not meet the interface requirement.
A11Y-092 Provide appropriate document titles, visible headings, landmarks, skip links, and a meaningful DOM reading order.
A11Y-093 Verify every control has a useful accessible name and custom controls expose correct role, state, value, and relationships.
A11Y-094 Ensure keyboard-only users can operate all essential functions without focus traps or undiscoverable commands.
A11Y-095 Check logical focus movement and restoration after route transitions, modal dialogs, menus, errors, and removed content.
A11Y-096 Make keyboard focus visible and not obscured; verify focus styles across themes, overlays, and sticky elements.
A11Y-097 Verify meaningful alternative text for images; hide decorative images from assistive-technology output appropriately.
A11Y-098 Verify form labels, autocomplete purposes where applicable, instructions, required states, and error associations.
A11Y-099 Present error summaries and targeted corrections in text, including updates that screen readers can perceive.
A11Y-100 Announce asynchronous status changes through appropriate live regions or other accessible notification patterns without over-announcing.
A11Y-101 Provide keyboard-operable dialogs, tabs, menus, comboboxes, carousels, and sliders using appropriate interaction patterns.
A11Y-102 Check text and graphical contrast, text resize, text spacing, and reflow at the applicable WCAG thresholds.
A11Y-103 Ensure pointer targets, drag interactions, gestures, and hover/focus revealed content have accessible alternatives where required.
A11Y-104 Respect reduced-motion preferences and provide control over moving, flashing, auto-playing, or auto-updating content as appropriate.
A11Y-105 Check responsive behavior, orientation, zoom, touch, and voice-control interaction on the supported devices.
A11Y-106 Ensure critical help, authentication, checkout, and session timeout flows do not introduce avoidable cognitive barriers.
A11Y-107 Confirm language attributes, localization, directionality, and text expansion remain correct after dynamic rendering.
A11Y-108 Verify accessible data tables expose headers, captions where appropriate, and relationships rather than only visual grid formatting.
A11Y-109 Ensure video/audio playback controls, captions, transcripts, and descriptions are available and operable when relevant.
A11Y-110 Test screen-reader and keyboard interactions with client-side routing, hydration, form validation, and dynamic content updates.
A11Y-111 Prevent hidden or inactive content from remaining in the focus order, and do not hide active controls from accessibility APIs.
A11Y-112 Run automated plus manual regression checks for shared components and priority user flows before release.

Release gate#

The evaluation scope, target standard/version/level, supported environments, and accountable reviewer are recorded.
Critical end-to-end workflows have been evaluated with keyboard access and appropriate assistive technologies, not only an automated scan.
Required accessible names, semantic structure, focus management, alternatives to non-text content, and form error recovery have been verified where relevant.
API-fed content and frontend components preserve accessibility information and handle asynchronous changes and errors accessibly where applicable.
No unresolved accessibility issue blocks an essential task or applicable mandatory criterion without explicit review and an authorized, documented remediation decision.
Findings, evaluation limits, responsible owners, retest outcomes, and final decision are documented in project-specific records.

Domain-specific approval rule: Do not claim WCAG conformance or legal compliance without an appropriately scoped assessment against all applicable criteria. Block release approval for unresolved barriers that prevent essential user tasks, or for unaccepted mandatory conformance failures; escalate jurisdiction-specific exceptions to qualified approvers.

Trusted references and scope#

These checks translate authoritative W3C materials into review questions; they are not a substitute for the full standard, its normative conformance rules, or professional evaluation.

W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — normative success criteria and conformance requirements.
W3C WAI — What's New in WCAG 2.2 — new focus, dragging, target-size, authentication, and help criteria.
W3C WAI — WCAG Quick Reference — technology-independent success criteria and supporting techniques.
W3C — WCAG Evaluation Methodology (WCAG-EM) 2.0 — defining evaluation scope, sampling, assessment, and reporting; guidance, not additional WCAG requirements.
W3C WAI — ARIA Authoring Practices Guide — accessible custom widgets, naming, states, and keyboard patterns.
W3C WAI — Accessible Names and Descriptions — appropriate control names and descriptions, with preference for native elements.
W3C WAI — Forms: Validating Input — accessible error messages, correction, and input validation.
W3C WAI — Images Tutorial — informative, functional, and decorative image alternatives.
W3C WAI — Planning Accessible Audio and Video Media — captions, transcripts, audio descriptions, and media controls.

Applicability: Web, native mobile, documents, kiosks, and embedded products can require distinct standards or evaluation methods. WCAG 2.2 Level AA is a suggested web baseline, not a declaration of universal legal applicability. WCAG-EM 2.0 was published in July 2026 and describes an evaluation process; it does not add normative success criteria.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

Test focus: keyboard navigation, focus order, accessible names, contrast, and assistive-tech flows; include browser and client behavior where applicable.
Cross-stack: axe DevTools + WAVE.
Python: Playwright + pytest; for pytest-based suites, run python -m pytest -q.
TypeScript: @axe-core/playwright + Playwright + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
JavaScript: @axe-core/playwright + Playwright + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

wcag-audit-patterns — Assess WCAG-oriented requirements and gaps (wshobson/agents, 42,437 repo stars).
screen-reader-testing — Plan and execute assistive-technology checks (wshobson/agents, 42,437 repo stars).
web-design-guidelines — Review accessible interface design patterns (vercel-labs/agent-skills, 33,937 repo stars).

How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.