Skip to main content
Accessibility Field Guide

Form Review Checklist

A practical checklist for reviewing labels, instructions, required fields, errors, grouping, and recovery before a form goes to accessibility review.

Close-up of a hand marking boxes on a paper checklist.
Photo: Close-up Photo of Checklist on White Paper via Pexels — https://www.pexels.com/photo/close-up-photo-of-checklist-on-white-paper-6837789/
View full screen Download image

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.

Use these as trail markers, not as the whole checklist:

  • 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