Every developer has shipped a form that felt finished. The layout is clean, the labels line up, the demo goes off without a hitch, and the pull request gets approved without much discussion.
Then, three weeks after launch, a QA note lands in the backlog: a screen reader user could not create an account. Not "had trouble." Could not. The submit button never fired for them, the error never announced itself, and they gave up two fields in.
This is not a one-off. Pull almost any production form apart and you will find the same three or four mistakes hiding under an interface that looks and functions perfectly on a mouse and a monitor. They rarely show up in a visual review, and they rarely show up in a quick tab-through either, unless you know exactly what to tab for. That is the trap with accessible forms: the failures are invisible to the exact review process most teams already run.
The Stat: 53.1% of home pages have missing alternative text for images, one of the six most persistent WCAG failure categories, essentially unchanged for seven consecutive years. (Source: WebAIM Million 2026)
Why "Looks Fine" and "Works Fine" Are Different Tests
A visual QA pass checks whether a form reads well, aligns well, and matches the design file. None of that tells you whether a label is actually attached to its input in the DOM, whether an error message is ever spoken aloud, or whether a screen reader user can even reach the submit button in a sane order. Those are structural questions, and structural questions need a structural checklist, not another look at the mockup.
That is what this piece is: a procedural list you can run against a pull request in ten minutes, before it merges, rather than three weeks after a user gets locked out.
The 12-Point Checklist to Run Against Every Form PR
Work through these in order. Most take one line of markup or one attribute to fix, and most are invisible until you specifically check for them.
1. Every Field Gets a Real, Programmatic Label
A placeholder is not a label. The moment a user starts typing, the placeholder disappears, and a screen reader may never have announced it in the first place. Every input needs a <label> with a for attribute that matches the input's id, or the input needs to be nested inside the label. Check the rendered HTML, not just the design, because plenty of component libraries render a visual label that never actually gets wired to its input.
2. Group Related Fields Into Logical Sections
Address fields, payment fields, and contact fields each read as one confusing block to a screen reader user unless they are broken into clearly announced sections. Use headings or role="group" with an accessible name to signal where one logical section ends and the next begins, especially on longer forms.
3. Use Fieldset and Legend for Radio and Checkbox Groups
Whenever a set of radio buttons or checkboxes represents one question, wrap them in a <fieldset> with a <legend> that states the question. Without it, a screen reader announces each option in isolation, with no idea what they collectively belong to.
4. Add Autocomplete Tokens to Standard Fields
Name, email, address, and phone fields should carry the correct autocomplete token (name, email, street-address, tel, and so on). This is not just a convenience feature. It is a documented WCAG success criterion, and it materially helps users with cognitive and motor disabilities who rely on browser autofill rather than retyping information.
5. Identify Input Purpose With the Right Type and Attributes
Pair the autocomplete token with the correct type and inputmode. An email field should be type="email", a numeric field should have inputmode="numeric", and so on. This gives assistive technology, and the user's own keyboard, the right context to work with.
6. Associate Error Messages With Their Field via aria-describedby
When a field fails validation, the error text needs to be programmatically tied to that field with aria-describedby, pointing at the id of the message. Without that link, a sighted user sees red text near the field, and a screen reader user hears nothing extra at all when they land on that input.
7. Decide Where Errors Live: Inline, Summary, or Both
Inline errors next to each field help users fix problems in context. An error summary at the top of the form, announced on submission, helps users understand the full scope of what failed before they start working through it. Longer forms generally benefit from both: a summary that lists every problem, plus inline messages tied to each field with the technique above.
8. Make Focus Order Match Reading Order
Tab through the form yourself, with your eyes closed if you can manage it, and confirm that focus moves in the same order a sighted user would visually scan the page. CSS that reorders fields visually without reordering them in the DOM is one of the most common ways focus order quietly breaks.
9. Announce Required Fields Programmatically
An asterisk next to a label is a visual cue only. Add the required attribute, or aria-required="true", so the requirement is actually announced, not just implied by a symbol a screen reader user cannot see.
10. Support Resize and Zoom Without Breaking Layout
Zoom the form to 200% and confirm nothing overlaps, gets clipped, or forces horizontal scrolling to read a single line of text. Low-vision users who rely on browser zoom are locked out just as thoroughly as screen reader users when a form's layout collapses under magnification.
11. Warn Before Timeout, and Let Users Extend
If a session or form can time out, users need a warning before it happens and a way to extend it. This matters most for anyone who needs more time to read, type, or think through a field, which describes a large share of your users, not an edge case.
12. Confirm Success Where Assistive Tech Can Hear It
After a successful submission, the confirmation needs to be programmatically announced, typically through a live region or a focus shift to a confirmation message. A success message that only appears visually, with no signal to assistive technology, leaves a screen reader user unsure whether anything happened at all.
Running the Checklist Without Slowing Down Your Team
None of these twelve points require a redesign. Most are a single attribute, a single wrapping element, or a single line of markup. The reason they get skipped is not difficulty, it is that nobody wrote them down as an explicit gate. Treat this list the same way you treat a linter rule: run it on every form PR, not just the ones flagged for an accessibility pass. The W3C's forms tutorial and the technique for providing descriptive labels are both worth bookmarking alongside this list, since they go deeper into the exact markup patterns behind several of these points.
How This Fits With the Rest of Your Forms Work
This checklist is deliberately narrow: it is a procedural pass for developers, not a conversion argument and not a single experiment. If you are also thinking about how accessible forms affect signups and completion rates, our piece on accessible forms, labels, errors, and lead capture that actually converts covers that angle directly. And if you are curious how far an AI code generator gets on its own against a list like this one, we asked ChatGPT to build an accessible form and wrote up exactly where it fell short.
Running all twelve points by hand on every PR is a solid habit. Running them automatically, on every deploy, catches what a manual pass misses under deadline pressure. That is exactly what our free scanning tools are built for, and they take a few minutes to point at a staging form.
If you would rather talk through a specific form with a person instead of a checklist, reach out to our team directly at experts@wcag.world, or run a scan yourself at wcag.world/free-tools.