Accessible Forms – Which Decisions Really Matter

From Labels to Focus Management: What Makes Forms Accessible to Everyone

A contact form that cannot be filled out. A checkout that breaks during keyboard navigation. An error message that no one understands. Forms are central interfaces of digital applications – and at the same time a common barrier on the web.

When a form is not designed to be accessible, it excludes people. This affects not only users who rely on screen readers or keyboard navigation. People with limited fine motor skills, cognitive impairments, or temporary disabilities also encounter barriers. Since June 28, 2025, the design of accessible forms has been mandatory for many companies under the Accessibility Strengthening Act (BFSG). But accessible forms are more than a legal requirement. They can improve the user experience for everyone, reduce error rates, and increase conversion rates.

This article shows which design decisions are relevant. The focus is on labels, error messages, focus management, grouping, and input assistance. All recommendations are based on the Web Content Accessibility Guidelines (WCAG 2.2) and the Accessible Information Technology Regulation (BITV 2.0).

What Matters in Accessible Forms

The design of accessible forms affects multiple levels. The following describes the most important decision areas that should be considered during the concept phase.

Labels: Clarity Instead of Guesswork

Every input field requires a clear label. This must be understandable even without visual context. If a label is missing or only visually recognizable, it remains unclear what input is expected. This affects not only screen reader users. People who have difficulty concentrating or are under time pressure also benefit from clear labels.

Formulations like "Name" are ambiguous. "First Name" or "Last Name" is better. For required fields, the asterisk alone is not enough. A legend should explain that fields marked with an asterisk are mandatory. Placeholder texts do not replace labels. They disappear during input and are not reliably available for assistive technologies.

The label must be programmatically linked to the input field. This allows screen readers to read the label when the field is focused. This connection is made through HTML structures that are implementable for developers but should already be considered during the concept phase.

Error Messages: Specific Instead of Frustrating

Error messages must be understandable and specifically state what is wrong. A message like "Invalid input" does not help. "The email address must contain an @ sign" is better. Error messages should appear directly at the affected input field, not only at the beginning or end of the form. This allows users to quickly find and correct the error.

Error messages should not rely solely on color. Red alone is not enough to indicate an error. An icon, text, or other visual marking should be used additionally. This helps people with color vision deficiency, but also everyone else who fills out forms under poor lighting conditions or on small screens.

Screen readers must be able to read error messages automatically. This is achieved through technical attributes that are implemented during development. However, the decision about which error message appears when and where is a design decision that should already be made in the UX concept.

Focus Management: Orientation During Navigation

The focus order must follow the visual and content structure of the form. Users navigating with the keyboard expect the focus to move from top to bottom and from left to right. Jumps or unexpected sequences make operation difficult and lead to abandonment.

The focus must be visible at all times. A thin, barely recognizable border is not enough. The focus indicator should have sufficient contrast to the background and be clearly visible. This is not only relevant for keyboard users. People with limited vision or cognitive impairments also benefit from clear focus management.

Context changes must not be triggered solely by focusing an element. If a dropdown menu automatically loads a new page as soon as it is focused, this is a barrier. Users should be able to consciously decide when an action is executed.

Grouping: Structure for Complex Forms

Forms with many input fields should be divided into logical sections. This structure helps all users orient themselves and maintain an overview. This is particularly important for radio buttons and checkboxes. Without clear grouping, screen reader users cannot recognize which options belong to which question.

For example, the question "How would you like to be contacted?" should be clearly connected to the options "Email," "Phone," and "Mail." This connection is made through HTML structures implemented during development. However, deciding which fields are grouped and how that grouping is labeled is a conceptual task.

Multi-page forms should include a progress indicator. This shows users which page they are on and how many steps remain. The progress indicator should also be accessible to screen readers so that all users can understand their progress in the process.

Input Assistance: Facilitation Instead of Barriers

Input fields should clearly indicate the expected input type. On mobile devices, the appropriate keyboard is then displayed automatically. This facilitates input and reduces errors. Autocomplete can also make filling out forms easier for users. Browsers can automatically insert saved data if the fields are appropriately marked.

Help text should be placed before or directly next to the input field. If a specific format is expected, this should be explained in advance. For example: "Please enter your phone number in the format +49 123 456789." This help text should be visible to all users and accessible to screen readers.

Redundant inputs should be avoided. Information that has already been entered in the same session should not be requested again. Exceptions apply when re-entry is necessary for security reasons, such as password confirmation.

Keyboard Operation: Complete and Without Detours

All form elements must be fully operable via keyboard. This includes input fields, buttons, dropdowns, date pickers, and all interactive elements. Basic keyboard control should be intuitive:

• Tab key: moves focus from one element to the next
• Enter key: submits forms or triggers actions
• Space bar: activates checkboxes and radio buttons
• Arrow keys: navigate in dropdown menus and date pickers

Keyboard traps must be avoided. A keyboard trap occurs when focus is trapped in an element and cannot be moved out. This can happen when modal dialogs or overlays are not correctly implemented. Users should always have the option to leave an element and return to their previous position.

Single-character keyboard shortcuts should be deactivatable or customizable. Otherwise, users who rely on voice input may accidentally trigger functions.

Error Prevention: Check, Confirm, Correct

For forms with legal or financial consequences, users should be able to review entries before submitting. There are several options for this:

• Entries can be reversed
• Entries are checked before submission
• A confirmation page allows correction

A summary before submission helps prevent errors. It should clearly display all entered data and offer the option to edit individual fields. This reduces frustration and increases the likelihood that users will successfully complete the form.

Automatic corrections should be transparent. Users should have the option to review corrections and reverse them if necessary. This is particularly important for names, addresses, or other personal data that should not be automatically corrected.

Authentication: Accessible and Secure

Authentication processes should not rely on cognitive function tests. CAPTCHAs that require recognizing distorted letters or identifying objects in images are not accessible to many people. Image-based CAPTCHAs are not usable for blind users. An audio alternative should be provided. Modern methods that work without user interaction are even better.

Password fields should offer the option to display the password. A "Show password" button reduces input errors and facilitates operation. This is particularly helpful for people with motor impairments or cognitive disabilities, but also for everyone else who is unsure during input.

Standards and Norms

The design of accessible forms is based on the Web Content Accessibility Guidelines and the Accessible Information Technology Regulation. These standards define specific requirements that must be considered during implementation.

WCAG 2.2 requires, among other things, that labels be provided when content requires user input, that errors be automatically detected and described, and that all functions be available via keyboard. BITV 2.0 specifies these requirements for the German legal framework and requires, for example, that labels of form elements be programmatically determinable.

Compliance with these standards has been mandatory for many companies since June 28, 2025, under the BFSG. However, the standards not only provide legal guidance. They also help to justify design decisions in a comprehensible way and set priorities.

UseTree and Accessible Forms

UseTree supports companies in designing accessible digital products. We test forms for compliance with WCAG 2.2 and BITV 2.0, develop concepts for accessible input processes, and accompany teams during implementation. We combine UX research with accessibility standards and ensure that forms are not only compliant but also usable.

Conclusion

Accessible forms improve the user experience for everyone. Clear labels, specific error messages, visible focus management, logical grouping, and thoughtful input assistance make forms accessible. Compliance with WCAG 2.2 and BITV 2.0 has been mandatory for many companies since June 28, 2025, under the BFSG. Those who consider accessibility early in the UX process create a better foundation for informed design decisions and can reduce the risk of extensive rework.

‍