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: Backend / API-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#

1. Copy the shared template into project-specific review records; leave all checkboxes here unchecked.
2. 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.
3. 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.
4. Test with representative browsers, devices, and assistive technologies. Automated scanning alone does not demonstrate full accessibility or WCAG conformance.
5. Complete ## API Checks and ## Frontend Checks separately when relevant. Re-evaluate after significant changes to UI, forms, content, media, or user journeys.

API Checks#

• A11Y-076 Identify API response fields that supply accessible names, descriptions, error messages, language metadata, or media alternatives to user-facing interfaces.
• A11Y-077 Ensure content APIs can provide meaningful alternative text or equivalent descriptions for informative media where the frontend needs them.
• A11Y-078 Supply captions, transcripts, audio-description references, or other media accessibility resources when the product uses them.
• A11Y-079 Provide structured validation errors with stable field references so clients can link corrections to the right controls.
• A11Y-080 Distinguish authentication, authorization, not-found, rate-limit, and service failures so clients can communicate useful recovery instructions.
• A11Y-081 Ensure API-generated messages are understandable, safe to announce, and localized or accompanied by localization keys when required.
• A11Y-082 Provide machine-readable progress, completion, and failure states for asynchronous actions that users must monitor.
• A11Y-083 Expose state, limits, required attributes, and allowable values needed to present dynamic forms or range widgets accessibly.
• A11Y-084 Check that pagination, filtering, and dynamic response updates include enough metadata for accessible result-count and status feedback.
• A11Y-085 Document timeouts, expiry, and renewal behavior so clients can warn users and preserve progress where feasible.
• A11Y-086 Do not rely on color, glyphs, positional information, or undocumented codes as the only explanation in API-provided content.
• A11Y-087 Review accessibility implications of API schema and content changes with client owners before rollout.
• A11Y-088 Verify API-fed lists, tables, headings, and document metadata can be represented with appropriate semantic relationships.
• A11Y-089 Provide stable content identifiers and ordering information needed for meaningful keyboard focus and updates when applicable.
• A11Y-090 Keep accessibility-related fields and examples in the API documentation and contract tests where those fields are part of the public interface.

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 API and service 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 backend / API 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.