Make the Form Possible to Complete: Universal Design from Fields to Error Messages

Category: Accessibility

A form can look simple and still be difficult to use. A missing field label, unclear focus indicator or error message shown only in red can prevent users from submitting an enquiry, registering or completing a purchase.

That is why universal design of forms should be treated as one continuous user journey. WCAG provides the requirements, but the practical task is to ensure that users understand what to fill in, can move through the fields, discover errors and correct them.

Start with the task, not the components

Before assessing contrast, code and screen reader behaviour, you should ask what the form actually requires of the user. Long and unclear forms create problems for everyone, but especially for people who use assistive technology or have impaired vision, motor challenges or difficulty concentrating.

Remove fields that are not necessary to complete the task. If the business does not need a phone number to respond, the field should normally not be mandatory. If a form has multiple steps, users must understand how far they have progressed and what remains.

A good initial review consists of three questions:

• What information is necessary to process the enquiry?
• Is the order logical from the user's perspective?
• Can instructions and technical terms be written more simply?

This is inclusive design in practice: Reduce the burden before attempting to explain the complexity.

Give every field a clear and persistent label

All form fields need a visible label that is technically associated with the correct field. Placeholder text inside the field is not a good substitute. It usually disappears when the user starts typing, may have low contrast and is not always conveyed usefully by assistive technology.

The field label should be specific. For example, use “Email address” instead of “Contact information”. If a particular format is required, a short instruction can be placed next to the field. This instruction must also be accessible to screen readers.

Required fields should be marked with text, not just a star or colour. Wording such as “Required” is clearer than a visual code the user must first learn. If most fields are required, it may be clearer to mark the optional fields instead.

Use standard components when appropriate

Common HTML fields, checkboxes, radio buttons and buttons have built-in functionality that browsers and assistive technology recognise. Custom-built components may be necessary, but require more work to support names, roles, states, focus and keyboard operation.

A visually elegant dropdown is not successful if users cannot open it with the keyboard or understand the selected option with a screen reader. Therefore, choose standard controls unless a custom solution provides a genuine user benefit and is thoroughly tested.

Ensure that the entire form works with a keyboard

Users must be able to reach and operate all fields, choices, help text and buttons without a mouse. The Tab key is normally used to move between interactive elements, while other keys are used to make selections in some components.

Test the order from the beginning of the form. Focus should follow the visual and logical order. Jumping to a button at the bottom of the page or back to a previous field can make the form difficult to understand.

The active element must have a clear focus indicator. A subtle colour change is often insufficient. Use an indicator that clearly stands out from both the component and the background, and that works across the page's colours.

Also make sure that fixed top menus, consent boxes or other layers do not cover the field that has focus. Technically, the field may be selected even though the user cannot see it.

Use contrast for more than readable text

WCAG sets requirements for contrast, but checks should not be limited to body text. In a form, you must also assess field borders, icons, focus indicators, help text, button text and error information.

A field with a very light border can be difficult to perceive against a white background. A disabled button can become so faint that users cannot see it, while there is no explanation of what needs to be done to enable it.

Colour must not be the only means of conveying information. An erroneous field may have a red border, but it also needs a symbol or textual message. The same applies to marking required fields, selected options and status messages.

Create error messages that help users move forward

“Invalid value” describes the system's reaction, not the user's solution. A useful error message explains which field has a problem, what is wrong and how it can be corrected.

For example, “Enter the email address with a name, @ symbol and domain” is more action-oriented than “Invalid email”. At the same time, validation should accept valid variations and not require a narrower format than necessary.

When submission fails, the form should:

1. Show a clear summary of the errors near the beginning.
2. Mark each problem at the relevant field.
3. Technically associate the error message with the field.
4. Preserve information that has already been entered, where appropriate.
5. Move or direct attention so that the user notices the error.

Avoid removing the entire form and replacing it with a generic message. For a screen reader user, a visually prominent message may go unnoticed if the change is not conveyed technically.

Test with a screen reader without forgetting the structure

A screen reader conveys the page sequentially and builds understanding based on structure, names and states. It is therefore not enough for the text to look correct visually. Field labels, groups, instructions and errors must have clear technical associations.

For example, radio buttons such as “Yes” and “No” need a shared group name, such as “Would you like to be contacted by phone?”. Otherwise, the options may be read aloud without the necessary context.

At a minimum, test that the screen reader announces:

• what the field is called
• what type of control it is
• whether the field is required
• which option is selected
• relevant instructions and error messages
• whether the submission was successful

Screen reader testing should be combined with visual inspection and keyboard testing. One tool will not reveal every barrier.

Make the form robust when zoomed and on small screens

Users must be able to zoom in on content without fields, text or buttons overlapping or disappearing. The form should adapt to a narrow viewport without requiring horizontal scrolling to understand and complete common fields.

Avoid placing field labels and inputs so far apart that their relationship becomes unclear when zoomed. Single-column fields are often easier to follow than dense multi-column layouts. Exceptions may include information that naturally belongs together, but these must also work when space is limited.

Buttons and options must be large enough and sufficiently spaced to be operated precisely. This is particularly important on mobile devices and for people with reduced fine motor skills.

Check the entire process before publication

Do not test only the empty form. Go through the situations users may actually encounter: correct completion, missing required fields, incorrect formats, interruptions and successful submission.

A practical check can be carried out as follows:

1. Complete the form using only the keyboard.
2. Repeat the test with significant zoom.
3. Check the contrast of text, components, focus indicators and error markers.
4. Use a screen reader and listen to each field label, option and status message.
5. Submit with several deliberate errors and assess whether the next steps are clear.
6. Test on mobile using touch and the on-screen keyboard.
7. Check that the confirmation explains what happens next.

Keep the test cases and use them after changes to the design, validation or form solution. This makes accessibility part of ongoing management, rather than a one-off check before launch.

Distribute responsibility across design, development and content

Accessible forms are rarely good if responsibility rests with one person at the end. The designer must define contrast, focus and error styling. The developer must ensure correct structure, keyboard support and communication with assistive technologies. The content owner must write understandable field labels, instructions and error messages.

The person responsible for the business process must also challenge which information the form asks for. A technically accessible form can still be unnecessarily demanding if it contains too many questions or unclear requirements.

The goal is not merely to tick off individual WCAG requirements. The goal is for more people to actually understand the task, complete it and know that the information has been submitted. That is the most useful test of whether the form works inclusively.