Skip to main content
Accessibility Field Guide

Intake Accessibility Questions Checklist

A quick checklist for spotting accessibility risks while a request is still early enough to shape.

A person filling out a form on a clipboard.
Photo: A Person Filling up a Form on a Clipboard via Pexels — https://www.pexels.com/photo/a-person-filling-up-a-form-on-a-clipboard-6169648/
View full screen Download image

Use this checklist when a request is new enough that the team can still shape it.

The goal is not to complete a full accessibility review at intake. The goal is to notice the parts of the work that may create accessibility rework later.

If a question does not apply, skip it. If a question reveals risk, turn the answer into a requirement, design note, test note, or review follow-up.

Quick pass

Use this when you only have a few minutes.

  • [ ] What is the user trying to do?
  • [ ] What could make this hard or impossible for someone to complete?
  • [ ] Is this task required, time-sensitive, or tied to eligibility, payment, identity, records, or access to a service?
  • [ ] Does this involve a form, document, vendor tool, custom interaction, or important decision?
  • [ ] Are error, empty, loading, confirmation, and recovery states part of the work?
  • [ ] Who will check the obvious accessibility issues before formal review?

User task

  • [ ] The main user task is clear.
  • [ ] The consequence of not completing the task is understood.
  • [ ] Required steps are separated from optional steps.
  • [ ] The team has identified where a user might get stuck.
  • [ ] The work does not assume every user can see, hear, use a mouse, read quickly, remember details, or complete the task in one sitting.

Forms and inputs

  • [ ] Any forms, fields, uploads, signatures, or data entry steps are identified.
  • [ ] Required fields are known.
  • [ ] Field labels are part of the requirement, not left as an afterthought.
  • [ ] Help text, hints, examples, or formatting rules are identified.
  • [ ] Error messages and correction paths are included.
  • [ ] Review, save, cancel, back, and confirmation behavior is understood.
  • [ ] New pages, steps, modals, tabs, accordions, filters, menus, or custom interactions are identified.
  • [ ] The expected keyboard path is considered.
  • [ ] Focus behavior is considered when content opens, closes, changes, or submits.
  • [ ] The page or flow has a clear structure.
  • [ ] Users have a clear way to recover if they make a mistake or need to leave the happy path.

Content and meaning

  • [ ] Instructions are written before the user needs them.
  • [ ] Headings describe the page or section clearly.
  • [ ] Link and button text explain the action or destination.
  • [ ] The work does not rely on color, shape, icon, or position alone to communicate meaning.
  • [ ] Acronyms, policy terms, or internal labels are explained when needed.
  • [ ] Confirmation, warning, and error text is plain enough to act on.

Documents and media

  • [ ] Any PDFs, documents, spreadsheets, scans, screenshots, images, audio, or video are identified.
  • [ ] The team knows whether the document is required to complete the task.
  • [ ] Fillable or signable documents are flagged early.
  • [ ] Captions, transcripts, alt text, or long descriptions are considered where needed.
  • [ ] The team has considered whether important content should be HTML instead of only a document.

Vendors and third-party tools

  • [ ] Any vendor product, embedded widget, iframe, map, calendar, payment tool, chatbot, or file viewer is identified.
  • [ ] The team has accessibility documentation or testing information from the vendor.
  • [ ] The team knows what can and cannot be configured.
  • [ ] Ownership is clear if the vendor tool creates an accessibility barrier.
  • [ ] There is a fallback path if the tool blocks some users.

Review planning

  • [ ] Known accessibility risks are documented.
  • [ ] The team knows what should be checked before formal review.
  • [ ] Review materials will include links, screenshots, test accounts, sample data, and special instructions when needed.
  • [ ] Someone owns follow-up if the review finds issues.
  • [ ] Accessibility findings will be fed back into the team’s requirements, design, development, and QA habits.

Good output from this checklist

The output should not be a separate accessibility note that gets forgotten.

Use the answers to create or improve:

  • acceptance criteria
  • design notes
  • content requirements
  • QA checks
  • vendor questions
  • review readiness notes
  • backlog items

What to do next