A Practical Accessibility Checklist for Online Forms

Short answer: the four checks that catch most form accessibility failures are visible labels on every field, keyboard navigation with a visible focus outline, error messages tied to their field and not signalled by colour alone, and adequate contrast. All four are quick, and all four also lift completion rates for people with no disability at all.

Accessibility gets discussed either as a compliance threat or as a specification document, and neither framing gets much fixed. The practical version is narrower than both: there is a short list of failures that account for most of the real-world exclusion on forms, and they are the same failures that make forms annoying for everybody.

That overlap is the argument. You are not choosing between an accessible form and a high-converting one.

The four that matter most

Visible labels, not placeholder text. Placeholder-only fields are the single most common failure. The text vanishes as soon as typing starts, so anyone who loses their place has to clear the field to remember what it wanted. Screen readers frequently do not announce it. Its contrast is nearly always too low by design. A persistent label above the field solves all three, and costs you a few pixels of vertical space.

Keyboard operability with a visible focus state. Some people never use a mouse — motor impairments, screen reader users, and a surprising number of fast typists. Tab must move through fields in the order they appear, the currently focused field must be visibly outlined, and Enter must submit. The common failure is a custom-styled control with the focus outline removed for looks, which leaves keyboard users navigating an invisible cursor.

Errors bound to fields, and never colour alone. A red border with no message tells a person that something is wrong, not what. It tells someone with a colour vision deficiency nothing at all. Every error needs text, next to the field, saying what is expected — and focus should move to the first error when a submit fails so nobody has to hunt for it.

Contrast that survives a real screen. Light grey text on white looks refined on a designer's calibrated monitor and disappears on a phone outdoors. This affects far more people than any other item on the list, most of them not disabled in any formal sense — just older, or in sunlight.

The wider checklist

Area	What to check	Why it fails commercially
Labels	Every field has a persistent visible label	People forget what a field wanted and abandon
Focus	Visible outline on the focused element	Keyboard users cannot tell where they are
Errors	Text beside the field, not colour alone	Failed submits become abandoned submits
Contrast	Text and borders readable on a phone in daylight	Fields look empty or disabled
Touch targets	Buttons and checkboxes comfortably tappable	Mis-taps on mobile, especially on radio groups
Field types	Correct input type so phones show the right keyboard	Typing a phone number on a letter keyboard
Required fields	Marked in text, not only with a coloured asterisk	People submit and get bounced back
Time limits	No session timeout that silently discards entries	Long forms lost entirely, once
Autofill	Standard field naming so browsers can fill	Extra friction on every contact detail
Language	Page language declared, matching the content	Screen readers pronounce the wrong language

The autofill row is worth dwelling on, because it is the one people miss. Browsers can fill name, email, phone and address instantly if the fields are named conventionally. Custom field naming breaks that, and every broken autofill is manual typing on a phone — friction for everyone and a genuine barrier for some.

Length is an accessibility issue

This is the least intuitive item and often the most impactful.

A long form demands sustained attention and working memory. For someone with a cognitive disability, ADHD, chronic fatigue or simply a bad day, a twenty-field form is not a minor irritation — it is the reason the enquiry does not happen. Every unnecessary required field excludes people, and it excludes them invisibly, because a person who gives up leaves no trace.

Which makes the ordinary conversion advice and the accessibility advice identical: cut fields you do not need, make optional anything you would still act without, and break what remains into steps. The drop-off evidence for that is in reducing form abandonment, and the mechanics of splitting a form well are in smart multi-step forms that adapt to answers.

Conversational formats sit in the same territory and cut both ways — shorter individual questions reduce load, but a chat interface that only announces new messages visually can be worse than a plain form for a screen reader user, which is one more thing to weigh alongside the trade-offs in chatbots versus forms for lead capture.

Multi-step forms are generally the more accessible pattern when built properly, with three conditions: progress is stated in text rather than implied by a graphic, focus moves to the top of each new step so screen reader users are not left at the bottom of the previous one, and going back never clears what was entered.

Language and reading level

Two things get conflated under "language" and both matter.

The technical one: the page must declare its language, and if you serve a form in more than one language, each version must declare its own. Screen readers use that to choose pronunciation, and a Spanish form declared as English is close to unusable aloud. If you run bilingual intake, this is a setup detail worth verifying rather than assuming — running forms in Spanish and English covers the wider question of doing that properly rather than machine-translating labels.

The human one: reading level. Industry jargon in a field label excludes non-specialists, non-native speakers and anyone reading quickly. "What is the make, model and year of your vehicle?" beats "Vehicle identification particulars". This is free to fix and improves data quality at the same time, because people answer clear questions more accurately.

Testing without buying anything

Three tests, fifteen minutes, no tools required.

Put the mouse away. Complete your own form using only Tab, arrow keys and Enter. You will find missing focus states and unreachable controls immediately.

Zoom to 200 percent. Browser zoom, not a device setting. Text should reflow, nothing should be cut off, and no control should end up off-screen. Fixed-width layouts fail this loudly.

Read it on a phone outdoors. The contrast test that matters. Anything you squint at is failing for a lot of people indoors too.

Automated checkers are worth running afterwards — they catch missing labels and contrast ratios reliably — but they cannot judge whether your labels make sense or whether the tab order is logical, which is where the real problems live. Automated tools find a minority of issues; the three manual tests above find the ones that stop people.

What you can honestly claim

Be careful with the word "compliant". Conformance to an accessibility standard is assessed against a specific version and level of the guidelines, generally through an audit, and asserting it without one is a claim you may have to defend. A form built to the practices here will be substantially more usable than most, and the accurate statement is that you have followed recognised guidance.

If a contract, a public-sector procurement or a regulator in your jurisdiction requires a formal position, that needs a qualified assessment rather than a checklist. General information here, not legal advice.

Where the platform helps and where it does not

A form builder can give you a decent starting point — sensible field types, real labels, working keyboard behaviour, error text attached to fields. Generated forms usually get the mechanics right because they are pattern-based; BotForms attaches field types and validation automatically when it builds a form from a description, on every plan.

What no platform can do is decide which fields you genuinely need, write your labels in plain language, or choose a contrast level for your brand styling. Those are the decisions that determine whether the form is usable, and they stay with you.

Getting started

Take your highest-traffic form and do the three manual tests. Fix labels first, focus states second, error handling third. Then look at the field count and ask which ones you would still act without.

That sequence typically takes an afternoon and improves both accessibility and completion rate, because on forms those are largely the same work. See features for the builder, pricing for plans from $29/month, or start a 30-day trial.