Skip to main content
Accessibility Field Guide

Intake Accessibility Questions

A plainspoken set of questions teams can ask early so accessibility risks show up before design, development, and review rework.

A notepad with a question mark drawn on it.
Photo: A Notepad with a Question Mark Drawing via Pexels — https://www.pexels.com/photo/a-notepad-with-a-question-mark-drawing-6991443/
View full screen Download image

Accessibility gets easier when it shows up before the work is already shaped.

That does not mean every intake conversation needs to become a WCAG review. Most teams do not need a standards lecture at the beginning of a request. They need a few good questions that help them notice where accessibility decisions are already hiding.

The goal is simple: catch the likely rework while the work is still easy to change.

When to use this

Use these questions when a new request, feature, form, page, vendor tool, document, or workflow is being discussed.

This is useful during:

  • project intake
  • discovery
  • request triage
  • backlog grooming
  • requirements drafting
  • vendor conversations
  • early design review
  • handoff from product to delivery

You do not need to ask every question every time. Pick the ones that match the work in front of you.

The core question

Start here:

What could make this hard or impossible for someone to complete?

That question usually leads to better follow-up questions than starting with, “Is this accessible?”

“Is this accessible?” is too broad. It often turns into a yes/no guess.

“What could block someone?” is more practical. It gets the team thinking about the user’s path, the decisions being made, and the places where the happy path may fall apart.

Questions about the user task

Ask:

  • What is the user trying to do?
  • Is this task required, optional, or informational?
  • What happens if the user cannot complete it?
  • Is there a deadline, penalty, payment, eligibility decision, or account consequence?
  • Does the user need to understand something before they can act?
  • Are we assuming the user can see, hear, use a mouse, read quickly, remember information, or complete the task in one sitting?

These questions help separate a cosmetic issue from a real barrier.

If the task affects eligibility, payment, identity, benefits, access to records, or a required service, accessibility risk is higher. The work needs clearer requirements and earlier review.

Questions about forms and inputs

Forms are where a lot of accessibility rework starts.

Ask:

  • Does the user need to enter information?
  • Are labels, hints, and instructions part of the requirement?
  • What fields are required?
  • How will the page explain errors?
  • Does the user get a chance to correct mistakes?
  • Are there format rules, character limits, masks, uploads, or date pickers?
  • What happens if the user submits incomplete or invalid information?
  • Can the user review before final submission?

A form requirement that only describes the happy path is not finished yet.

The error path is part of the experience. So are instructions, required fields, review steps, and confirmation messages.

Questions about navigation and structure

Ask:

  • Is this adding a new page, section, modal, step, tab, accordion, or wizard?
  • Does the user need to move through content in a specific order?
  • Does the page have clear headings?
  • Will a screen reader user understand where they are?
  • Can a keyboard user reach everything in a reasonable order?
  • Does focus move somewhere unexpected after an action?
  • Is there a clear way to go back, cancel, save, or recover?

Navigation problems often start as design or flow decisions, not code defects.

If the structure is confusing on paper, it will probably be more confusing with assistive technology.

Questions about content

Ask:

  • Is the language clear enough for the audience?
  • Are instructions visible before the user needs them?
  • Does the page rely on color, position, shape, or icons alone to explain meaning?
  • Are links and buttons specific enough out of context?
  • Are headings descriptive?
  • Are confirmation, warning, and error messages written in plain language?
  • Are there acronyms, policy terms, or internal labels that need explanation?

Content is accessibility work.

A technically correct screen can still be hard to use if the instructions are vague, the labels are unclear, or the button text does not explain what happens next.

Questions about documents and media

Ask:

  • Does this request create, change, upload, download, or link to a PDF or document?
  • Is the document the only way to get important information?
  • Does the document need to be filled out or signed?
  • Are there charts, images, screenshots, or scanned pages?
  • Is there audio or video?
  • Do videos need captions or transcripts?
  • Is there an HTML alternative for content that should not be locked inside a document?

Documents can become quiet blockers.

If a PDF is required to complete the task, then the PDF is part of the user flow. It should not be treated as an attachment someone worries about later.

Questions about vendors and third-party tools

Ask:

  • Is a vendor product, embedded widget, iframe, chatbot, map, calendar, payment tool, or file viewer involved?
  • Do we have accessibility documentation from the vendor?
  • Has the tool been tested with keyboard navigation and screen readers?
  • Can we configure labels, headings, instructions, colors, error messages, or focus behavior?
  • Who owns fixes if the vendor tool creates a barrier?
  • Is there an accessible fallback path if the tool fails for some users?

Vendor work still needs ownership.

A third-party tool can move the fix outside the team’s direct control, but it does not move the user impact somewhere else.

Questions about review and handoff

Ask:

  • Who will check the obvious accessibility issues before formal review?
  • What needs to be ready before review?
  • Are requirements clear enough for design, development, and QA to test against?
  • Is there a keyboard path through the main task?
  • Are known risks documented?
  • Are screenshots, links, test accounts, sample data, and special instructions ready for the reviewer?
  • If something fails review, who owns the fix?

A review is easier when the team knows what it is submitting.

The goal is not to replace formal review. The goal is to avoid sending work forward with problems the team could have caught earlier.

A small intake script

If the conversation is moving fast, use a shorter version:

  1. What is the user trying to do?
  2. What could block someone from completing it?
  3. Does this involve a form, document, vendor tool, custom interaction, or required decision?
  4. What error, empty, loading, confirmation, and recovery states are needed?
  5. What should we check before this goes to review?

That is enough to make the work better.

It will not catch everything. It is not supposed to. It gives the team a better starting point.

What to do with the answers

If the answers reveal risk, turn them into requirements.

Good intake notes should lead to clear next steps:

  • Add acceptance criteria for labels, errors, keyboard behavior, headings, or document accessibility.
  • Flag vendor or third-party risk early.
  • Ask design to account for focus, structure, content, and recovery states.
  • Ask development to use native HTML where possible.
  • Ask QA to include keyboard and form-error checks.
  • Prepare review materials before the final handoff.

Accessibility intake should not create a separate pile of notes nobody uses.

It should shape the work.

These questions can point toward many WCAG criteria, depending on the feature. Common trail markers include:

Follow-up pages for forms and interaction risk

If intake reveals a form, task flow, custom control, modal, or error path, use these Field Guide pages as follow-up:

What to do next