Forms
Form accessibility checklist
An accessible form gives every field a visible label tied to it, works from a keyboard alone, keeps enough contrast in its text and borders, describes errors in words, and does not rush anyone. The checklist below turns that into 20 checks mapped to WCAG 2.2 success criteria, each with a test you can run in a few minutes before publishing.
Nuwan Madhusanka · Co-founder
8 min read · Published · Updated
A form accessibility checklist comes down to five things: every field has a visible label that is tied to it, the whole form works from a keyboard, text and borders have enough contrast, errors are named in words with a way to fix them, and nobody is rushed. The 20 checks in the table at the end of this article map each of those to a WCAG 2.2 success criterion and give a test you can run without special software. Run them on every form before it goes live, and again whenever the theme or layout changes.
W3C’s forms tutorial opens with a point that sits under all of them: people prefer simple, short forms, and asking for more than the task needs makes them more likely to abandon it. The most accessible field is the one you removed.
Labels
A label has three jobs. It has to be visible, it has to be tied to its field, and it has to describe what goes in it.
Visible. Success criterion 3.3.2, Labels or Instructions, requires labels or instructions wherever input is needed. Placeholder text does not count as a label, because it disappears as soon as someone types. The Merriwether Books contact form labels every field in plain words, “Your name”, “Your email”, “Phone number, if you chose phone”, so the form still reads correctly with every box filled in.
Tied to the field. Success criterion 1.3.1, Info and Relationships, asks that the relationship a sighted person sees can be determined by software. WebAIM explains why: sighted users connect a label to its field visually, and other users need the connection in the code so the label is announced when the field receives focus. On a published classic form, the labels on text, number, date and choice fields are linked to their inputs, which you can confirm by clicking the label text and watching the cursor land in the field.
Descriptive. Success criterion 2.4.6, Headings and Labels, asks that labels describe purpose. A label reading “Details” passes the first two tests and fails this one. Read the labels alone in order. If the list does not tell you what the form collects, rewrite them.
Mark required fields with more than colour, which is success criterion 1.4.1. A classic form puts an asterisk after the label of a required field, a symbol rather than a colour, and a line near the top explaining the asterisk finishes the job.
Contrast
Two ratios matter. Text needs at least 4.5 to 1 against its background under success criterion 1.4.3, with a lower bar for large text. Borders, tick boxes and focus indicators that identify a control need 3 to 1 against adjacent colours under success criterion 1.4.11, Non-text Contrast.
Themes are where contrast is won or lost. A classic form has 12 built-in themes and a conversational form has 25, with 22 colour palettes that recolour whichever theme is applied. The Theme Builder exposes an accent colour, a form background and an input background, plus an input style of outline, filled or underline. An underline input on a pale background is the combination most likely to fail the 3 to 1 border check, and a pale accent colour behind white button text is the one most likely to fail 4.5 to 1. Check both with a contrast checker after every palette change, not only when the form is first built.
The hazard report form is meant for two minutes on a phone in a hospital corridor, so check it in bright light too. A ratio that passes at a desk can be hard to read under fluorescent tubes.
Keyboard
Success criterion 2.1.1 asks that everything works from a keyboard. The test is blunt and effective: put the mouse away and complete the form using Tab, Shift and Tab, Space to tick, the arrow keys inside option groups and Enter to activate buttons. Include the dropdown, the date field and any upload.
Three related checks follow from the same run. Focus should move in the order the fields appear (2.4.3, Focus Order). You should always be able to see where focus is (2.4.7, Focus Visible). And the focused field should never be hidden behind something fixed on the screen, which WCAG 2.2 added as 2.4.11, Focus Not Obscured. That last one matters if you turn on the sticky submit button, which pins the buttons to the bottom of the screen. Tab to the final fields in a short window and make sure they are not tucked behind the bar.
Two behaviours are worth knowing while testing. On a classic form, pressing Enter inside a single line field does not send the form, so a stray keypress will not submit half an answer. On a conversational form, Enter moves to the next question from most fields, while a long text box keeps Enter for new lines. The newsletter signup is a conversational example worth running through this way, including its consent tick on its own screen.
Target size is the pointer version of the same concern. Success criterion 2.5.8 sets a minimum of 24 by 24 CSS pixels for controls, with exceptions for spacing. The visitor sign in form is opened from a QR code at a factory door and asks for five separate ticks, one per site rule, so tap every tick box on a phone, with a thumb, before printing the poster. Questions that need a precise drag are the hardest case; the note on slider questions explains why a row of tappable points works better.
Errors
Success criterion 3.3.1, Error Identification, requires that a detected error is identified and described in text. Success criterion 3.3.3, Error Suggestion, adds that the message should say how to fix it when the fix is known. W3C’s understanding document gives the contrast between “Email is not valid”, which meets the first, and a message that also shows the expected format, which meets both.
Test by sending the form empty. On a published classic form, the first missing required field is named in a short message built from its label, such as “Your email is required”, and a conversational form says “Please answer:” followed by the label. Because the label is the message, a clear label is also a clear error. Then break a length or number rule and read what comes back; limits are checked when the form is sent, so print any limit in the label rather than leaving people to discover it. The dedicated article on form error messages goes further into wording.
With a screen reader running, send the form with a field missing and listen. Success criterion 4.1.3, Status Messages, asks that a message like this is announced without focus being moved to it. It is a quick check and the only way to be sure.
Time limits
Success criterion 2.2.1, Timing Adjustable, requires that any time limit set by the content can be turned off, adjusted or extended, with at least 20 seconds to extend when warned. Most forms have no deliberate limit, which is the best answer. Test anyway by leaving a form open for twenty minutes, returning and sending it, especially on a secret key form, which asks for the key each time the page is opened.
Long forms raise a related need. A form with legal or financial consequences should let people check and correct answers before the final button, which is success criterion 3.3.4. A paginated classic form has a Back button on every page after the first, so walking back through the steps is a practical review. And success criterion 3.3.7, Redundant Entry, asks that information already given is not typed again in the same process, so strike out any field that repeats an earlier answer.
The 20 checks
The table at the end of this article lists all twenty checks in the order of the sections above, with the WCAG 2.2 criterion number, its name and level, and a test for each. Every test uses tools you already have: a keyboard, a narrow window, a contrast checker, and for two checks the screen reader built into your computer or phone.
Common mistakes
Testing only with a mouse. A form that looks finished can be impossible to send from a keyboard.
Checking contrast once. A palette change months later quietly undoes it.
Explaining a field in a place the respondent never sees. On a classic form, the description box on most fields is not shown, so help has to go in the label, the sub-label or a paragraph above.
Relying on a signature pad alone. Offer the typed route, and keep signed forms classic.
Asking for everything. Every extra field is one more thing to label, test and fix.
Build it
The single column form page shows the classic layout that stacks every field at full width, which keeps focus order matching visual order on any screen; a free flow layout also falls back to a single column on a phone. Of the 41 component types, labels and sub-labels come with each field, and the paragraph, heading and subheading components carry the instructions a respondent must read. Classic and conversational forms both support the same checks, and photo and inline signature fields render in both.
Use the theme building guide to set colours you have checked, then save the theme so every later form starts from a palette that already passes. Before choosing between the two formats, the article on conversational against classic forms sets out what each can collect.
| Check | WCAG 2.2 criterion | How to test |
|---|---|---|
| Every field has a visible label that says what to enter | 3.3.2 Labels or Instructions (A) | Read the form top to bottom and confirm no field depends on placeholder text to explain itself |
| Each label is tied to its field | 1.3.1 Info and Relationships (A) | Click each label; the cursor should land in its field |
| Labels describe the purpose, not a vague heading | 2.4.6 Headings and Labels (AA) | Read the labels alone, in order, and check each still makes sense |
| Required fields are shown by more than colour | 1.4.1 Use of Color (A) | View the form in greyscale and check every required field is still marked |
| Nothing important lives in placeholder text | 3.3.2 Labels or Instructions (A) | Type one character in each field and check no instruction disappeared |
| A group of choices has a question naming the group | 1.3.1 Info and Relationships (A) | With a screen reader, move to one option and listen for the question |
| Text reaches a contrast ratio of at least 4.5:1 | 1.4.3 Contrast (Minimum) (AA) | Run labels, hints, option text and button text through a contrast checker |
| Field borders, tick boxes and focus rings reach 3:1 | 1.4.11 Non-text Contrast (AA) | Check the input border against the form background, especially with an underline style |
| The form works at 320 CSS pixels wide without sideways scrolling | 1.4.10 Reflow (AA) | Narrow the browser window or open the form on a phone |
| Every field, option and button works from the keyboard | 2.1.1 Keyboard (A) | Complete and send the form with Tab, Shift and Tab, Space, Enter and the arrow keys only |
| Focus moves in the same order as the fields appear | 2.4.3 Focus Order (A) | Tab through slowly and watch for focus jumping across rows |
| The focused field is always visibly marked | 2.4.7 Focus Visible (AA) | Tab through the form and check you can always see where you are |
| A focused field is never fully hidden behind a sticky bar | 2.4.11 Focus Not Obscured (Minimum) (AA) | With a sticky submit bar on, tab to the last fields in a short window |
| Buttons, options and tick boxes are at least 24 by 24 CSS pixels | 2.5.8 Target Size (Minimum) (AA) | Measure the smallest control in the browser's developer tools, or tap each on a phone |
| There is no time limit, or it can be turned off, adjusted or extended | 2.2.1 Timing Adjustable (A) | Leave the form open for twenty minutes, then finish and send it |
| Nobody types the same information twice | 3.3.7 Redundant Entry (A) | List every field and strike out any that repeats an earlier answer |
| A missed or broken answer is named in text | 3.3.1 Error Identification (A) | Send the form empty and read what appears |
| The error says how to fix it | 3.3.3 Error Suggestion (AA) | Break a length or number rule and check the message tells you what to change |
| A form with legal or financial effect can be checked before it is sent | 3.3.4 Error Prevention (Legal, Financial, Data) (AA) | Confirm there is a way to review and correct answers before the final button |
| Messages are announced without moving focus | 4.1.3 Status Messages (AA) | With a screen reader running, send the form with a missing field and listen |
A finished example
A contact form template needs a name, an email, the message and very little else, plus a clear line on when a reply will arrive. This one has eight fields, five of them required, and the two doing the real work are the subject dropdown that routes the message and the introduction that prints the reply time before anyone writes. It states the phone number rather than hiding behind the form, and it does not sign anyone up to anything. Classic, because eight short fields on one screen is faster than eight screens.
Read the contact form templateQuestions people ask
Which version of WCAG should a form meet?
WCAG 2.2 is the current W3C Recommendation, and testing to level AA covers every level A criterion as well. Version 2.2 added criteria that matter directly to forms, including Focus Not Obscured, Target Size (Minimum), Redundant Entry and Accessible Authentication. The Australian Government Style Manual treats accessibility as a mandatory standard for government agencies and tells them to test content against the WCAG success criteria.
Is an asterisk enough to mark a required field?
An asterisk is a visible symbol, so it does not rely on colour alone, which is the point of success criterion 1.4.1. It still needs explaining once. Add a short line near the top of the form saying fields marked with an asterisk are required, and consider writing if you have one into the labels of optional fields so the difference is obvious.
Do I need a screen reader to test a form?
For most of this checklist, no. Keyboard, contrast, reflow, target size and label checks need only a browser and a contrast checker. Two checks really do need one: whether a group of options announces its question, and whether error messages are read out. The screen readers built into desktop and phone operating systems are enough for a first pass.
Are conversational forms more accessible than classic forms?
Neither is automatically better. A conversational form shows one question per screen, and Enter moves to the next question from most fields, which keeps the focus path simple. A classic form lets people review everything at once, which helps anyone checking answers. Run the same twenty checks on either. The comparison article on this site covers which field types each format supports.
Is a signature field accessible?
A drawn signature needs a pointer, which excludes some keyboard users. The inline signature can be drawn or typed, on a classic or a conversational form, so test that the typed route works from the keyboard before relying on it. Keep a way to reach you for anyone who cannot use either route, such as a phone number beside the field.
How often should a form be retested?
Every time the theme, the layout mode or a field type changes, and before any form that carries legal or financial weight goes live. A colour palette swap can drop contrast below the minimum without anyone noticing, and moving from single column to a free layout can change the focus order. Keep the twenty checks as a standing list and tick it off on each publish.
Written by
Nuwan Madhusanka · Co-founder
Works across the builders and the export paths: how a form becomes a PDF, how a flyer canvas becomes a print file, and how a signed document carries its audit trail.
LinkedIn profileWritten and checked by the OneCraft team. Last checked .
Make your own form
Describe what you need and the generator writes and designs it, then you edit anything you like.
See what it can makeRead next
How to write form instructions
Put each instruction where it is read at the moment it is needed: rules that decide whether an answer is accepted go in the label, a one line hint goes under the field, rules for a whole section go in a short paragraph above it, and what to have ready goes before the first question. Keep every instruction to one idea, and never leave anything important in placeholder text.
Form privacy notice checklist
A privacy notice on a form tells people, at the moment they type their details, who is collecting them, why, who else will see them, whether they go overseas, and how to get access or complain. Australian Privacy Principle 5 lists ten matters, and on most forms they fit in a short paragraph above the first field.
Form error messages: best practices for wording and placement
A good form error message sits next to the field it is about, says in plain words what went wrong and exactly how to fix it, and appears when the person has finished with the field or pressed the button, never while they are still typing. The best error message of all is the one that never appears, because the rule was written into the label first.
For the steps inside the builder, read the guide on this topic.