Resources · 32
Design accessible forms and recoverable errors
Guide entry, explain failure and preserve a person’s progress through the task.
· 7 min
What this guide helps achieve
- Limit fields
- Name and guide
- Explain errors
- Test recovery
Quick check
- Does every field have a perceivable name?
- Are expected formats explained before entry?
- Does an error identify its field and possible correction?
- Are valid values retained?
- Can the task finish with keyboard and zoom?
Step-by-step method
- 01
Start from the task
List only data needed to complete it and the steps a person must understand. Remove requests that do not serve the transaction.
Deliverable: minimal form and field rationale.
- 02
Label and group
Connect each control with a visible label, group related choices and place help nearby. Check reading and tab order.
Deliverable: tested structure and labels.
- 03
Prevent mistakes
Offer format examples and state constraints before submission. Do not use color alone to convey that a field is required.
Deliverable: instructions and entry states.
- 04
Explain each failure
After validation, announce a summary, connect each issue to its field and describe how to resolve it. Keep correct values and context.
Deliverable: correctable error scenario.
- 05
Handle outages
Distinguish entry error, business refusal, timeout and server incident. Give a next step without pretending a request succeeded.
Deliverable: messages and recovery per state.
- 06
Test real tasks
Replay success and failure with keyboard, zoom, mobile and appropriate assistance. Measure blockers, fix them and retest.
Deliverable: evidence of task completion.
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Completeness | Needed fields with labels and help | Fix ambiguous controls |
| Errors | Failures with explanation and field link | Rewrite messages |
| Recovery | Values retained after correction | Fix state management |
| Task | Journeys completed with keyboard and zoom | Remove barriers |
Common pitfalls
- Using placeholders instead of labels
- Showing only “an error occurred”
- Erasing the whole form after a mistake
- Testing only the happy path with a mouse
Frequently asked questions
Is a placeholder enough?
No. An identifiable label should remain available while a person enters a value.
When should an error appear?
Choose a useful moment and explain cause and remedy without needless interruption.
What if the server fails?
Do not claim success; retain what can be saved and offer understandable recovery.
Forms: criteria, errors and contrast
An accessible form lets people understand the request, reach controls, correct an error and finish the task. For an incident-reporting portal, service request or authentication journey, quality also depends on waiting, failure and backtracking states.
This editorial selection connects 17 WCAG 2.2 Level A or AA criteria to review questions and evidence to retain. Identifiers, English titles and levels were checked against the W3C Recommendation of 12 December 2024, consulted on 23 October 2026. The selection does not cover every criterion applicable to a page or process.
Separate the rule, its explanation and observed evidence
| Reading layer | What it provides | How to use it |
|---|---|---|
| WCAG 2.2 Recommendation | Normative text: read the criterion, definitions and exceptions together. | Connect the finding to the exact criterion and examined scope. |
| WAI Understanding and tutorials | Informative explanations and guidance for interpretation and implementation. | Use them to prepare checks without presenting them as new normative requirements. |
| Journey observation | A check on a page, version, state and configuration. | Retain reproduction steps and evidence; a calculation or scanner does not replace complete evaluation. |
W3C · Web Content Accessibility Guidelines (WCAG) 2.2 · Recommendation · 12 December 2024
17 criteria for a form review
Questions and checks below are CIE editorial methodology. Each criterion links to the dated normative text; its Understanding link leads to an informative explanation. Levels are neither a score awarded to this site nor an audit result.
| W3C criterion and level | CIE review question | Evidence or check to prepare |
|---|---|---|
| 1.3.1 · Info and Relationships Level A | Do field labels and groups remain understandable in the semantic structure? | Accessibility tree and traversal of named groups. |
| 1.3.5 · Identify Input Purpose Level AA | For personal inputs covered by the taxonomy, can software identify the input purpose? | Purpose-appropriate autocomplete tokens; distinguish a label from a purpose token. |
| 1.4.1 · Use of Color Level A | Can an error or selection be understood without relying on colour alone? | Error text, field identification and state independent of red or green. |
| 1.4.3 · Contrast (Minimum) Level AA | Does meaningful text stand out from its background in relevant states? | Actually adjacent colours, text size and weight; criterion threshold and exceptions. |
| 1.4.11 · Non-text Contrast Level AA | Is visual information needed to identify components and states distinguishable? | Necessary border, icon or other cue compared with adjacent colours; examine exceptions. |
| 2.1.1 · Keyboard Level A | Can the journey’s actions be operated by keyboard within the criterion’s scope? | Pointer-free scenario: selection, entry, help, correction and submission. |
| 2.4.7 · Focus Visible Level AA | Can visitors see which interactive element has keyboard focus? | Tab and Shift+Tab through initial, error and confirmation states. |
| 2.4.11 · Focus Not Obscured (Minimum) Level AA | Does the focused component remain at least partly visible despite author-created content? | Test sticky headers, banners and panels; this AA minimum does not mean no obscuration at all. |
| 2.5.3 · Label in Name Level A | Does the accessible name contain visible label text where this criterion applies? | Compare visible text and computed name, including for voice control. |
| 2.5.8 · Target Size (Minimum) Level AA | Do pointer targets reach 24 × 24 CSS pixels or satisfy a criterion exception? | Measure bounds and examine spacing, equivalent control, inline text, user-agent control or essential presentation. |
| 3.3.1 · Error Identification Level A | When an input error is automatically detected, are its field and nature described in text? | Submit a missing value and an incorrect format; retain the message associated with the field. |
| 3.3.2 · Labels or Instructions Level A | Are necessary labels or instructions available before entry? | Requirements known in advance: expected field, mandatory entry and useful format. |
| 3.3.3 · Error Suggestion Level AA | Is a known correction suggested where it does not compromise security or content purpose? | Compare a generic message with actionable help for the error actually detected. |
| 3.3.7 · Redundant Entry Level A | Within one process, is previously supplied information populated or available to select, subject to exceptions? | Return to a step; distinguish still-valid data, essential requirements and security needs. |
| 3.3.8 · Accessible Authentication (Minimum) Level AA | Does an authentication step require a cognitive test without an alternative, assistance or specified exception? | Usable password-manager, paste and other mechanisms; read the complete exceptions. |
| 4.1.2 · Name, Role, Value Level A | Are component name, role, value and relevant states exposed to assistive technologies? | Inspect native and custom controls, then change their states. |
| 4.1.3 · Status Messages Level AA | Can relevant status messages be presented by assistive technology without receiving focus? | Waiting, error or brief result; test announcements and avoid unnecessary interruptions. |
Five recovery situations to write and test
| Illustrative situation | Useful feedback | Check |
|---|---|---|
| Required field left blank | Identify the field and explain the expected information in text. | Keep the message associated with the field and the label visible. |
| Unaccepted format | Explain the actual accepted format and suggest a correction where possible. | Do not erase other valid entries; let the person resume correction. |
| Multiple input errors | Provide an overview and messages close to the fields. | Error-summary links reach the correct controls and keyboard order remains coherent. |
| Service waiting or failure | Say whether the request is pending, failed or requires another action. | Useful status feedback is perceivable without repeated announcements on every keystroke. |
| Returning to a step in the same process | Retain still-valid information or make it available to select. | Examine 3.3.7 exceptions and avoid unjustified forced re-entry. |
W3C WAI · Forms Tutorial · Labeling Controls · Practical guidance · consulted 2026-10-23
W3C WAI · Forms Tutorial · User Notifications · Practical guidance · consulted 2026-10-23
Local contrast calculator
Calculation uses two opaque, solid sRGB colours. Enter #RGB or #RRGGBB, case-insensitively. The ratio uses relative luminance and (lighter L + 0.05) / (darker L + 0.05). Numeric display is rounded for reading; threshold comparisons use the unrounded result.
This model does not inspect website styles and does not handle transparency, gradients, background images, video, other colour spaces or rendering variations. It compares numbers with thresholds; it does not decide whether a criterion applies or its exceptions are satisfied.
Calculated ratio : ·
| Reference and use | Ratio threshold | Comparison for the entered pair |
|---|---|---|
| 1.4.3 · AA · normal text | 4.5:1 | |
| 1.4.3 · AA · large text | 3:1 | |
| 1.4.6 · AAA · normal text | 7:1 | |
| 1.4.6 · AAA · large text | 4.5:1 | |
| 1.4.11 · AA · relevant non-text visual information | 3:1 |
WCAG large-scale text includes at least 18 point, or 14 point bold, or equivalent sizing under the definition’s rules. Text merely looking “large” on screen does not justify choosing a reduced threshold. For non-text, examine necessary identifying information and all relevant adjacent colours.
W3C WAI · Understanding SC 1.4.3 · Contrast (Minimum) · Informative explanation · consulted 2026-10-23
W3C WAI · Understanding SC 1.4.6 · Contrast (Enhanced) · Informative explanation · consulted 2026-10-23
W3C WAI · Understanding SC 1.4.11 · Non-text Contrast · Informative explanation · consulted 2026-10-23
Seven calculated pairs, available without JavaScript
| Learning case | Foreground / background | Calculated ratio | Numeric thresholds reached |
|---|---|---|---|
| Illustrative gold and dark background | #D4BD7F / #101719 | 9.826201:1 | 3:1 · 4.5:1 · 7:1 |
| Black and white | #000000 / #FFFFFF | 21.000000:1 | 3:1 · 4.5:1 · 7:1 |
| Grey below the 4.5 threshold | #777777 / #FFFFFF | 4.478089:1 | 3:1 |
| Grey just below the 3 threshold | #959595 / #FFFFFF | 2.995346:1 | Numeric threshold not reached |
| Grey above the 7 threshold | #595959 / #FFFFFF | 7.004729:1 | 3:1 · 4.5:1 · 7:1 |
| Red and white | #FF0000 / #FFFFFF | 3.998477:1 | 3:1 |
| Identical colours | #777777 / #777777 | 1.000000:1 | Numeric threshold not reached |
#777777 grey on white gives approximately 4.478089:1: the 4.5:1 threshold is not reached. #959595 on white gives approximately 2.995346:1: rounding it to 3.0 does not make it reach the 3:1 threshold. These are calculations, not measurements of a real journey.
A task-oriented verification method
- Define the task
Specify what the person needs to complete and the pages and states involved: entry, waiting, error, correction and confirmation.
- Test different uses
Navigate by keyboard, with zoom and on a small screen; also inspect names and states exposed to assistive technology.
- Keep reproducible findings
Record version, configuration, steps, expected and observed results. Link barriers to criteria and retain the exceptions examined.
- Retest after correction
Recheck the whole task with the actual components and services, retaining any points still requiring confirmation.
Copyright © 2020–2024 World Wide Web Consortium. W3C Recommendation WCAG 2.2, 12 December 2024. Copyright © 2023 W3C®. This document includes material copied from or derived from Web Content Accessibility Guidelines (WCAG) 2.2. Identifiers, titles and levels are attributed to W3C; questions, examples and method are CIE synthesis. This is not an official translation or a modified technical specification.
W3C · Web Content Accessibility Guidelines (WCAG) 2.2 · Recommendation · 12 December 2024
W3C · Document license · 2023 version · Terms and attribution consulted 2026-10-23
Verified documentary edition
WCAG 2.2 · Recommendation · 2024-12-12 · 2026-10-23
Source HTML SHA-256: 6e3c5fe397257cae509a2fb4752b73062cf8cbeb92c2cec618989b17e4cf7057
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
- W3C WAI — Forms tutorial
- W3C WAI — Form validation
- W3C · Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI · Understanding SC 1.4.3 · Contrast (Minimum)
- W3C WAI · Understanding SC 1.4.6 · Contrast (Enhanced)
- W3C WAI · Understanding SC 1.4.11 · Non-text Contrast
- W3C WAI · Forms Tutorial · Labeling Controls
- W3C WAI · Forms Tutorial · User Notifications
- W3C WAI · Understanding SC 3.3.8 · Accessible Authentication (Minimum)
- W3C · Document license · 2023 version
Continue exploring
Related analysis
