Form Accessibility Testing
Labels, required fields, validation and error recovery — tested by filling the form in the way keyboard and screen-reader users do, not only by reading its markup.
- Passed. 1 · Sign-in form — labels announced
- Passed. 2 · Submit — error summary takes focus
- Passed. 3 · Dashboard — heading level 1 announced
- Serious. 4 · Search field — placeholder, no label
- Critical. 5 · Results — list replaced silently
- Not evaluated. 6–7 · not reached
Completed 3 of 7 stepsWCAG 4.1.3 · 3.3.2
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
What makes a form accessible?
An accessible form can be completed without seeing it or using a mouse. Every field announces a clear name, required fields and expected formats are stated in text, and when submission fails the errors are announced, tied to their fields and say how to fix them — with focus taken somewhere the user can act.
Why forms fail so often
Missing form labels are among the most common failures on the web: the 2026 WebAIM Million found them on 51% of the top million home pages (WebAIM, 2026). That is only the part a scanner can detect, on a home page, before anyone types anything.
The harder failures live after the first keystroke. Validation, error messages, conditional fields and the move from one step to the next only exist once someone uses the form — which is why a form can pass every automated rule and still be impossible to submit.
Common form barriers, and what finds them
Each barrier is marked with the layer that catches it. Scans settle whether something is present; journeys find out what happens when the form is used.
Inputs with no label
A placeholder that disappears on typing, a visible label that is not associated with its field, or no label at all. The field announces as "edit, blank".
WCAG 1.3.1 · 3.3.2 · 4.1.2 · Found by scanning
Required fields marked only visually
A red asterisk or bold label says "required" to sighted users and nothing to anyone else, so the form fails on submit for reasons nobody was told.
WCAG 1.3.1 · 3.3.2 · Found by journeys
Errors that are shown but not tied to the field
The message appears in red beneath the input, but is not associated with it — so moving back to the field announces the field and not what is wrong with it.
WCAG 1.3.1 · 3.3.1 · Found by journeys
Errors nobody hears
After a failed submit, focus stays on the button and nothing is announced. The page looks different; to a screen-reader user it sounds exactly the same.
WCAG 3.3.1 · 4.1.3 · Found by journeys
Errors that do not say what to do
"Invalid input" names a failure without a fix. When the system knows the expected format, WCAG asks for the suggestion.
WCAG 3.3.3 · Found by journeys
Multi-step forms that lose people
Moving to step two leaves focus where step one ended, the new heading is never announced, and information already entered is asked for again.
WCAG 2.4.3 · 3.3.7 · Found by journeys
How Accessible tests forms
Scans settle what is present; journeys find out what happens once the form is used.
Scanning finds what is missing
Automated scanning checks every page with a form for inputs with no accessible name, invalid ARIA and contrast failures, groups a broken field component into one issue across every page it appears on, and gives the markup change that fixes it.
How scanning worksJourneys find what happens when it is used
A journey fills the form in keyboard-only with the test values you provide, including the wrong ones. After every keystroke and submit it checks what was announced, where focus went, whether a status message was spoken and whether the form’s fields and errors still make sense — and reports the step where it could not continue, with the WCAG criterion and the fix.
How journey testing worksMonitoring shows which forms real people struggle with
Real user monitoring ranks the barriers visitors meet by how many sessions hit them, so a broken sign-up form outranks a contact form nobody uses. It never sends what anyone typed.
How monitoring works
Testing a form by hand? Work through how to test keyboard-only navigation and the form criteria in the WCAG 2.2 checklist.
Sources
- The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages (opens in a new tab). WebAIM, March 30, 2026. Independent. Automated testing of home pages only.
Frequently asked questions
What is form accessibility testing?
Checking that people using a keyboard, screen reader or other assistive technology can understand, fill in, submit and correct a form: every field named, required fields and formats communicated, and errors identified, announced and explained.
Can an automated scanner test form accessibility?
Partly. A scanner can reliably find inputs with no accessible name and some invalid ARIA. It cannot submit the form, so it cannot tell whether errors are announced, tied to their fields or explain the fix — the failures that decide whether someone gets through.
How do you test form validation for screen readers?
Submit the form with errors on purpose, keyboard only, and listen. Focus should move to the errors or an error summary, each error should be announced and associated with its field, and returning to a field should announce what is wrong with it and how to fix it.
Does Accessible test multi-step forms?
Yes. A journey attempts the whole form across steps and page loads, typing the test values you provide, and reports the step where it could not continue. Sign-in steps work the same way, using a test account rather than live credentials.
Which WCAG criteria apply to forms?
Most often 1.3.1 Info and Relationships, 1.3.5 Identify Input Purpose, 3.3.1 Error Identification, 3.3.2 Labels or Instructions, 3.3.3 Error Suggestion, 3.3.7 Redundant Entry, 4.1.2 Name, Role, Value and 4.1.3 Status Messages — plus 3.3.4 Error Prevention for legal and financial submissions.
Submit your forms the way your users do.
Scan every page for missing labels, and run a journey through the form that matters most.