Accessibility Field Guide

Accessibility Requirements Checklist

A checklist for turning early accessibility risks into requirements, acceptance criteria, design notes, and QA checks.

Photo: An Architect’s Work Table With Tools and Blueprints via Pexels — https://www.pexels.com/photo/an-architect-s-work-table-with-tools-and-blueprints-6894105/

View full screen Download image

Use this checklist after intake, when the team is turning a request into requirements, acceptance criteria, design notes, or backlog items.

Accessibility requirements do not need to sound complicated. They need to be clear enough that design, development, QA, and review can tell what should happen.

A requirement that only describes the happy path is usually not enough.

The basic test

For each screen, flow, component, document, or vendor tool, ask:

[ ] What does the user need to do?
[ ] What information does the user need before they act?
[ ] What happens if the user makes a mistake?
[ ] What happens if the user cannot use a mouse?
[ ] What happens if the user cannot rely on visual layout alone?
[ ] What does the team need to test before review?

If the requirement cannot answer those questions, it probably needs more detail.

User task and scope

[ ] The main user task is named plainly.
[ ] Required and optional parts of the task are separated.
[ ] The start and end of the flow are clear.
[ ] Decisions, deadlines, consequences, payments, eligibility steps, or account changes are identified.
[ ] Any alternate paths are described.
[ ] Known accessibility risks from intake are carried forward.

[ ] Page titles, headings, and section labels are expected to describe the content clearly.
[ ] Multi-step flows explain where the user is and what comes next.
[ ] Navigation, back, cancel, save, and return behavior is described.
[ ] Modals, tabs, accordions, menus, or other interactive patterns have expected keyboard and focus behavior.
[ ] Content changes after user action are accounted for.

Forms and error states

[ ] Every input has a visible label or clear equivalent.
[ ] Required fields are identified.
[ ] Instructions and formatting rules are provided before submission.
[ ] Error messages identify the field or issue.
[ ] Error messages explain how to fix the problem when possible.
[ ] The user can find the error and recover without starting over.
[ ] Confirmation messages explain what happened and what comes next.

Content clarity

[ ] Button text explains the action.
[ ] Link text explains the destination or purpose.
[ ] Instructions are written in plain language.
[ ] Important meaning is not conveyed by color alone.
[ ] Icons, badges, charts, screenshots, or images have text support when needed.
[ ] Acronyms, policy terms, and internal labels are explained when needed.

Keyboard and focus expectations

[ ] All interactive elements are expected to work with a keyboard.
[ ] Focus is visible.
[ ] Focus order follows the visual and task order.
[ ] Focus does not disappear, jump unexpectedly, or get trapped unless the pattern intentionally manages focus.
[ ] Custom components have expected keyboard behavior documented or linked.

Documents and file handling

[ ] PDFs and documents are identified as part of the user flow when they are required.
[ ] The team knows who owns document accessibility.
[ ] Uploaded documents, generated PDFs, and downloadable forms have accessibility expectations.
[ ] The requirement says whether an HTML alternative is needed.
[ ] File upload instructions and errors are clear.

Vendor and third-party requirements

[ ] Vendor tools are named in the requirement or linked notes.
[ ] Accessibility documentation, VPAT/ACR, or testing evidence is requested when appropriate.
[ ] Configurable content, labels, colors, error messages, and focus behavior are identified.
[ ] Known vendor limitations are documented.
[ ] A fallback or support path is defined if the vendor tool blocks users.

Acceptance criteria starter language

Use plain acceptance criteria like this:

[ ] Users can complete the main task with a keyboard.
[ ] Each form field has a clear label and any needed instructions.
[ ] Required fields are identified before submission.
[ ] Error messages identify the problem and explain how to fix it.
[ ] Focus is visible and follows the task order.
[ ] Link and button text describe the action or destination.
[ ] Important status changes are communicated in text.
[ ] Documents required to complete the task are accessible or have an accessible alternative.
[ ] Vendor components have been reviewed for keyboard access, labels, focus behavior, and error handling.

These are starter criteria, not magic words.

Adjust them to the feature. The best requirement is specific enough that the team can build and test it.

Definition of done

Before the work is treated as ready, the team should be able to say:

[ ] The accessibility expectations are visible in the requirement, ticket, or acceptance criteria.
[ ] Design accounted for labels, headings, focus, errors, content, and states.
[ ] Development used native HTML where possible and documented custom behavior where needed.
[ ] QA has a practical accessibility check to run.
[ ] Known issues, exceptions, vendor limits, or follow-ups are documented.
[ ] Review materials can be prepared without guessing how the feature works.

Turn common interaction risks into requirements

Use the interaction route when requirements need to describe behavior, not just screens:

Labels, instructions, required fields, and field groups: Forms and Labels
Validation, error text, and recovery paths: Error Messages and Recovery
No-mouse operation and keyboard traps: Keyboard-Only Navigation
Visible focus and logical tab order: Focus Visible and Focus Order

If the requirement is hard to test, rewrite it until someone can use Form Review Checklist or QA Keyboard Check to check the behavior.

What to do next

Convert the relevant checklist items into acceptance criteria, design notes, or QA checks.
If the work includes forms or errors, use the Form Review Checklist.
If the work is close to handoff, use the Review Readiness Checklist before formal review.
Use the WCAG 2.1 A/AA Map when a requirement needs a standards reference.