Accessible Forms: Labels, Errors and the New Authentication Rules

Most accessibility failures cost you goodwill. Form failures cost you revenue, directly and immediately, because a form is the point at which someone is actively trying to buy something, book something, apply for something or contact you. A person who cannot complete your checkout does not file a complaint. They leave.

WebAIM's February 2026 analysis of a million home pages found missing form input labels on 51.0% of them — and unlike most failure types, that number has been getting *worse*, up from 48.2% the previous year. Forms have become more complex and more custom-built, and the accessibility fundamentals have not kept pace.

The label is not the placeholder

The single most common form accessibility failure is using placeholder text instead of a label. It looks clean: an empty box with grey text inside saying "Email address", no separate label taking up vertical space.

It fails on four counts. The placeholder disappears as soon as the user types, so anyone who is interrupted, distracted or reviewing their answers has lost the field's identity. It is typically low contrast by design — grey on white, usually failing 1.4.3. It is not reliably announced as the field's accessible name across screen readers and browsers. And it actively harms people with cognitive and memory difficulties, who most need the label to remain visible.

A real label is a <label> element associated with its input, so that clicking the label focuses the field and a screen reader announces the correct name. Placeholders are for supplementary hints — a format example, say — not for identification. Use both if you want, but never the placeholder alone.

Where a visible label genuinely will not fit, such as a search field with a magnifying-glass button, the field still needs an accessible name via aria-label or a visually hidden label. Invisible to sighted users, present for everyone else.

One related trap: 2.5.3 Label in Name (Level A) requires that where a control has a visible text label, its accessible name contains that visible text. If your button says "Submit application" but its aria-label says "Send", a voice control user saying "click submit application" will fail to activate it. Voice control matches what people can see.

Error messages that work

Getting an error wrong is worse than getting a label wrong, because the user has already invested effort and is now stuck.

Identify errors in text (3.3.1, Level A). A red border alone is not an error message. Colour cannot be the only means of conveying information, and a screen reader announces nothing at all for a border colour change. Say what is wrong in words.

Say what to do about it (3.3.3, Level AA). "Invalid input" is technically an error message and practically useless. "Enter a date in the format DD/MM/YYYY" tells the person how to succeed.

Announce it. If your form validates without a page reload, the error must be programmatically announced, or a screen reader user gets no feedback at all — they press submit and, as far as they can tell, nothing happens. A live region, or moving focus to the error summary, both work. Silence is the failure mode.

Associate it with its field. Use aria-describedby to link the message to the input so it is read when the user reaches the field, not just when they hit the summary.

Put a summary at the top for long forms. List the errors, link each to its field, and move focus there on submit.

The WCAG 2.2 additions that hit forms hardest

Two of the nine new criteria in WCAG 2.2 land squarely on forms.

3.3.7 Redundant Entry (Level A) says information the user already entered in the same process must not be requested again from memory — auto-populate it, or let them select it. The canonical failure is a checkout that collects a delivery address and then asks for the billing address with no "same as delivery" checkbox. Exceptions exist for re-entry that is essential (confirming a new password), required for security, or where the earlier answer is no longer valid.

3.3.8 Accessible Authentication (Minimum), Level AA is the bigger one. No step in an authentication process may require a cognitive function test — remembering, transcribing or manipulating information — unless you also provide an alternative method, a mechanism to help, a test that is merely object recognition, or one based on non-text content the user supplied themselves.

In practice this makes two very common patterns non-conforming.

The first is blocking paste on password fields. It is done in the belief that it improves security; it does the opposite. It breaks password managers, which forces people to use passwords they can memorise, which means shorter and reused passwords. It also forces manual transcription, which is precisely the cognitive function test the criterion prohibits. Remove the paste block.

The second is puzzle CAPTCHAs — distorted text, "select all the traffic lights", arithmetic. These are cognitive function tests by definition. And the user data on them is damning: in WebAIM's Screen Reader User Survey #10, published in 2024, CAPTCHA was ranked the single most problematic item on the web, above every other barrier tested. If you need bot protection, the accessible options are risk-based or invisible challenges that do not require the user to solve anything, or providing a genuine alternative route to the same outcome.

Structure, grouping and expectations

Group related fields. Radio buttons and checkbox sets need a <fieldset> with a <legend>, so the question is announced along with the option. Without it, a screen reader user hears "Yes, radio button" with no idea what they are agreeing to.

Mark required fields properly. An asterisk with a legend somewhere is a convention, not an implementation. Use the required attribute so the state is exposed programmatically, and keep the visual convention as well.

Help autofill work. WCAG 2.1's 1.3.5 Identify Input Purpose (Level AA) requires that fields collecting information about the user identify their purpose programmatically — which in practice means correct autocomplete attributes. This is not just a convenience feature: it lets browsers and assistive technologies fill fields for people for whom typing is slow or error-prone, and it lets some users see familiar icons in place of text labels.

Do not change context without warning (3.2.2, Level A). A <select> that navigates the moment you arrow onto an option is a trap for keyboard users, who cannot reach the option they want without triggering the wrong ones on the way. Require an explicit action.

Give people enough time. Sessions that expire silently mid-form are a real accessibility barrier for anyone who works more slowly, and 2.2.1 Timing Adjustable requires a way to turn off, adjust or extend limits in most cases.

Test the whole process, not the page

This is the mistake that undoes otherwise careful work. WCAG conformance is claimed for complete processes: if a page is a step in a multi-step flow, every page in that flow must conform or none of them can be claimed. Your product page can be immaculate and your conformance claim still invalid because the third step of checkout has an unlabelled field.

So test the journey end to end, with the keyboard, from landing to confirmation — including the error states, which are the parts nobody tests because they require deliberately doing the wrong thing. Submit the form empty. Enter an invalid email. Let the payment fail. Those paths are where accessible forms are actually won and lost.

Automated tools will find your missing labels reliably; that failure type is one of the things machines are genuinely good at detecting. They will not tell you whether your error message is comprehensible, whether focus lands in the right place after a failed submit, or whether a person can finish. For that, see automated versus manual testing.

*The 51.0% figure and the 48.2% prior-year comparison are both from the WebAIM Million 2026 report (analysis run February 2026, published March 2026), based on automated analysis; WebAIM notes automated tools cannot detect all conformance failures. Success criteria are from the W3C's published WCAG 2.2 Recommendation. The CAPTCHA ranking is from the WebAIM Screen Reader User Survey #10, conducted December 2023 to January 2024 with 1,539 responses.*