Accessible Forms: Labels, Errors and Validation

A form combines several critical interactions in a small space: labeling, input, validation, error handling and submission. Each of these steps can create its own barrier. The most common problems arise when visual design and programmatic structure diverge. A field looks labeled because there is text next to it, but this text is not linked to the field as a . Sighted users recognize the connection, whereas a screen reader only announces input field.

The WebAIM Million Report (2024) shows that 96.3% (WebAIM Million, 2024) of all analyzed home pages have at least one automatically detectable WCAG violation. Missing form labels have consistently ranked among the top errors for years. On top of that: automated testing tools only reliably detect a portion of all barriers (W3C/WAI). With forms in particular, manual tests with keyboard and screen reader are indispensable, because the operation logic and reading behavior only become visible in the real flow.

The Nielsen Norman Group (2023) describes that unclear error messages and poorly placed hints are among the biggest frustration factors in forms - for all users, not only for people with disabilities. An accessibly built form is therefore almost always a more user-friendly form with lower abandonment rates. Our services work precisely at this intersection of accessibility and conversion. This becomes especially visible in the extensive order and address forms of an accessible shop.

Every input field needs a programmatically linked label. The simplest and most robust way is the element with a for attribute pointing to the field's id. Screen readers then automatically announce the label when the field receives focus, and clicking the label moves focus into the field - which also enlarges the click target and helps people with motor impairments. WCAG 2.2 criteria 3.3.2 (Labels or Instructions) and 4.1.2 (Name, Role, Value) require exactly this association (W3C, 2023).

A placeholder is not a substitute for a label. It disappears when typing, is handled inconsistently by screen readers and often has insufficient contrast. If, for design reasons, no visible label is possible - for example with a search field - aria-label or aria-labelledby can be used. Visible text remains the best choice, however, because it helps all users, including people with cognitive disabilities and users of voice input who address the visible label as a command.

Required fields must be recognizable both visually and programmatically. A red asterisk alone is not enough, since its meaning is not explained and screen readers do not reliably announce it. A robust approach combines the native HTML attribute required (which also activates browser validation) with a visible hint. Additionally, the meaning of the marking should be explained at the start of the form, for example: fields marked with an asterisk are required.

Anyone using the asterisk should either make it readable for screen readers or hide it via aria-hidden and set aria-required="true" instead. Consistency is important: either all required fields are marked or - in forms where almost everything is required - only the optional fields are marked as optional. Duplicate or contradictory hints confuse more than they help.

WCAG 2.2 dedicate several criteria to errors: 3.3.1 (Error Identification) requires that an error is detected and named in text form. 3.3.3 (Error Suggestion) requires that, where possible, a specific correction suggestion is made (W3C, 2023). In practice this means: a good error message describes not only the problem but also the solution. Instead of invalid input, better: please enter an email address with an at-sign, for example name@example.com.

Every error message belongs directly at the affected field - not only in a summary at the top of the page. Programmatically, the field is marked with aria-invalid="true" and the message is linked to the field via aria-describedby. On focus, the screen reader then announces label and error message together. So that a newly displayed message is announced immediately, the message container should carry role="alert" (or aria-live="assertive").

With server-side validation, after which the page reloads, an error summary should additionally appear above the form. This lists all errors as links that jump directly to the respective field. After submission, focus is programmatically set to this summary so that screen reader and keyboard users immediately learn that and where something needs correcting. The BITV test procedure and EN 301 549 assess precisely this combination of identification, description and reachable correction (EN 301 549, 2021). Which BFSG requirements apply in detail depends on the type of your offering.

Inline validation checks input while the user is still filling in and gives immediate feedback. Implemented correctly, this reduces errors and abandonment; implemented incorrectly, it creates new barriers. The most common mistake is validating on every keystroke: it reports an error while the user is still typing, and a role="alert" would then constantly interrupt. The Nielsen Norman Group (2022) recommends validating only when the field is left (blur) and using positive feedback sparingly.

For live feedback, a region with aria-live="polite" is suitable, announcing changes without interrupting the current task. assertive or role="alert" is reserved only for urgent, blocking messages. It is important that a message which disappears again (for example because the error was fixed) does not steal focus and that the user can follow the correction path. A password field that ticks off requirements live should present them as a list with clear states rather than by color alone.

Focus management determines whether a form remains comprehensible via keyboard and screen reader. Basic rule: the tab order follows the visual reading direction, and every focused element has a clearly visible focus indicator. The criterion 2.4.11 (Focus Not Obscured), newly introduced with WCAG 2.2, requires that the focused element is not hidden by sticky headers, cookie banners or chat windows (W3C, 2023).

After submitting a form with errors, focus is actively set to the error summary or the first erroneous field. If submission was successful, focus should move to the success message so that it is announced. Programmatically set focus on non-interactive elements such as a heading requires a tabindex="-1" so that the element becomes focusable without slipping into the normal tab order. Clean focus management is part of how we approach accessible web development.

WCAG criterion 1.3.5 (Identify Input Purpose) requires that the purpose of input fields collecting personal data is programmatically determinable (W3C, 2023). This is implemented via standardized autocomplete tokens such as given-name, family-name, email, tel, street-address, postal-code or country-name. Browsers and assistive technologies can then offer stored data and enrich fields with icons - a major relief for people with motor or cognitive impairments.

In addition, the inputmode attribute controls the on-screen keyboard on mobile devices: numeric for postal codes, email for email fields, tel for phone numbers. Combined with the correct type attribute, this creates an input that produces fewer errors. Anyone operating several forms benefits twice here, because the same tokens can be reused across domains. We implement these details as standard in accessible web development.

Date fields are among the most difficult form elements. The native is often the best choice because it brings keyboard operation, localization and screen reader support. Where a custom datepicker widget is needed, it must reflect the complete keyboard pattern: navigation via arrow keys, selection via Enter, closing via Escape and correct ARIA markup as a dialog or grid. An additional text input as an alternative is always important, because not everyone can operate a calendar grid.

The expected date format must be communicated clearly, for example via help text DD.MM.YYYY linked to the field via aria-describedby. Fields split into sub-fields (day, month, year) each need their own label and should be wrapped in a