> ## Content Index > Fetch the complete content index at: https://fieldnotes.tommytruong.com/llms.txt > Use this file to discover other available public pages before exploring further. # Intake Accessibility Questions Checklist - URL: https://fieldnotes.tommytruong.com/accessibility-field-guide/intake-accessibility-questions-checklist/ - Published: 2026-07-05T15:50:00.000Z - Updated: 2026-07-21T03:16:56.000Z - Description: A quick checklist for spotting accessibility risks while a request is still early enough to shape. - Author: Tommy Truong - Tags: Guides, Accessibility, Accessibility Field Guide, Checklist, Intake, Requirements 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 - [Intake Accessibility Questions](https://fieldnotes.tommytruong.com/accessibility-field-guide/intake-accessibility-questions/) - [Requirements Checklist](https://fieldnotes.tommytruong.com/accessibility-field-guide/accessibility-requirements-checklist/) - [Review Readiness Checklist](https://fieldnotes.tommytruong.com/accessibility-field-guide/review-readiness-checklist/) - [Forms and Labels](https://fieldnotes.tommytruong.com/accessibility-field-guide/forms-and-labels/) - [Error Messages and Recovery](https://fieldnotes.tommytruong.com/accessibility-field-guide/error-messages-and-recovery/) - [Keyboard-Only Navigation](https://fieldnotes.tommytruong.com/accessibility-field-guide/keyboard-only-navigation/) ## 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](https://fieldnotes.tommytruong.com/accessibility-field-guide/accessibility-requirements-checklist/). - If the work includes a form or workflow, check [Forms and Labels](https://fieldnotes.tommytruong.com/accessibility-field-guide/forms-and-labels/) and [Error Messages and Recovery](https://fieldnotes.tommytruong.com/accessibility-field-guide/error-messages-and-recovery/) before build decisions harden.