Making enquiry-form errors easier to read

The task and barrier

A visitor needs to correct missing or invalid information before sending an enquiry. On the version of our contact page captured on 7 October 2026, the red field labels and error messages were too faint against the white form background. This could make the instructions harder to read for someone with low vision.

Finding AAT-001: insufficient text contrast. We assigned medium priority: the instructions remained available, but their presentation made correcting the form harder.

Evidence and requirement

The earlier capture contained four invalid field labels and four error messages for Name, Email, Subject and Message. These were eight occurrences of one finding. This normal-sized text required at least 4.5:1 contrast under WCAG 2.2 success criterion 1.4.3 Contrast Minimum.

How the issue was reproduced

1. Open the contact page and leave the required fields empty.
2. Activate the submission button to display the validation messages.
3. Identify the visible error labels and messages, and measure their computed text and background colours.
4. Calculate the contrast ratio and compare it with the requirement for the text size.

The earlier test blocked outgoing submissions. The retest used an isolated preview with a test-only enquiry form. No real enquiry was sent.

Recommended correction

Use a darker colour for error messages and invalid labels, checking it against the background where the text actually appears. Check the error-summary links too. Keep clear error wording so the visitor can understand what needs correcting.

What the retest established

On 30 October, empty-form and invalid training-enquiry states were tested at 1440 × 1000 and 390 × 844 CSS pixels. The red error text, invalid labels and error-summary links measured 8.37:1 against white in these four states. The error-summary heading and other measured labels had higher contrast.

Retest result: the measured text meets the contrast requirement in the tested states.

Why manual screen-reader testing also matters

A visible error is only part of the story. A sighted visitor may notice a red outline, while a screen-reader user needs a clear error message associated with the field and a usable way to reach and correct it.

Manual testing checks what is spoken, where keyboard focus goes and whether the person can recover from an error. Founder Aj Ahmed's everyday JAWS use informs those checks. Read more about our screen-reader testing experience.

Scope of this extract

This extract covers one type of barrier. It compares a historical live-site capture with an identified development preview. The form changed between those dates, so the retest covers the current fields rather than an identical set of eight text occurrences.

Testing used Chromium on Windows, browser interaction and computed-style measurements. The narrow check used a resized desktop browser. Screen-reader speech, other browsers, dark or forced-colour modes, physical phones and the complete enquiry process were outside this contrast retest. The result does not certify the whole website.

Get findings your team can act on

We agree the pages, user journeys and testing environments before an audit. You receive a prioritised written report with step-by-step guidance. A call is available on request, and follow-up and retesting are agreed in your quote.