> ## 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. # Form Review Checklist - URL: https://fieldnotes.tommytruong.com/accessibility-field-guide/form-review-checklist/ - Published: 2026-07-08T21:52:13.000Z - Updated: 2026-07-21T03:16:57.000Z - Description: A practical checklist for reviewing labels, instructions, required fields, errors, grouping, and recovery before a form goes to accessibility review. - Author: Tommy Truong - Tags: Guides, Accessibility, Accessibility Field Guide, Forms, Checklist, WCAG Use this checklist before a form gets too far into design, build, QA, or formal accessibility review. The goal is not to complete a full audit from this page. The goal is to catch the common form problems while they are still small enough to fix. A useful form should make the path clear: - what the page is asking for - which fields matter - what format the user should follow - how related options fit together - what went wrong if something fails - how the user can recover and finish the task If the form cannot answer those questions, it is probably not ready yet. ## How to use this checklist Pick one real form or screen. Do not review only the happy path. Try the form as a user would: - fill it out correctly - leave required fields blank - enter the wrong format - choose conflicting options if the form allows it - upload the wrong file type if uploads are part of the flow - use only the keyboard for at least one pass - zoom in or narrow the browser window if layout may change As you review, write down the specific field, screen, or step where the issue appears. A useful finding should be clear enough for someone else to fix. ## Before design or build Use these questions while the form is still easy to shape. - Does the team know what information the user needs to provide? - Does every field have a clear purpose? - Are required fields identified in the requirements or acceptance criteria? - Are format rules documented before development starts? - Are file upload limits documented, including type and size? - Are radio buttons, checkboxes, repeated sections, and date ranges described as groups when needed? - Are error states part of the requirements, not an afterthought? - Does the team know what should happen when the user submits the form with errors? - Does the team know what system errors or service failures the user might see? - Are there places where better instructions could prevent avoidable errors? ## Labels and field purpose Each field should be understandable before the user starts typing. - Does every input have a visible label? - Does the visible label clearly name what the field is asking for? - Are labels specific enough to stand on their own? - Are repeated controls distinguishable from each other? - Are icon-only controls given a clear text alternative or accessible name? - Does the accessible name match or include the visible label? - Are placeholder-only labels avoided? - Are vague labels like `Type`, `Number`, `Name`, or `Information` clarified when more detail is needed? Quick check: > If someone heard only the field or control name, would they know what it is for? ## Instructions and help text Instructions should appear before the user needs them. - Are format requirements shown before the user submits the form? - Are examples provided when the expected answer could be unclear? - Are file upload requirements shown near the upload control? - Are date, phone, ID, case number, or currency formats explained when needed? - Are eligibility or documentation rules explained before the user reaches a dead end? - Is help text close to the field it explains? - Is help text programmatically connected to the field when needed? - Is the instruction still available after the user starts typing? Useful examples: - `Use MM/DD/YYYY.` - `Enter your 10-digit phone number.` - `Upload a PDF, JPG, or PNG under 10 MB.` - `Select all programs that apply.` ## Required fields The user should know what is required before submitting. - Are required fields clearly identified? - Is the required-field pattern explained if the form uses an asterisk? - Does the form avoid relying on color alone to show required fields? - If most fields are required, would it be clearer to mark optional fields instead? - Are required-field errors specific when the user misses something? - Does the form avoid surprising the user with hidden required fields after submission? Quick check: > Can someone tell what they must complete before pressing submit? ## Grouping and relationships Related controls should feel like one clear question, not scattered pieces. - Are radio button groups introduced by a clear group label or question? - Are checkbox groups introduced by a clear group label or question? - Are address, name, phone, date, and repeated sections grouped in a way that makes sense? - Are dependent fields explained when one answer changes what appears next? - Are headings, labels, legends, or other programmatic relationships used where needed? - Does the visual layout match the logical relationship between fields? - Does the form still make sense when zoomed, reflowed, or viewed on a narrow screen? Example: - Group label: `Preferred contact method` - `Email` - `Phone` - `Mail` Without the group label, the options may be present but unclear. ## Error messages Errors should help the user fix the problem. - Does each error message identify what went wrong? - Does each error message explain how to fix it when the fix is known? - Are error messages written in plain language? - Are field-level errors shown near the fields they describe? - Does a long form provide an error summary when several fields need attention? - Does the error summary point the user back to the fields that need work? - Are errors shown with text, not only color, icons, or red borders? - Are errors programmatically connected to the fields they describe? - Does the form preserve the user’s completed answers after validation fails? - Can the user trigger and fix more than one error without getting lost? Less helpful: - `Invalid input` - `Error` - `Required` More helpful: - `Enter a date in MM/DD/YYYY format.` - `Select one contact method.` - `Upload a PDF, JPG, or PNG under 10 MB.` ## Focus and keyboard recovery A user should be able to find, understand, and fix errors without a mouse. - Can the user reach every field and control with the keyboard? - Is the tab order logical? - Is keyboard focus visible throughout the form? - After failed submission, does focus move to a useful place? - If focus moves to an error summary, can the user move from the summary to the problem fields? - If focus stays near the form, does the user still receive clear feedback that errors were found? - Are custom selects, date pickers, file uploads, and autocomplete controls usable with the keyboard? - Are modal dialogs, popovers, or conditional sections handled without trapping the user? Quick check: > Submit the form with errors using only the keyboard. Can you find the errors, fix them, and submit again? ## System and service errors Not every error is the user’s fault. Those messages still need to be useful. - Does the page explain what happened in plain language? - Does the message avoid raw technical codes unless they are genuinely useful to support? - Does the message tell the user whether to retry, save work, contact support, or come back later? - Does the message explain whether a payment, submission, upload, or request went through? - Does the page preserve the user’s work when possible? - If the user needs help, is the next contact path clear? Useful examples: - `We could not submit the form right now. Try again in a few minutes.` - `The file could not be uploaded. Save your work and try again.` - `Payment could not be completed. Your card has not been charged.` ## Final pre-review pass Before the form goes to a broader review, do one intentional break pass. - Submit the form empty. - Enter the wrong format in fields with format rules. - Miss one required field in the middle of the form. - Trigger more than one error at once. - Try the form with only the keyboard. - Check the form at 200% zoom or in a narrow viewport. - Confirm the user can recover without losing completed work. Then ask: > Would a person using only the page’s labels, instructions, errors, and focus behavior know what to do next? If the answer is no, fix the form before it becomes review rework. ## Common findings to write down Use plain notes like these so the issue is easy to act on: - `Date of birth field uses placeholder text as the only instruction. Add persistent visible format guidance.` - `Required fields are marked only by red labels. Add text or an explained required-field marker.` - `Preferred contact options need a group label so the radio buttons have a clear question.` - `File upload error says "Invalid." Replace with accepted file types and size limit.` - `After failed submit, focus stays on the submit button while the error summary appears above. Move focus or announce the summary.` ## Related WCAG trail markers Use these as trail markers, not as the whole checklist: - [1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#info-and-relationships) - [1.4.1 Use of Color](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#use-of-color) - [2.1.1 Keyboard](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#keyboard) - [2.4.3 Focus Order](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#focus-order) - [2.4.7 Focus Visible](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#focus-visible) - [3.2.1 On Focus](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#on-focus) - [3.2.2 On Input](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#on-input) - [3.3.1 Error Identification](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#error-identification) - [3.3.2 Labels or Instructions](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#labels-or-instructions) - [3.3.3 Error Suggestion](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#error-suggestion) - [3.3.4 Error Prevention (Legal, Financial, Data)](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#error-prevention-legal-financial-data) - [4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#name-role-value) - [4.1.3 Status Messages](https://www.w3.org/TR/WCAG21/?ref=fieldnotes.tommytruong.com#status-messages) ## Related field notes - Forms and Labels - Error Messages and Recovery - Accessibility Requirements Checklist - Intake Accessibility Questions - Review Readiness - Broader first pass: How to Review a Web App for Accessibility for the First Time ## What to do next - Run the checklist against one real form, not an idealized version of the flow. - If labels or instructions are unclear, use [Forms and Labels](https://fieldnotes.tommytruong.com/accessibility-field-guide/forms-and-labels/). - If the recovery path is unclear, use [Error Messages and Recovery](https://fieldnotes.tommytruong.com/accessibility-field-guide/error-messages-and-recovery/). - Before formal review, include the form in the [Review Readiness Checklist](https://fieldnotes.tommytruong.com/accessibility-field-guide/review-readiness-checklist/).