Fixes by subject · 59 techniques
How to Fix Forms and Error Messages
Every other accessibility failure costs somebody effort. A broken form costs them the whole task, and unlike a missing alt attribute you feel it in your numbers.
Forms are the subject automated testing is worst at. Guideline 3.3 covers labels, errors and the help around them across nine criteria, and between those nine there is exactly one automated test rule, still proposed rather than approved. The gap has a shape you can point at. A field labeled only by its placeholder does have an accessible name, so it passes the machine check. Then the label vanishes the second somebody starts typing. So the techniques here cover labelling that survives contact with a user, grouping related controls, and error messages that name the field and say what to do about it. They also cover announcing those errors rather than only showing them, and the autocomplete values that let a browser fill fields in for people who find typing hard.
All 59 techniques
They run in technique order, and each one carries a tag. Sufficient techniques satisfy a rule. Advisory ones help without being required. Failures document a specific way of getting it wrong. None of them is mandatory, because W3C publishes techniques as documented ways of meeting a criterion rather than the only ways, so your own approach conforms as long as it meets the criterion.
- H44Sufficient1.1.1, 1.3.1, 3.3.2, 4.1.2Attach a real label to every form field
- H90Sufficient3.3.2Mark required fields in the label itself
- H32Sufficient3.2.2Give every form a real submit button
- H65Sufficient1.1.1, 1.3.1, 4.1.2Label form fields when a visible label will not fit
- H71Sufficient1.3.1, 3.3.2Group related form fields with fieldset and legend
- H84Sufficient3.2.2Pair select menus with a real action button
- H85Sufficient1.3.1Group long select lists with optgroup
- H98Sufficient1.3.5Add autocomplete attributes to personal data fields
- H100Sufficient3.3.8, 3.3.9Mark up email and password inputs properly
- ARIA1Sufficient1.3.1, 3.3.2Attach help text to inputs with aria-describedby
- ARIA2Advisory1.3.1, 3.3.1, 3.3.2Tell screen readers a field is required
- ARIA9Sufficient1.1.1, 3.3.2Assemble one label from several text pieces
- ARIA17Sufficient1.3.1, 3.3.2Group related form fields with ARIA roles
- ARIA18Sufficient3.3.1, 3.3.3, 4.1.3Raise blocking errors in an alert dialog
- ARIA19Sufficient3.3.1, 4.1.3Announce form errors with role=alert
- ARIA21Sufficient3.3.1Flag invalid fields with aria-invalid
- SCR18Sufficient3.3.1, 3.3.3, 3.3.4Validate in the browser and describe the error
- SCR19Sufficient3.2.2, 3.2.5Never change context when a select changes
- SCR32Sufficient3.3.1, 3.3.3Put validation errors in the page as text
- SVR4AdvisoryStore the user's accessible-version preference
- F9Failure3.2.5Do not change context when a field loses focus
- F12Failure2.2.5Do not let session timeouts destroy user input
- F36Failure3.2.2Do not auto-submit when the last field changes
- F37Failure3.2.2Do not launch windows from a checkbox or select
- F60Failure3.2.5Do not launch new windows while users type
- F68Failure4.1.2Do not ship form controls without accessible names
- F82Failure3.3.2Do not split a phone field and drop the label
- F86Failure4.1.2Do not leave parts of a split field nameless
- F107Failure1.3.5Do not invent autocomplete attribute values
- F109Failure3.3.8, 3.3.9Never block paste in password or code fields
- F111Failure1.3.1, 2.5.3, 4.1.2Do not leave labeled controls without a name
- G13Sufficient3.2.2, 3.3.2Say what a control will do before it does it
- G80Sufficient3.2.2Use a submit button, not automatic submission
- G83Sufficient3.3.1, 3.3.2, 4.1.3Tell users which required fields they missed
- G84Sufficient3.3.1, 3.3.3, 4.1.3Explain when input is not an allowed value
- G85Sufficient3.3.1, 3.3.3, 4.1.3Explain format errors and show the fix
- G89Sufficient3.3.2, 3.3.5Show the expected format with an example
- G98Sufficient3.3.4Let users review answers before final submission
- G99Sufficient3.3.4Make deleted data recoverable
- G105Sufficient2.2.5Save user data across session re-authentication
- G131Sufficient2.4.6, 3.3.2Write labels that describe their fields
- G139Advisory3.3.1, 3.3.3Let users jump straight to form errors
- G143Sufficient1.1.1Describe every CAPTCHA's purpose in text
- G144Sufficient1.1.1Offer a second CAPTCHA in another modality
- G155Sufficient3.3.4Add a confirmation checkbox before final submission
- G162Sufficient1.3.1, 2.5.3, 3.3.2Position labels where users expect them
- G164Sufficient3.3.4State how long requests can be canceled
- G167Sufficient3.3.2Label fields with their adjacent buttons
- G168Sufficient3.3.4Ask for confirmation before completing risky actions
- G177Sufficient3.3.3, 4.1.3Suggest corrections when input fails validation
- G184Sufficient3.3.2, 3.3.5State form requirements before the fields
- G194Sufficient3.3.5, 4.1.3Spell-check text input and offer fixes
- G199Sufficient3.3.1, 3.3.3, 3.3.4, 4.1.3Confirm success when a submission works
- G218Sufficient3.3.8, 3.3.9Sign users in with an emailed link
- G221Sufficient3.3.7Carry entered data into later steps
- PDF5Sufficient3.3.1, 3.3.2Mark required fields in PDF forms
- PDF10Sufficient1.3.1, 3.3.2, 4.1.2Label every field in your PDF forms
- PDF15Sufficient3.2.2Give PDF forms an explicit submit button
- PDF22Sufficient3.3.1, 3.3.3Tell users when PDF form input is invalid
More on Forms and errors
The other 13 subjects
Knowing the technique is not the same as knowing you need it.
The free scan checks 10 pages in a real browser and maps every machine-checkable failure to the exact fix guide that clears it.