Form error message accessibility: 5 checks

A visitor who misses the error does not see a failed form. They see a button that did nothing, and they assume the site is broken. Error text is often set in a light gray or pale red at a small size, which fails the contrast a reader needs in bright light or on a dim screen. Some toasts appear at the top and vanish after a few seconds. On a phone, the keyboard may cover the message under the field, so the visitor never sees it. Nothing in the page's own look tells the owner the text is hard to read.

• Check the error text color against its background in the developer tools color picker, which shows a contrast ratio.
• Compare the error text size with the label beside it. A smaller message is the first thing a visitor skips.
• Open the form on a phone with the keyboard up, and confirm the message under the field is still visible.
• In the Elements panel, check that the input has aria-invalid and an aria-describedby that points at the message.
• Look at the form in grayscale. The error should still show through its words and icon, not only its red border.

The message can fail in four separate ways, and each needs its own check. Contrast fails when the text is too close in brightness to its background, so it blurs on a bright phone screen or a dim monitor. Size fails when the message is smaller than the label, so it reads as fine print and gets skipped. Placement fails when the message is far from its field or hidden behind the keyboard or a header. Association fails when the code never tells assistive tools which field the message belongs to. Check each one in order, because a bright, large message can still be out of reach.

Open the developer tools, select the error text, and use the color picker, which reports the ratio between the text and the background it sits on. The usual minimum is a ratio of at least 4.5 to 1 for normal-size text, and 3 to 1 for large text. Size is checked the same way: read the computed font size of the message and of the label beside it. A message that looks clear on your own bright monitor can fall short on a phone outdoors, so test it on the device, not only on the screen you designed on.

On a phone the keyboard takes up a large part of the screen, and the browser usually scrolls the focused field above it. A message placed under the field can still sit behind the keyboard, or behind a sticky header, depending on the layout. A toast at the top or bottom is worse, because it times out. A visitor who reads slowly, switches apps or looks away can miss it, and a toast does not wait for them. Keep the message attached to its field and visible while the field is focused, and use a toast only as an extra announcement.

The wrong version is a red span in a toast, with nothing on the input to say it failed. The right version keeps the words beside the field and ties them together. For one ZIP code field, that means a label, then an input marked aria-invalid='true' with aria-describedby='zip-error', then a paragraph with id='zip-error' that says Enter a ZIP code as five digits. Test that version with the keyboard, and then with the keyboard open on a phone, because the message has to survive both.

A restyle, a new brand color or a new toast component can put the error back into small, pale text that a phone cannot read. Rerun the same visitor after each design change, on a phone, and recheck the contrast whenever the palette changes. With paid credits, visitors can reach a form behind a site password, so the same check can run on each preview deploy before release.