Skip to main content
Accessibility Field Guide

Review Readiness Checklist

A pre-review checklist for keyboard access, forms, content, documents, vendor pieces, and review materials.

A red tick mark appears in one of three square checklist boxes on white paper.
Photo: Tick Mark on Square Boxes via Pexels — https://www.pexels.com/photo/tick-mark-on-square-boxes-8850713/
View full screen Download image

Use this before a page, flow, document, or feature goes to formal accessibility review.

This checklist does not replace review. It gives the team a chance to catch the obvious issues before someone else has to find them.

That matters because late accessibility findings usually cost more. By the time something is in review, the design may be approved, the code may be written, the release date may be close, and every fix feels heavier than it needed to be.

Before you send it

  • [ ] The page, flow, or feature is stable enough to review.
  • [ ] The reviewer has a working link or build.
  • [ ] Login steps, test accounts, roles, permissions, and sample data are ready.
  • [ ] The main user path is documented.
  • [ ] Alternate paths, error states, empty states, and confirmation states are available or described.
  • [ ] Known issues are documented instead of hidden.
  • [ ] The team knows who will answer questions and own fixes.

Quick keyboard check

  • [ ] You can reach every interactive element with the keyboard.
  • [ ] You can see where focus is.
  • [ ] Focus moves in a logical order.
  • [ ] You can open, use, and close menus, dialogs, accordions, tabs, date pickers, and other controls.
  • [ ] Focus does not get trapped unless it is inside a modal that intentionally manages focus.
  • [ ] There is no keyboard-only dead end.

This is one of the fastest ways to find real problems.

If the main task cannot be completed with a keyboard, it is not ready.

Structure and screen reader basics

  • [ ] The page has a clear title.
  • [ ] Headings describe the structure of the page.
  • [ ] Form fields have labels.
  • [ ] Groups of related fields are understandable.
  • [ ] Buttons and links have meaningful names.
  • [ ] Images that matter have useful alternative text.
  • [ ] Decorative images are not adding noise.
  • [ ] Status messages, errors, and important changes are communicated in text.

The team does not need to become expert screen reader users overnight.

But the page should at least have the right structure for assistive technology to work with.

Forms and errors

  • [ ] Required fields are identified before submission.
  • [ ] Instructions appear before the user needs them.
  • [ ] Error messages identify the field or issue.
  • [ ] Error messages explain how to fix the problem when possible.
  • [ ] Errors are easy to find after submission.
  • [ ] The user can correct mistakes without starting over.
  • [ ] Confirmation messages explain what happened and what comes next.

Forms should help users recover.

If an error message only says something failed, the form is probably not ready.

Visual and content checks

  • [ ] Text and important visual elements have enough contrast.
  • [ ] Meaning is not communicated by color alone.
  • [ ] Text can be resized or zoomed without breaking the task.
  • [ ] Content is readable and plain enough for the audience.
  • [ ] Link text is specific.
  • [ ] Button text makes the action clear.
  • [ ] Instructions, warnings, and next steps are not hidden in visual layout alone.

A lot of accessibility issues are also plain usability issues.

If people have to guess what a button does, where an error happened, or what a color means, the experience is fragile.

Documents, media, and downloads

  • [ ] Required PDFs or documents are included in the review scope.
  • [ ] Documents have been checked for basic accessibility.
  • [ ] Fillable forms, generated PDFs, and uploaded document flows are ready to test.
  • [ ] Videos have captions when needed.
  • [ ] Audio has transcripts when needed.
  • [ ] Important charts, screenshots, or images have text alternatives or explanations.

Do not let required documents sit outside the review path.

If the user needs the document to complete the task, the document is part of the task.

Vendor or third-party pieces

  • [ ] Vendor widgets, iframes, maps, calendars, payment tools, chatbots, and file viewers are identified.
  • [ ] The team knows what parts are controlled internally and what parts depend on the vendor.
  • [ ] Vendor accessibility documentation or testing notes are available when relevant.
  • [ ] Known vendor limitations are documented.
  • [ ] There is a support or fallback path if the vendor tool blocks users.

Vendor pieces are easy to miss because they feel separate from the team’s code.

Users do not experience them as separate. They experience one task.

Review package

Before submitting, gather:

  • [ ] URL or build location
  • [ ] test accounts and roles
  • [ ] sample data
  • [ ] steps to reach the page or flow
  • [ ] expected result of the main task
  • [ ] screenshots if helpful
  • [ ] known issues or open questions
  • [ ] documents, downloads, or media files in scope
  • [ ] vendor notes or constraints
  • [ ] contact person for questions

Good review materials save time.

They also reduce the chance that the reviewer spends the first round trying to understand how to reach the thing they are supposed to review.

If it is not ready

If the checklist turns up issues, that is useful.

Do not treat it as failure. Treat it as the reason to fix the problem before the review clock starts.

Common next steps:

  • Add missing acceptance criteria.
  • Fix keyboard blockers.
  • Rewrite unclear labels, links, buttons, or error messages.
  • Add missing states to the design or build.
  • Pull required documents into scope.
  • Ask the vendor for accessibility evidence.
  • Document known issues and ownership.

The goal is not perfection before review.

The goal is to avoid sending work forward when the team already knows where the trail gets muddy.

What to do next