Every other accessibility failure costs somebody effort. A form failure costs them the task. They cannot buy, cannot book, cannot apply, cannot get in touch. And unlike a missing alt attribute, you feel this one in your numbers.
The encouraging part is that forms fail in a small number of predictable ways, and each one has a well-established fix. Four rules cover most of it, and the ten-point check at the bottom will find the rest in about a quarter of an hour.
Rule One, Every Field Has a Real Label
Not text that happens to sit near the field. A label connected to it, so that clicking the label focuses the field and a screen reader announces the two together. Our fix guide covers connecting a label to its field.
The quickest test takes two seconds. Click the label text. If focus jumps into the field, they are connected. If nothing happens, they are not, and the field will be announced with no idea what belongs in it. There is one blind spot in that test worth knowing before you file a finding on it. A control named with aria-label or aria-labelledby conforms perfectly well and does not produce the click behavior, so check the accessibility tree before you write that one up.
It is also worth knowing why a connected label matters to more people than a screen reader user. A connected label makes the label itself part of the click target, which is a real help to anybody with limited dexterity. And a speech input user activates a control by saying its name out loud, so a field with a visible label and no accessible name cannot be reached by voice at all. That is a named failure of its own, and voice control users are the group most likely to be left out of a forms audit entirely.
Three traps account for most of what we find.
- Placeholder as label. The prompt vanishes the moment somebody types, so anybody who gets interrupted has lost it. W3C also notes that browsers usually render placeholder text in a color that misses the contrast minimum. Placeholders are fine as an example of the format, sitting underneath a real label.
- Label above, input elsewhere in the markup. Visually fine, programmatically unconnected. Use
forandid. - Icon-only fields, such as a search box with a magnifier and no text. It needs an accessible name, and that is 4.1.2 doing the work rather than the labeling rule. W3C accepts an image as a visible label where the image is widely understood, and a search magnifier is its own example. So the icon is a legitimate label. What it still owes is a name assistive technology can read.
Rule Two, Group Related Fields
A set of radio buttons or checkboxes needs the question announced, not only the options. Without a fieldset and a legend, a screen reader user hears Standard, radio button, with nothing saying what is being asked. Our fix guide covers grouping with fieldset and legend.
Each option inside the group needs its own label as well, which sounds obvious and is the half people skip when they style radios as cards. The same goes for multi-part fields. A phone number split across three boxes, a date across three selects, a card number across four. Each part needs its own name, or the user hears edit text three times and has to guess which box wants the area code. The names on the parts can be invisible, and W3C's own passing example does exactly that inside a fieldset legended Phone number.
Put the Instructions Where They Will Be Heard
This is the most concrete piece of forms guidance W3C publishes, and almost nobody carries it. It sits on one page of the W3C tutorial on form instructions. Screen readers switch into a forms mode inside a form element, and in that mode they usually read only the form elements themselves, meaning inputs, selects, textareas, legends and labels. Ordinary paragraphs between your fields may simply not be read.
So instructions that apply to the whole form belong before the form element, where they get read before the mode switches. Instructions that apply to one field belong on that field, tied to it with aria-describedby, which is how a format hint reaches somebody rather than sitting near the box hoping to be noticed. Our fix guides cover instructions at the start of a form and showing the expected format.
There is a counterweight in the standard that is worth having in your pocket when a remediation plan starts growing. W3C says outright that too much information or instruction can be just as harmful as too little. A team that responds to an audit by hanging help text off every field has not improved the form. And one scope note that halves a common misreading. The rule talks about content that requires user input, and that means every field, optional ones included, not only the ones marked required.
Rule Three, Errors That Say What and Why
This is where most forms fail, and it is rarely a technical problem. It is a writing problem.
| What forms say | What the user needs | Why |
|---|---|---|
| "Invalid input" | "Enter your date of birth as DD/MM/YYYY" | Names the field and the expected format |
| "Error" | "Your password needs at least 8 characters" | Says what would fix it, which is what turns one message into two criteria satisfied at once |
| A red border, nothing else | A red border, an icon, and a message | Color alone fails 1.4.1, and a border carries nothing at all to a screen reader |
| "Please correct the errors below" | A list of the specific errors, each linked to its field | Lets somebody jump straight to the problem. One accepted route among several rather than the requirement |
| An error that appears silently | An error announced when it appears | Otherwise a screen reader user resubmits blindly |
W3C's own teaching pair makes the second row land. Email is not valid passes the error identification rule. Please provide a valid email address in the format name@domain.com passes that one and the error suggestion rule as well. One sentence, two criteria, no extra work.
Where you show the errors is more open than people assume. W3C accepts a summary at the top, messages beside each field, an alert, or a dialog, and declines to say which. What it does specify is what each entry in a summary has to do. Name the label of the field it belongs to, describe the problem in words anybody can follow, say how to fix it and repeat the format requirement while you are there, and link to the field itself. That third item is the one teams skip, and it is the one that saves a second round trip.
There is a technique that reaches a screen reader user before any of that, and it costs one line. Put the error count in the page title and in the h1 when the form comes back, so the title reads 3 Errors, Billing Address. On a full page reload the title is announced immediately, which means the news arrives before the reader has gone looking for it.
The announcement part matters more than teams expect. An error that renders visually and is never announced means a screen reader user presses Submit, hears nothing, and presses Submit again. And again. That is 3.3.1 Error Identification and, for the announcement, 4.1.3 Status Messages. Two criteria, two different jobs.
Pick one route rather than both. Moving focus to an error summary is itself a change of context, and a change of context sits outside the definition of a status message, so a summary that takes focus needs no live region around it. Announce the errors politely, or move focus to a summary listing them. Do both and somebody hears the same thing twice.
Two smaller rules under the same heading. Re-displaying the form with no indication that anything went wrong is not enough on its own. And an error you fixed for the user still has to be reported, so a quantity stepper that silently clamps 500 down to 50, or a date picker that quietly rounds a date into range, owes the user a message saying so.
Try it on your own form
Submit your contact form completely empty, with a screen reader running. Listen for whether anything reaches you at all, whether it names the fields, and whether you end up somewhere you can act from. This one test finds more than any scanner will on the same page, and the reason is dull rather than rhetorical. The labeling rule and the status message rule have no automated rules written for them at all, and the error identification rule has exactly one, still at proposed status.
Native Validation Passes, and Here Is What It Costs
The browser's own constraint validation, the bubble you get from required and type="email", satisfies the error identification rule. W3C says so, and then lists four things to weigh before you rely on it. The message may not persist or scroll with the page. It does not magnify along with zoomed content. The default wording is too generic to satisfy the error suggestion rule, so it will not carry you to Level AA on its own. And where several fields are wrong, only the first error is exposed.
That last one is the one that turns a five-field form into five round trips, which is why native validation is a reasonable floor and a poor ceiling.
While you are in the validation code, two more things. Be generous about what you accept, because rejecting a phone number that is correct but formatted differently is a barrier rather than a standard. And whatever you check in the browser, check again on the server, since client-side validation is a convenience and never a security control.
Rule Four, Do Not Make People Work Twice
WCAG 2.2 added two rules aimed squarely at forms, and both reward things good forms did anyway.
- 3.3.7 Redundant Entry. Do not ask for the same information twice in one process. If they gave you a delivery address, offer it for billing rather than demanding it again.
- 3.3.8 Accessible Authentication. Do not require a cognitive function test to log in, unless the step provides one of four escapes. Another authentication method that skips the test, a mechanism that helps somebody through it, a test that only asks them to recognize objects, or a test that only asks them to identify content they supplied themselves.
Allowing paste and letting password managers work is the mechanism escape, which is the one most sites take and the one most people mistake for the whole rule. It is not. A site offering a passkey or an email sign-in link has taken the alternative escape and conforms at that step regardless. Blocking paste in a password field is still the failure we find most, and it is usually added deliberately for security reasons that do not survive examination. The sign-in guide has the detail.
Forms and the Clock
A guide about checkouts and applications that never mentions timeouts is missing the failure that wipes the work. W3C's own advice is that a form should not carry a time limit at all where you can avoid one. Where a session limit is unavoidable, 2.2.1 at Level A wants the user able to turn it off, adjust it well beyond the default, or extend it with a simple action after a warning. And 2.2.6 wants them warned about how long inactivity can last before data is lost, unless the data is preserved for more than twenty hours.
Autocomplete Is a Requirement, Not a Nicety
1.3.5 Identify Input Purpose asks for the right autocomplete value on fields collecting information about the person filling the form in. Their name, their email, their telephone number, their street address, their postal code.
That scope is narrower than it first reads, and W3C wrote the limit into the standard. The purposes pertain only to information related to that individual, so a gift recipient's delivery address, an emergency contact's phone number and a referee's email all sit outside the rule even though those exact tokens are on W3C's list. Setting the attribute on them is still good practice. It is not a finding if you have not.
It is a Level AA requirement, and the thing it asks for is that the purpose be programmatically determinable rather than that the browser actually fill anything. W3C is explicit that the autofilling itself is a benefit rather than the requirement. The benefit is real, though. It fills fields for people who find typing difficult, and it lets assistive tools swap in familiar icons for a field somebody recognizes by picture rather than by word. Our fix guides cover the correct autocomplete values and the failure of using wrong ones.
Forms That Change Shape as You Fill Them In
You do not have to test every route through a branching form. That is the worry people arrive with, and no rule anywhere asks for it. Eight yes-or-no questions already produce 256 possible routes and twelve produce more than 4,000, so a report claiming to have covered them all is telling you something about the report rather than about the form.
What you do instead is choose the routes deliberately, write down which ones you chose, and say plainly which ones nobody opened. A path nobody walked is untested, not passing, and the difference between those two words is the whole of an honest scope. The worksheet below is how that choice gets made in about half an hour.
Step One, Write Down the Deciders
Not every field changes the form. Most do nothing but collect an answer. Go through the form and list only the controls that alter what happens next, which is usually a much shorter list than the team expects.
- A control that reveals or hides other fields on the same step.
- A control that adds or removes a whole step.
- A control that changes the wording, the validation or the options of a later field.
- A control that lets somebody add another one of something, so a second passenger, a second line item, a second address.
- A control that can end the form early, including the eligibility question that stops it.
If that list is empty, you have a long form rather than a branching one, and the ten-point check below is the whole job. If it has five entries, you have five decisions to make and the rest of the worksheet makes them.
Step Two, Pick the Paths, and Say Why
Four kinds of path earn a place in almost every scope, and naming them is faster than arguing about coverage.
- The shortest route to a finished submission. The one most people take, and the one that has to work before anything else matters.
- The longest route. Every optional section opened, every repeatable group used twice, because length is where progress indicators and saved state fall over.
- One route per branch you have never tested. Not one per combination. One that reaches each deciding control and exercises it, which is a small number even on a large form.
- Every dead end. The routes that stop the form, because a person told they are not eligible still needs to hear it, and those screens are the least looked at part of any application.
Write beside each path the answers that reach it, as you go. That is what makes the test repeatable next quarter, and it costs nothing while you are already standing in the form.
Step Three, Test the Transitions, Not Only the Screens
Static screens are the easy half. What breaks on a branching form is the moment it changes, and each kind of change raises a different rule. Filing them separately is what turns a list of complaints into tickets somebody can close.
| When this happens | Check | The rule it belongs to |
|---|---|---|
| A field appears in place | Whether anything reaches a screen reader user at all, and where focus is left standing | 4.1.3 Status Messages for the announcement |
| Choosing an option navigates or submits on its own | Whether the user was told the control would do that before they touched it | 3.2.2 On Input, Level A |
| A step is skipped by an earlier answer | Whether the progress indicator still tells the truth, and whether Back returns somewhere sensible | No single criterion owns this. It is 3.3.2 if the instructions now mislead, and a usability finding otherwise |
| Somebody adds a second instance of a repeated group | Whether each instance has its own name, and where focus goes after Add and after Remove | 4.1.2 Name, Role, Value for the naming |
| An answer is changed after later steps depended on it | Whether anything silently discards work, and whether the user is told | 3.3.4 at a legal, financial or data step. Elsewhere, report it as data loss and say so |
| The form ends early | Whether the outcome is announced, and whether there is a route out other than the back button | 3.3.1 Error Identification where the ending is an error |
That last column is doing more work than it looks. The temptation on a branching form is to file everything under one heading and call the wizard broken. Six findings against six rules get fixed. One finding saying the wizard is inaccessible gets discussed.
Step Four, Tell the Truth About the Step Count
W3C's own guidance says the first step should say how many steps follow, and that each step should report progress. Then it answers the case people assume it ignores. Where the number of steps depends on the answers, it shows an approximate count rather than a false exact one, and its worked example reads Step 1 of circa 7. An honest approximation beats a precise wrong number, because a bar that promised Step 3 of 5 and then produced nine steps is the part of your form people describe to other people.
Progress belongs at the front of the page title, ahead of the step name and the site name, because the title is the first thing many people hear. That rule also settles what happens when a step has both a position and an error count, which is that the count of things needing attention leads and the rest follows.
One trap in W3C's own suggestion
The HTML progress element is drawn by the operating system, and W3C notes that on some systems it animates. An animation that starts on its own, runs past five seconds and sits alongside other content engages 2.2.2 Pause, Stop, Hide. The tutorial's own fix is browser-specific CSS on the element. If you take the technique, take the fix with it.
Step Five, Decide What Going Back Is Allowed to Cost
Linking back to a completed step is a real kindness and it comes with an obligation. W3C says that where you offer it, the data already entered in the current step has to be saved. Otherwise reviewing step two quietly destroys the work somebody did on step four, and they find out at the end.
Where the form finishes a purchase, signs something, submits a test answer or changes data somebody owns, one more rule arrives. 3.3.4 Error Prevention at Level AA wants one of three things, and the third is the natural answer for a wizard. Make the submission reversible, check the entries and give a chance to correct them, or put a review-and-confirm step in front of the finish. Most branching forms of any consequence should be reaching for the third one anyway.
What the Worksheet Buys You
One page with five columns, which you can rule up in a spreadsheet before anybody opens a browser.
- The path, given a name a person would use. Applicant under 18, no vehicle. Not Path 4.
- The answers that reach it, in order, so somebody else can walk it next quarter without asking you.
- The states inside it, counting the error state and the confirmation, because those are screens too.
- What was checked, naming the browser and the assistive technology rather than saying tested.
- What was not opened, which is the column that makes the other four honest.
That last column is the reason the whole exercise is worth doing, and it is the one that gets left out. A scope with nothing written in it is not a scope with full coverage. It is a scope nobody wrote down.
Writing the scope down matters more here than on a set of ordinary pages, and the standard is the reason. Where a series of pages makes up one process, every page in that series has to conform before any single page in it counts as conforming. So an untested step five is not a small gap at the end of the report. It is why steps one to four cannot be signed off. If you would rather hand the whole shape to somebody else, that is what a wizard and multi-step audit is for, and telling us the number of steps and branches up front is what makes the scope real. What each package covers is on pricing.
The Ten-Point Form Check
Run this on each path you selected, not once on the form as a whole.
- Click every label. Does focus jump to its field?
- Are labels visible after typing starts?
- Are radio and checkbox groups wrapped in a fieldset with a legend, and does each option carry its own label?
- Are required fields marked in text, rather than by a red asterisk alone?
- Submit empty. Does each error name its field, say what is wrong, and say what would fix it?
- Do the errors reach a screen reader user, by announcement or by focus moving to a summary? One route, not both.
- Are errors marked by more than color?
- Is
autocompleteset on the fields asking about the user themselves? - Can you complete the form by keyboard alone?
- Can you paste into the password field?
One honest limit
A scanner will tell you a label is missing. It cannot tell you your label says Field 3, your error message says Invalid input, or your three-step checkout loses focus between steps. Those are the ones that actually cost you the sale, and they need a person. That is what our forms accessibility audit does.