Skip to main content
Accessibility Field Guide

Checklists and Job Aids

Practical Accessibility Field Guide checklists for intake, requirements, forms, keyboard QA, review readiness, vendors, and component work.

A checklist page clipped to a white clipboard.
Photo: A White Paper With Checklist on a Clipboard via Pexels — https://www.pexels.com/photo/a-white-paper-with-checklist-on-a-clipboard-8978610/
View full screen Download image

Use this page when you need a quick prompt during real project work.

A checklist is not a full accessibility review.

It is a way to catch common issues before they become late rework.

The best checklist is small enough to use while the work is still moving. Use these pages during intake, requirements, design handoff, development, QA, vendor review, and pre-review cleanup.

How to use these checklists

Pick the checklist that matches the moment in front of you.

Do not try to run everything at once.

A useful pass usually looks like this:

  1. Choose the checklist that matches the work.
  2. Walk through a real screen, flow, component, document, or vendor response.
  3. Mark what is clear, what is missing, and what needs follow-up.
  4. Turn findings into requirements, design notes, development tasks, QA checks, or review prep.
  5. Use the related topic pages when a checklist item needs more context.

Intake and early shaping

Use these when the team is still clarifying the request, scope, risk, and ownership.

  • Intake Accessibility Questions Checklist — ask practical accessibility questions before the work gets too fixed.
  • Accessibility Requirements Checklist — turn accessibility expectations into requirements and acceptance criteria.

Related guide pages:

  • Intake Accessibility Questions
  • Review Readiness
  • Browse by Topic

Forms and errors

Use this when the work includes fields, instructions, required inputs, validation, error text, confirmation messages, or recovery steps.

  • Form Review Checklist — check labels, instructions, grouping, errors, recovery, and completion paths.

Related guide pages:

  • Forms and Labels
  • Error Messages and Recovery
  • Status Messages and Alerts

Keyboard and focus

Use this when someone needs to move through the screen without a mouse.

  • QA Keyboard Check — run a practical no-mouse pass through a page, flow, component, or prototype.

Related guide pages:

  • Keyboard-Only Navigation
  • Focus Visible and Focus Order
  • Modals and Dialogs

Review readiness

Use this before work goes to formal accessibility review, signoff, handoff, or launch planning.

  • Review Readiness Checklist — check whether the team has addressed common issues and gathered enough evidence.

Related guide pages:

  • Review Readiness
  • WCAG 2.1 A/AA Map
  • Accessibility Glossary

Vendor and third-party accessibility

Use this when a vendor tool, embedded service, platform, generated document, or third-party workflow affects users.

  • Vendor Accessibility Questions Checklist — ask what the vendor evidence covers, what it does not cover, and who owns follow-through.

Related guide pages:

  • Vendor and Third-Party Accessibility Field Guide

Supporting notes:

  • A VPAT Is Not a Magic Shield
  • Accessibility Evidence Should Match the Thing You’re Shipping
  • Ask Vendors How Accessibility Works in Your Configuration

Components and development handoff

Use this when a feature depends on custom controls, reusable components, design-system behavior, or ARIA.

  • Developer Component Checklist — check names, roles, states, keyboard behavior, focus movement, and handoff expectations.

Related guide pages:

  • Native HTML First
  • Button vs Link
  • Accessible Names
  • Name, Role, and Value
  • ARIA Is Not Duct Tape
  • Accordions
  • Combobox
  • Tabs

Other useful job aids

These are useful candidates for future expansion, but they are not production v1 blockers unless a project needs them immediately.

  • Design handoff checklist — design-to-development accessibility expectations.
  • Content clarity checklist — plain-language, labels, instructions, and help text.

For production v1, use the live checklists above as the primary working set.

What to do next

  • If the work is early, start with Intake Accessibility Questions Checklist.
  • If the team is writing acceptance criteria, use Accessibility Requirements Checklist.
  • If the work is a form, use Form Review Checklist.
  • If the work needs a no-mouse pass, use QA Keyboard Check.
  • If the work is close to review, use Review Readiness Checklist.
  • If you are not sure which page fits, use Browse by Topic.