Accessibility Field Guide

Intake Accessibility Questions Checklist

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

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.

Navigation and interaction

[ ] 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

Related field notes

What to do next

Save the answers where the team already tracks scope, requirements, or open questions.
If a risk needs to become acceptance criteria, move to the Accessibility Requirements Checklist.
If the work includes a form or workflow, check Forms and Labels and Error Messages and Recovery before build decisions harden.