A form is where an inaccessible website stops being an annoyance and becomes a locked door. People can skim past a badly described image. They cannot skim past a job application they are unable to submit.
The Web Content Accessibility Guidelines (WCAG) are the shared yardstick. Version 2.2 became a W3C Recommendation in October 2023 and added nine success criteria, several aimed squarely at forms. Level A is the floor, AA is what laws and procurement rules usually cite, and AAA is the stretch.
Two honest notes. This is a practical guide, not legal advice. And Upform, which publishes this page, does not publish a WCAG conformance claim or a VPAT, so treat what follows as a checklist for testing your own form, whichever tool built it. For the layout rules underneath it all, see form design best practices.
The ten checks at a glance
Each check maps to one or more WCAG 2.2 success criteria, numbered as in W3C's own documents.
| Check | WCAG 2.2 success criteria | Level |
|---|---|---|
| 1. Labels and instructions | 3.3.2 Labels or Instructions, 1.3.1 Info and Relationships, 2.4.6 Headings and Labels, 1.3.5 Identify Input Purpose | A, AA |
| 2. Errors | 3.3.1 Error Identification, 3.3.3 Error Suggestion, 3.3.4 Error Prevention (Legal, Financial, Data), 4.1.3 Status Messages | A, AA |
| 3. Focus | 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured (Minimum), 2.4.3 Focus Order, 2.1.1 Keyboard, 2.1.2 No Keyboard Trap | A, AA |
| 4. Contrast | 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast | AA |
| 5. Target size | 2.5.8 Target Size (Minimum), 2.5.7 Dragging Movements | AA |
| 6. Color alone | 1.4.1 Use of Color | A |
| 7. Time limits | 2.2.1 Timing Adjustable | A |
| 8. Consistent help | 3.2.6 Consistent Help | A |
| 9. Authentication | 3.3.8 Accessible Authentication (Minimum) | AA |
| 10. Redundant entry | 3.3.7 Redundant Entry | A |
Laws usually name level AA of a specific version, not always the newest: the US Section 508 standards reference WCAG 2.0, and EN 301 549, the European standard behind the European Accessibility Act, references 2.1. Content that meets 2.2 also meets the earlier versions at the same level, so 2.2 AA is the sensible target.
1. Labels and instructions
WCAG 2.2: 3.3.2 Labels or Instructions (A), 1.3.1 Info and Relationships (A), 2.4.6 Headings and Labels (AA), 1.3.5 Identify Input Purpose (AA).
Every field needs a visible label that says what to enter, connected to the field in code so a screen reader announces it on focus. If the answer has a format, such as a date order or a file type, say so before the person types, not in an error afterward.
The placeholder is the usual failure: it vanishes on the first keystroke, it is usually pale, and screen readers treat it inconsistently. Keep it for an example. Mark required fields in words or with a symbol you explain (Upform puts an asterisk on required questions, so say what it means in the first question's description), and add autocomplete attributes (name, email, tel, street-address) to fields about the person, so browsers can fill them in.
3 →
What's your work email?
We send your confirmation here, nowhere else.
Click each label: in a well-built form, focus jumps into its field. Then turn on a screen reader (VoiceOver on Mac and iPhone, NVDA on Windows, TalkBack on Android) and move through each field. You should hear the question, whether it is required, and any instruction.
2. Error identification and suggestion
WCAG 2.2: 3.3.1 Error Identification (A), 3.3.3 Error Suggestion (AA), 3.3.4 Error Prevention (Legal, Financial, Data) (AA), 4.1.3 Status Messages (AA).
When a form rejects an answer, it has to identify the field and describe the problem in text. At AA, if you know the fix, say it: not "Invalid date" but "Enter the date as MM/DD/YYYY." A red outline alone fails, because it tells a color-blind reader nothing and a screen reader user even less.
The message must also reach people who cannot see it appear: use a live region (role="alert" or aria-live), or move focus to the field in error. For forms that create a legal or financial commitment, AA adds a duty to let people review and correct their answers before submitting, or reverse the submission afterward.
"Invalid input" in red at the top of the page → under the field: "Enter a web address that starts with https://, for example https://example.com."
Upform writes its validation errors as sentences below the answer, such as "Please enter a valid URL (e.g. https://example.com)", and checks an email address when the person presses Enter or Next, not while they type. Put the format in the description line and the error rarely has to appear.
Submit every question empty, then with a wrong format. For each error, ask: does it name the field, does it say how to fix it, and does a screen reader announce it without you hunting for it?
3. Focus visible, and never hidden
WCAG 2.2: 2.4.7 Focus Visible (AA), 2.4.11 Focus Not Obscured (Minimum) (AA, new in 2.2), 2.4.3 Focus Order (A), 2.1.1 Keyboard (A), 2.1.2 No Keyboard Trap (A).
Keyboard users move with Tab, Shift+Tab, Enter and Space, and the focus indicator is their cursor. The most common failure is one line of CSS that removes the browser's outline and puts nothing in its place.
WCAG 2.2 adds a check for modern layouts: a focused element must not be entirely hidden by author content such as a sticky header, a chat bubble or a cookie banner. Embedded forms are exposed because the host page brings its own sticky elements, so test them inside the real page (see how to embed a form). At AAA, 2.4.13 Focus Appearance also sets a size and a 3:1 change for the indicator itself.
Focus should also follow reading order and never get stuck in a widget such as a date picker. In multi-step forms, it should land in the answer field on each new step, not back at the top of the page. Upform places the cursor in the answer field when a text question appears, and Enter moves on from a single-line answer; in Long Text, Enter adds a line and the Next button moves on.
Put the mouse away and complete the form by keyboard. Can you always see where you are? Does anything cover the focused element near the bottom of a phone-sized window? Can you go back, change an answer and still submit?
4. Contrast: text, fields and states
WCAG 2.2: 1.4.3 Contrast (Minimum) (AA), 1.4.11 Non-text Contrast (AA).
Text needs at least 4.5:1 against its background, or 3:1 for large text (24px regular, or about 18.7px bold). That includes help lines, placeholder hints, error messages and the button label. Anything that identifies a control or its state needs 3:1 against its neighbors: the line that shows where to type, the focus ring, the fill that shows which option is chosen.
Theme colors are the owner's choice, so contrast is partly your job. In Upform's Design panel you set six colors: primary, background, text, button, button text and card. The default design (text #1a1a2e on white, a #171717 button with white text) gives the question and the Next button far more than 4.5:1. The risk starts when you swap in brand colors.
2 →
How should we get back to you?
We only use this to answer your request.
Measure these pairs whenever you change a color.
| Pair to check | Where it shows up | Target |
|---|---|---|
| Text on background | The question, and the description line under it | 4.5:1 |
| Button text on button | The Next button label | 4.5:1 |
| Button text on primary | The number inside a chosen Rating button | 4.5:1 |
| Primary on background | The border of a chosen option, the A, B, C letters on choices, and the asterisk on a required question | 3:1 for the border, 4.5:1 for the letters and the asterisk |
| Text on background image | Every line of text, over the busiest part of the photo | 4.5:1 |
Two details make the text pair stricter than it looks. Upform draws the description line in your text color at 70% opacity and the small sub-labels on Date and Address questions at 60%, so both sit closer to the background. On white, a text color of #333333 or darker keeps the description above 4.5:1; the sub-labels need a near-black, about #1c1c1c or darker (the default #1a1a2e only just passes). On a dark background, keep the text near white. Measure the lighter line on the published form, not the color you typed in.
With a background image, measure text against the lightest patch behind it, not the average. Once a theme passes, save it as a private theme and load it into each new form, so you start from colors you have already checked.
Use the color picker in Chrome's developer tools, which shows the ratio, or WebAIM's free contrast checker. Check each pair in its normal and chosen state, recheck after any color change, and treat a theme preset as a starting point, not a guarantee.
5. Target size
WCAG 2.2: 2.5.8 Target Size (Minimum) (AA, new in 2.2), 2.5.7 Dragging Movements (AA, new in 2.2).
Anything someone taps or clicks should be at least 24 by 24 CSS pixels, or spaced so a 24px circle centered on it does not touch the next target. Links inside a sentence, controls the browser draws itself and essential cases are exempt. On a phone, design for the AAA figure instead: 44 by 44, from 2.5.5 Target Size (Enhanced).
Forms fail this with bare radio dots, tiny remove buttons on uploaded files and ten rating buttons squeezed onto a narrow screen. The new dragging criterion adds sliders and drag-and-drop uploads: anything done by dragging needs a single-tap alternative.
In Upform, choice options run the full width of the column, Rating buttons are 40 pixels square, and the Previous and Next buttons are 44 pixels tall. File Upload does not depend on dragging: a tap anywhere on the drop zone, or on its Browse files button, opens the file picker. Slider Scale uses the browser's own range control, so a tap on the track or the arrow keys also set a value; still try it on a real phone, and if a slider is fiddly there, a Rating or Number question may serve people better.
Open the form at phone width and try every control with a fingertip, not a mouse pointer. Inspect small controls in developer tools and read their rendered size. Anything under 24 by 24 needs more size or more space.
6. Never rely on color alone
WCAG 2.2: 1.4.1 Use of Color (A).
Color can support a message; it cannot be the message. A required field marked only in red, an error shown only as a red border, a chosen option shown only by a tint: each disappears for the roughly one in twelve men with a color vision deficiency, and for anyone on a washed-out screen.
Pair color with a word, an icon or a change of shape. Upform writes errors as text and marks required questions with an asterisk. A chosen option switches from a faint border to one in your primary color, with a light wash behind it. That change is carried by color, so make it a change in lightness too: W3C's guidance on this criterion says a lightness difference of 3:1 or more can count as a cue beyond hue. A primary with at least 3:1 against the background does it; a pale primary on white does not.
View a grayscale screenshot, or emulate vision deficiencies in the Rendering panel of Chrome's developer tools. Can you still tell which questions are required, which option is chosen and which answer is wrong?
7. Time limits
WCAG 2.2: 2.2.1 Timing Adjustable (A). See also 2.2.6 Timeouts (AAA).
If a form has a time limit, people must be able to turn it off, extend it to at least ten times the default, or be warned and given at least 20 seconds to extend it with a simple action, at least ten times. Real-time events such as auctions, essential limits and limits over 20 hours are exempt.
Most form timeouts are accidental: a session that expires during a long answer, a ticket held for five minutes, a screen that moves on by itself. People using switch access, magnification or voice input hit them first. At AAA, 2.2.6 Timeouts asks you to warn people up front if inactivity can lose their data.
An Upform form has no timer: nothing counts down, and choosing an option does not jump ahead until the person presses Next. A real deadline, such as applications closing on Friday, belongs in the form's text, not in a clock on the screen.
Start the form, leave it open for half an hour, then finish it. Did anything expire, reset or move on without you?
8. Consistent help
WCAG 2.2: 3.2.6 Consistent Help (A, new in 2.2).
You do not have to offer help. But if help repeats across the pages of a process, it must appear in the same place relative to the other content each time. That covers contact details, a contact form or chat, a self-help option such as an FAQ, and a chatbot.
In a multi-step form each step counts as a page, so a "Questions? Email us" line that moves from the top of step one to the bottom of step four fails. It matters most to people with cognitive disabilities, who learn where things are and rely on them staying put.
In a one-question-per-screen form, choose one spot and one wording: end the description line with the same contact sentence on the questions that raise doubts, and repeat it on the Thank You screen.
Step through the form and note where help appears on each screen. Same wording, same relative position, every time it appears.
9. Accessible authentication
WCAG 2.2: 3.3.8 Accessible Authentication (Minimum) (AA, new in 2.2). 3.3.9 Accessible Authentication (Enhanced) is the AAA version.
No login step may rely on a cognitive function test (remembering a password, transcribing a code, solving a puzzle) unless there is an alternative or a mechanism that helps. Allow paste in password and code fields, support password managers (autocomplete="current-password" and autocomplete="one-time-code"), and offer an emailed link or a passkey. AA still allows tests that ask people to recognize objects or their own content; AAA does not.
Forms meet this at a login wall in front of the form and at a CAPTCHA at the end of it. A puzzle CAPTCHA in a login is exactly what this criterion targets, and anywhere else it still needs an alternative under 1.1.1 Non-text Content.
A published Upform form opens from its public link without an account, and its spam check is invisible reCAPTCHA v3, which scores submissions in the background instead of asking anyone to solve a puzzle. If you place the form behind your own login, that login is where this check applies.
Sign in the way a respondent would. Can you paste into every field, and does your password manager fill it? Is there a route that needs no memory and no puzzle?
10. Redundant entry
WCAG 2.2: 3.3.7 Redundant Entry (A, new in 2.2).
Within one process, anything the person already entered, or that you already gave them, must be filled in for them or offered to select. The exceptions: when re-entering is essential, when it protects security, and when the earlier answer is no longer valid.
The classic offenders are a "confirm your email" field, a delivery address retyped after the billing address, and a name asked twice. Each repeat is a chance for a typo, and a real cost for people with memory or motor impairments.
Ask once. Instead of a second address block, ask "Is the delivery address the same as your billing address?" as a Yes/No question and use conditional logic to skip the second address on yes. Instead of a confirm field, give the email its own screen so it can be read back before Next. And the Previous button in an Upform form brings back the last answer as it was left.
List every question and highlight any fact you ask for twice. Remove the repeat, fill it in for the person, or offer the earlier answer to select.
Test your form in 20 minutes
Run axe DevTools, WAVE or Lighthouse, but know that scanners catch only part of the problems, and none can judge whether an error message makes sense. This manual pass covers the rest.
Keyboard, five minutes. Complete the form without a mouse, watching the focus indicator the whole way.
Screen reader, five minutes. With VoiceOver, NVDA or TalkBack, listen for the question, required status and instruction on every field, and for each error.
Zoom and reflow, three minutes. Zoom to 200%, then narrow the window to 320 CSS pixels. Nothing should clip or need sideways scrolling (1.4.4 Resize Text, 1.4.10 Reflow).
Contrast and color, four minutes. Measure each pair from check four, then view the whole form in grayscale.
Errors, three minutes. Submit empty and wrong answers everywhere, and read each message as if you had never seen the form.
Fix what you find, publish, and repeat the pass on the live link. Then ask someone who uses assistive technology every day to try it. They will find things no checklist does.
What Upform covers, and what stays with you
A form builder decides some of this for you and leaves the rest to you. Here is the honest split for Upform's published forms.
- One question per screen, with the question above the answer and a description line for instructions.
- Validation errors written as sentences below the answer, checked when the person presses Enter or Next.
- Full-width choice options, 40px Rating buttons, 44px-tall Previous and Next buttons, and file uploads that never need a drag.
- No timers, no automatic jump ahead, and no puzzle: spam protection is invisible reCAPTCHA v3.
- Previous returns to the last question with the answer still in place.
What stays with you: the six theme colors and any background image, the wording of every question and button, where help goes, how many questions you ask, and the page you embed the form in. Those are yours to get right in any builder. The rest, such as how a screen reader announces each question and each error, only shows up when you test, so run the 20-minute pass on your published form.
Upform does not publish a WCAG conformance statement or a VPAT. If your organization needs formal documentation before choosing a tool, ask through the contact page before you commit.