Every other problem with a form announces itself. A broken integration produces an angry email. A confusing question produces a phone call. A slow page produces complaints.
Accessibility failures produce silence. Somebody who cannot use your form does not write to tell you that your date picker is unreachable by keyboard. They go somewhere else, and the entire event is invisible from your side, because the only trace is a session that did not become a submission and you have thousands of those.
That silence is why accessibility gets treated as a compliance chore rather than a business problem. Nothing in your dashboard will ever point at it, so you have to go looking, and looking turns out to be much easier than most people assume.
How many people are we talking about
The commonly cited figure is that around one in five people has a disability, which is true and not very useful, because most of those people have no difficulty with a well-built form.
The number that matters is smaller and still substantial. People who navigate by keyboard rather than mouse, people using a screen reader, people who need large text or high contrast, people with tremor or limited fine motor control, and people with reading or attention differences that a badly structured form makes considerably worse.
Add to that the much larger group who are situationally affected: bright sunlight, a cracked screen, a bad connection, one hand holding a child, or simply being tired. Almost every fix in this article helps that group too, which is why accessibility work tends to raise completion rates across the board rather than serving a minority.
The keyboard test
The single most productive ten minutes available is to open your form and complete it without touching the mouse or trackpad. Tab moves forward, shift and tab move back, space and enter activate things.
Watch for three failures. Whether you can see where you are at every step, which requires a visible focus outline that somebody has not removed for looking untidy. Whether the order makes sense, which it will not if the layout was built in a different order from the markup. And whether anything traps you, which custom dropdowns and date pickers do more often than any other component.
If you cannot complete the form this way, neither can a meaningful number of people, and you have found the problem without any specialist tooling at all.
If you cannot finish your own form without a mouse, a real share of your visitors cannot finish it either.
Placeholder text is not a label
The most common accessibility failure on modern forms is also the most fashionable design decision: using the grey text inside a field instead of a label above it.
It fails in several ways at once. It disappears the moment somebody starts typing, so anybody who is interrupted loses the question. Its contrast is usually poor enough to be hard to read in sunlight. Screen readers treat it inconsistently. And it makes the form impossible to review before submitting, because every completed field now looks unlabelled.
The fix is to put the label above the field and leave it there. This is not a compromise for accessibility's sake. Forms with persistent labels perform better for everybody, and they always have.
Errors that nobody can find
The second most common failure is error handling, and it is the one that causes the most abandonment, because it happens at the moment somebody has already done all the work.
Red borders alone are invisible to a screen reader and hard to see for the significant number of people with colour vision deficiency. An error summary at the top of a long form is useless if it does not say which field. And the classic pattern of clearing the form on a validation failure converts a small annoyance into a total loss.
Good error handling names the field, sits next to it, says what would be acceptable rather than merely that the input is wrong, and keeps everything the person already typed. Phone number must include an area code beats invalid input by a distance.
Time limits and auto-advance
Forms that move on automatically when an answer is selected feel slick in a demo and are genuinely hostile to several groups. Anybody who selects the wrong option by accident, anybody with a tremor, anybody using a screen reader that has not finished reading the options, and anybody who wanted to check their answer before continuing.
Timed sessions are worse. If a form expires after ten minutes, say so at the start and offer a way to extend it. People do get interrupted, and losing a half-completed application because a child came into the room is the kind of experience that ends a relationship.
If you must auto-advance, make it a preference rather than a default, and never combine it with a form people cannot go back through.
Contrast, size and the reduced motion setting
Three quick checks that need no expertise. Text against its background needs enough contrast, and light grey on white fails constantly in modern designs, particularly for help text and placeholder content, which is exactly the text people need most.
Tap targets should be around forty-four pixels square. Smaller than that and anybody on a moving train, anybody with larger fingers, and anybody with limited dexterity will miss, and missing on a radio button often means selecting the wrong answer rather than selecting nothing.
And if your form animates between questions, respect the reduced motion setting. Somebody who has asked their operating system to stop animations has usually done so because motion makes them ill, and a form that slides every question in regardless is not a style choice from their side.
Group the questions that belong together
A set of radio buttons is not five separate questions, but that is what a screen reader will announce unless the group is marked up as one. The person hears five options with no idea what was being asked, which makes the question unanswerable without guessing.
The same applies to checkbox groups, address blocks, and anything where several fields make one logical unit. Most form builders handle this correctly if you use the question types they provide and incorrectly if you assemble something out of individual fields.
That is a good general rule. Use the built-in question type wherever one exists, because somebody has already thought about the markup, and hand-assembled equivalents almost never get it right.
The specific things to fix, in order
If you do nothing else, these five cover most of the real-world damage, and none of them requires a specialist.
- Visible labels above every field, never placeholder-only.
- A focus outline you can see, on every interactive element.
- Errors that name the field, sit beside it, and never clear the form.
- Tap targets around forty-four pixels, with enough contrast on all text including help text.
- No auto-advance, no time limits, and reduced motion respected.
Testing without hiring anyone
You do not need an audit to make substantial progress. Beyond the keyboard test, two more cost nothing.
Turn on the screen reader already installed on your machine, close your eyes, and try to complete the form. This is uncomfortable the first time and extremely informative. You do not need to become proficient; you need to hear what your form sounds like, and thirty seconds of that usually identifies the worst problem.
Then open the form on a phone in bright daylight, at arm's length, and see what you can read. Between them, these two tests catch a large majority of what a paid audit would find, and they take a quarter of an hour.
The legal position, briefly
In the UK, the Equality Act requires reasonable adjustments for disabled people, and a public-facing form is a service. In the EU, the Accessibility Act extends similar obligations to a broad range of private services. In the US, the ADA has been applied to websites repeatedly.
The practical reading for a small business is that the obligation exists, is proportionate to your size, and is very unlikely to be tested in court over an enquiry form. Compliance is not usually the reason to do this work.
The reason to do it is that the fixes above are cheap, they take an afternoon, and they raise completion for everybody. The legal position is a floor rather than a motivation, and treating it as the motivation tends to produce the minimum rather than the useful.
There is a procurement angle worth knowing too. Larger organisations and anything public sector increasingly ask about accessibility before they buy, and being able to answer the question honestly has won small suppliers work that had nothing to do with disability at all.
Autocomplete and input types
Two attributes do a disproportionate amount of work and cost nothing. Setting the correct input type means a phone field brings up a number pad rather than a full keyboard, and an email field brings up one with an at sign. On a small screen that is the difference between four taps and twelve.
Autocomplete attributes let the browser or password manager fill a field in, which helps everybody and helps enormously anybody for whom typing is slow or painful. A form where somebody can fill in six fields with one tap is a genuinely different experience from one where every character has to be typed.
Both are usually handled correctly by a form builder as long as you pick the right question type. A field labelled phone but built as a generic text input will get neither, which is one more reason to use the specific type rather than a text box with a label.
Long option lists and the scroll trap
A question with twenty options is hard for everybody and considerably harder on a phone, where the list can push the continue button several screens away and there is no visual cue that it exists.
The usual fixes are worth knowing. Group options under headings if they fall into natural sets. Put the common ones first rather than alphabetically, because alphabetical is a filing convention rather than a usability decision. Or replace the list with a two-step question, where the first narrows and the second selects, which sounds like more work and is measurably faster.
Where a long list is genuinely unavoidable, such as a country selector, make it searchable and make sure the search works by typing rather than only by scrolling. A person using a screen reader should not have to listen to a hundred and ninety options.
Start with the keyboard
If this feels like a long list, do one thing this week. Open your main form and try to complete it using only the keyboard.
Most people find at least one blocker within two minutes, and it is almost always either a focus outline somebody removed for looking untidy or a custom dropdown that swallows the tab key and will not give it back. Fixing that single thing will help more people than anything else on the page, and it will take less time than reading this article did.
Then come back for the labels and the errors. This is not a project that has to be finished. It is a set of small corrections, each of which pays for itself immediately.
Keep a short note of what you fixed. The next form you build should start from that list rather than rediscovering the same five problems, and a team that writes them down stops shipping them within about two forms.