PDFAccess PDF to accessible web content
← Journal
Guide

Accessible Forms: Labels, Error Handling, and Autocomplete

6 min min read

Forms are public authorities' most important digital interface with citizens — and one of the most frequent sources of accessibility failures. Three WCAG 2.1 criteria set the framework: correct labels, understandable error handling, and semantic autocomplete. This guide explains the requirements and the typical errors found in self-service solutions.

Forms and Accessibility

A form that cannot be operated without a mouse — or whose error messages are communicated solely through colour — is effectively inaccessible to a wide range of citizens. Forms are the interface through which citizens apply for benefits, report changes of circumstances, and submit declarations. Yet they are consistently one of the categories generating the most failures in supervisory reports from the Danish Agency for Digital Government.

Three WCAG 2.1 success criteria define the requirements:

  • 3.3.2 — Labels or Instructions (Level A): All form fields must have clear, programmatically associated labels.
  • 3.3.1 — Error Identification (Level A): Errors must be identified and described in text.
  • 1.3.5 — Identify Input Purpose (Level AA): Form fields collecting personal information must use standardised autocomplete attributes.

These three criteria address the most common failure modes and are closely related in practice.

Labels: Visual Presence Is Not Enough

WCAG 3.3.2 requires that all interactive form fields have a label — a clear text designation that explains what the field expects. It is not sufficient for the label to be visually present: it must be programmatically associated with the field, so that screen readers and assistive technologies can communicate the field’s purpose to the user.

In HTML, this is achieved using <label> with a for attribute pointing to the field’s id:

<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">

Placeholder text is not a substitute for a label. Placeholder text disappears when the user begins typing — and many screen readers do not announce it as a label. A field with only placeholder text does not meet WCAG 3.3.2, regardless of how clear it appears visually.

Hidden Labels and ARIA

In some design patterns, the visible label is intentionally hidden — for example, in search fields where the field’s purpose is clear from context. It is acceptable to visually hide a label using CSS, provided it remains present in the DOM and correctly associated with the field. Alternatively, aria-label or aria-labelledby can be used to give a field a programmatic label without a visible text element.

A field with no label at all — neither visible, CSS-hidden, nor via ARIA — is a violation of 3.3.2 and is the single most common error in public sector self-service solutions. The Danish Agency for Digital Government identifies missing labels as one of the three most widespread accessibility failures on municipal websites.

Required fields must be marked, and the marking must be explained. An asterisk (*) without explanation is not sufficient. Many implementations place the explanation at the top of the form — “Fields marked with * are required” — which is acceptable, provided the explanation is accessible to screen reader users.

Error Handling: More Than a Red Border

WCAG 3.3.1 (Error Identification, Level A) requires that errors upon form submission are identified and described in text. Marking a field with a red border alone is not sufficient — colour alone is not accessible (WCAG 1.4.1), and users who are colour-blind or use a screen reader receive no information about the error.

An accessible error message must meet three conditions:

Specificity: The message must identify precisely which field has an error, and describe what is wrong. “There are errors in the form” is insufficient. “Email address: Invalid format — please include an @ symbol” gives the user enough information to correct the error.

Programmatic association: The error message must be linked to the relevant field via aria-describedby, or placed immediately adjacent to the field in the DOM, so that the screen reader announces it when the field receives focus.

Focus management: When a form is validated and rejected, focus should move to the error summary or the first field in error. Many implementations reload the page and return focus to the top — leaving keyboard and screen reader users with no orientation as to what went wrong.

Real-Time Validation

WCAG 3.3.1 applies primarily upon submission, but many modern forms validate continuously as the user types. Real-time validation is not a requirement — but if implemented, error messages should be shown when the field loses focus (on blur), not as the user is still typing. Error messages appearing after every keystroke are disruptive for screen reader users and rarely serve their intended purpose.

WCAG 3.3.3 (Error Suggestion, Level AA) and 3.3.4 (Error Prevention, Level AA) extend the requirements further: solutions with legal or financial consequences should give users the opportunity to review and correct their submission before final confirmation.

Autocomplete and WCAG 1.3.5

WCAG 1.3.5 (Identify Input Purpose, Level AA) is one of the criteria most frequently overlooked in public sector self-service solutions — and one of the most valuable for citizens.

The criterion requires that form fields collecting personal information be marked with standardised autocomplete attributes. The purpose is to allow browsers and assistive technologies to fill in fields automatically — so that citizens with cognitive disabilities, reading difficulties, or motor limitations do not have to re-enter the same information across form after form.

Examples of correct usage:

<input type="text"  autocomplete="name"           ...>
<input type="email" autocomplete="email"          ...>
<input type="tel"   autocomplete="tel"            ...>
<input type="text"  autocomplete="street-address" ...>
<input type="text"  autocomplete="postal-code"    ...>
<input type="text"  autocomplete="bday"           ...>

W3C publishes a complete list of approved autocomplete values as part of the WCAG 2.1 documentation. Fields collecting national identification numbers, dates of birth, or payment information are explicitly referenced in the standard.

autocomplete="off" must not be used to circumvent the requirement. Disabling autocomplete is only legitimate where there is a concrete security justification — for example, a field for one-time codes or session-bound tokens.

Forms in PDF Documents

Many public authorities distribute forms as PDF files — either as static templates intended to be printed and signed, or as interactive PDF forms with fillable fields. Both types present particular accessibility challenges.

Interactive PDF forms must meet PDF/UA requirements to be accessible: each field must have a tooltip-based label, the tab order must correspond to the logical reading sequence, and required fields must be programmatically marked. Even well-structured PDF forms are generally more difficult to navigate by keyboard and screen reader than HTML forms — and they support neither native browser autocomplete nor browser-native error validation.

For forms that represent citizens’ only route of access to a public service, guidance from the Danish Agency for Digital Government indicates that they must either meet PDF/UA or be supplemented with an accessible HTML alternative. See the articles on the PDF/UA standard and PDF to HTML for a review of the technical requirements and conversion options.

Checklist: Accessible Forms

Use this checklist to verify that your forms meet WCAG 2.1 AA:

  • All form fields have a <label> programmatically associated with the field (WCAG 3.3.2)
  • Placeholder text is not used as a substitute for labels (WCAG 3.3.2)
  • Required fields are marked, and the marking is explained in text (WCAG 3.3.2)
  • Error messages identify precisely which field has an error — in text (WCAG 3.3.1)
  • Errors are not communicated solely through colour or icon (WCAG 1.4.1)
  • Focus moves to the error summary or first field in error upon submission
  • Form fields collecting personal information have correct autocomplete attributes (WCAG 1.3.5)
  • autocomplete="off" is not used without a security justification (WCAG 1.3.5)
  • The form can be operated entirely by keyboard (WCAG 2.1.1)
  • Screen readers announce error messages correctly via aria-describedby or equivalent