Common form accessibility failures and quick fixes

Most broken forms were tested by someone with a mouse, good eyesight and no interruptions. Run the same form with a keyboard, a screen reader or a five-minute pause halfway through, and the cracks show immediately. These are the form accessibility failures that turn up again and again on Indian business websites, along with the fastest reliable fix for each. None of them require a redesign; most are an afternoon of work in a template.

Failure 1: placeholder text used instead of a label

The field says "Email address" in grey inside the box. Start typing and the words vanish. Come back after checking your inbox for an OTP and you are staring at a box of text with no idea what it was asking for.

It fails several ways at once. Placeholder grey is usually too light to meet contrast requirements, screen reader support for placeholders as names is inconsistent, and anyone who is distracted loses the question entirely. Auto-filled values make it worse, since the hint is gone before the person ever reads it.

The fix: add a persistent label above each field and keep the placeholder only for a genuine example, such as a date format. If a designer insists on the compact look, use a floating label that moves above the field rather than disappearing.

Failure 2: icon-only buttons and controls with no name

Search magnifiers, calendar icons, an X to clear a field, an eye to reveal a password, a paperclip for attachments. Each is a button with no text inside it, so a screen reader can only announce "button".

The same problem hits image-only submit buttons and arrow controls in multi-step forms, where a listener has no way to tell "previous" from "next".

The fix: give every control a name. Either include visually hidden text inside the button, or add an aria-label that says what it does: "Search products", "Clear search", "Show password". Name the action, not the picture, and make sure the name matches any visible text so speech-control users can say it aloud.

Failure 3: forms that expire while people are still filling them

Session timeouts and OTP windows cause real abandonment. Someone who types slowly, uses a switch device, or steps away to fetch a GSTIN certificate comes back to a blank form or an "expired" message, often with everything they entered already gone.

Checkouts are the worst offenders, because a cart reservation timer adds pressure on top of the session limit.

The fix: where a limit is genuinely needed, warn the person at least 20 seconds before it expires and offer a simple way to extend it. Preserve entered data across a timeout so nothing has to be retyped. Where the limit exists only out of habit, lengthen it substantially. For OTPs, keep the code valid long enough for a slow SMS and make the resend button easy to find and clearly labelled.

Failure 4: custom dropdowns that ignore the keyboard

A native select element works everywhere: keyboard, screen reader, and the phone's own picker. Replace it with a styled list of divs and all of that has to be rebuilt by hand, which almost never happens completely.

Typical symptoms in a custom dropdown:

• Tab moves past it without ever opening it
• Arrow keys do nothing, so options cannot be reached
• Escape does not close the list
• The chosen value is not announced after selection
• The list opens visually but focus stays behind it, so a screen reader reads the page underneath

The fix: prefer the native select whenever the requirement is "pick one from a list", and style what you can. If a searchable or multi-select control is genuinely needed, use a well-maintained accessible component rather than writing one, and test it with a keyboard before shipping. The same advice applies to autocomplete fields for city or PIN code.

Date pickers deserve their own mention

Calendar widgets are among the least accessible controls on the web. Many trap focus, lack a month and year announcement, or cannot be operated without a mouse at all.

Always allow typed entry as an alternative to the calendar, and state the expected format in hint text, since date order varies between Indian and international conventions. On a mobile-first site, the native date input often gives a better experience than any custom widget. If you keep a calendar, check that arrow keys move between days, that the current selection is announced, and that Escape closes it and returns focus to the field.

Failure 5: mistakes that only show as a colour

A field turns red and nothing else changes. To a person who cannot distinguish that red, or who is listening rather than looking, nothing has happened at all. The same applies to green ticks for success and amber warnings.

The fix: pair every colour signal with text and, where useful, an icon. Say what is wrong and how to correct it, next to the field. Move focus to the first problem after a failed submission so keyboard users are not left scrolling.

A fifteen-minute check for any form

1. Put the mouse aside and complete the form with Tab, arrow keys, Space and Enter only.
2. Watch whether the focus outline is always visible, including inside dropdowns and date pickers.
3. Submit the form empty and see whether you are told what went wrong and taken to it.
4. Start filling the form, wait ten minutes, then continue and see what survives.
5. Zoom the browser to 200% and confirm nothing overlaps or disappears.
6. Run Lighthouse or axe DevTools to catch missing labels and names.
7. Listen to the whole form once with NVDA or VoiceOver.

Do this on the form that matters most commercially first, whether that is an enquiry form, a booking form or the checkout.

Where to start on Monday

Pick your highest-value form and fix the two failures that appear on it most often. Labels and button names take the least time and remove the biggest barriers, so start there, then move on to timeouts and any custom widget.

If the form comes from a plugin you cannot edit, replacing it is often quicker than patching it. Our team rebuilds enquiry and checkout forms as part of website development work, including the keyboard and screen reader testing.

Frequently asked questions

Are CAPTCHAs an accessibility problem?

Image and audio challenges are difficult or impossible for many people. Prefer invisible or risk-based checks, and always provide a route to complete the task another way, such as a phone number or an email address.

Does adding ARIA attributes make a form accessible?

Not on its own. ARIA describes behaviour that must already exist; a div with a role of button still needs keyboard handling. Native HTML elements come with that behaviour built in.

My form works with a mouse and looks fine. Do I still need to test?

Yes, because the common failures are invisible to a mouse user. A keyboard-only pass takes a few minutes and finds most of them.

Can I rely on an accessibility overlay widget to fix these?

Overlays cannot repair missing labels, unnamed buttons or broken keyboard support in a custom control. They address surface presentation, so fixing the markup remains the only dependable route.