Form Audit: How to Make the Journey from Field to Confirmation Accessible

A contact form may look simple, but it brings together many of the most common accessibility barriers in one place. Users need to understand what is being requested, navigate between fields, detect errors and know whether their submission was successful. It must work without a mouse, with magnified content and with a screen reader.

That is why forms are a good place to start when a business wants to make accessibility concrete. Instead of checking WCAG as a long list of individual requirements, you can follow one real task from start to finish. This form audit is suitable for contact forms, orders, registrations, applications and other important enquiries.

Start with the task, not just the components

An accessible text field is of little use if users cannot find the form, do not understand its purpose or lose information after an error. The audit should therefore cover the entire process:

1. Find the right form.
2. Understand what needs to be filled in.
3. Complete the fields using the preferred method of interaction.
4. Detect and correct errors.
5. Submit the form.
6. Receive a clear confirmation.

Choose the form that is most important to the organisation. It could be a request to book a site survey, registration for a course or a request for a quote. Note which task you are testing, what needs to be completed and what the user should experience when the task is complete.

Remove fields that have no clear purpose

The easiest field to make accessible is one you do not need. Every additional question increases cognitive load and creates another opportunity for error.

Ask the form owner to explain why each field exists. Do you need both first name and surname, or is name enough? Does the phone number need to be mandatory when the response can be sent by email? Is an organisation number necessary before an initial conversation?

Clearly distinguish between mandatory and optional fields. Do not rely solely on an asterisk or colour. For example, write Phone number, optional in the label. If almost all fields are mandatory, you can explain this before the form and mark the exceptions as optional.

Give every field a visible and precise label

Placeholder text inside a field is not a good replacement for a label. The text disappears when the user starts typing, may have weak contrast and is not always conveyed predictably by assistive technologies.

Use a visible label that is technically associated with the correct field. The label should describe the information, not merely show an example. Email address is a label. navn@bedrift.no is an example that may be included as well.

Instructions should be placed before the user needs them. If a password must meet specific requirements, the requirements must be visible before submission. If the date must be entered in a particular format, provide the format next to the field. Also ensure that the instruction is technically associated with the field, so it is read aloud by screen readers.

Test the entire form without a mouse

The keyboard test is about more than being able to enter a text field. Users must be able to reach, understand and operate all interactive elements.

Start on the page and use Tab to move forward and Shift and Tab to move back. Use Enter and Space where relevant. Test drop-down lists, checkboxes, radio buttons, date pickers, upload fields and the submit button.

Check the following as you go:

• The focus order follows the visual and logical order.
• It is easy to see which element has keyboard focus.
• Focus does not disappear behind a fixed top menu or a pop-up window.
• All functions can be operated without precise mouse movements.
• The user is not trapped in a field, menu or dialog box.
• Enter does not submit the form unexpectedly while the user is selecting an option.

A clear focus indicator should have good contrast against both the component and the surrounding background. Do not remove the browser's default indicator without replacing it with something at least as visible.

Check contrast in all states

The contrast test must cover more than body text. A form has several states that are often overlooked: default, focus, filled, disabled, error and confirmed.

Check labels, help text, button text, borders that show where the field is, focus indicators and error messages. Light grey text on a white background is particularly common in help text and placeholders.

Colour should not be the only way to convey meaning either. A red border around a field does not necessarily explain what is wrong and may be difficult to perceive. Combine visual highlighting with text that describes the error. Icons can support the message, but should not stand alone.

Turn the error message into guidance

A good error message answers three questions: What is wrong, where is the error, and how can it be fixed? Invalid value is not very useful. Enter the email address with a name, at sign and domain gives the user a way forward.

Validating while the user is typing can be disruptive if the field is marked as erroneous before it has been completed. Wait until the user has left the field, or until the form is submitted, depending on the task. Do not remove information that has already been entered correctly when an error occurs.

If submission reveals multiple errors, an overview should be displayed at the top of the form. The overview should explain that the form was not submitted, list the errors and help the user find the relevant fields. Each field must still have its own message.

Moving keyboard focus can be appropriate when submission fails, but it must be done deliberately. Move focus to the error summary or the first field with an error, so that keyboard and screen reader users notice that the situation has changed.

Test with a screen reader without looking at the screen

A screen reader test reveals whether the visual structure also exists in the code. It is not enough for the label to appear next to the field. The screen reader must be able to convey the field's name, type, status, instructions and any errors.

Go through the form with the screen turned off or covered. Listen for whether each field makes sense without visual context. A field that is only announced as edit field, required, is probably missing an accessible name.

In particular, check that:

• Headings describe the sections of the form.
• Groups of options have a shared question.
• Required status is conveyed.
• Help text and error messages are read together with the correct field.
• Changes after submission are announced.
• The confirmation explains what has been registered and what happens next.

Do not try to repair inadequate HTML with numerous technical attributes. Start with correct standard elements and the right structure. Custom-built fields, dropdown lists and date pickers require more development and more thorough testing than the browser's standard form controls.

Try magnification and a narrow view

Users may magnify content significantly or increase the text size without changing the rest of the interface. Labels, fields and buttons must still be readable and usable.

Test the form in a narrow view and with significant magnification. Look for text that is cut off, fields that fall outside the screen, buttons that cover content, and the need for horizontal scrolling. Two columns may work on a large screen, but should often become one column when space is limited.

Also make sure that zoom does not hide error messages behind a fixed header or consent banner. The form must accommodate larger text without information or functionality disappearing.

End with a confirmation that actually confirms

A form has not been fully tested when the submit button can be activated. The user needs a clear answer as to whether the submission was successful.

The confirmation should be visible, understandable and accessible to screen readers. State what has been received, what further processing is expected and what the user should do if it is urgent. Avoid a brief message that only says Thank you.

For transactions with greater consequences, users should be able to review the information before final submission. This is especially important for purchases, agreements, applications and other actions that may be difficult to reverse.

Make the findings possible to prioritize

Record each finding with a screenshot, steps to reproduce the problem, affected users and the expected solution. Prioritize obstacles that prevent the task from being completed: submit buttons that cannot be reached, fields without names, errors that are not conveyed, or content that disappears when magnified.

You can then address problems that create unnecessary friction, such as unclear labels, weak contrast and imprecise instructions. Assign each finding to a responsible role. Some issues must be resolved in the design, some in the text, and some in the code or form solution.

Repeat the entire task after corrections. A technical change can affect the focus order, display or screen reader experience elsewhere. Include the most important checks in the acceptance criteria for new forms, so the same errors are not introduced again.

A form review provides a defined and measurable starting point for WCAG work. At the same time, it tests what matters most: whether people with different needs can actually complete an important request independently.