Building accessible forms that people actually want to fill in
Most web forms are terrible. They're inaccessible, confusing, and ask for information nobody needs. Here's how I approach building forms that work for everyone.
Every client project I've worked on in the past three years has included at least one form, and almost every redesign I've done has revealed a form that was quietly losing the client leads or enquiries. Not because of a technical bug, but because the form was just unpleasant to use. Too many fields, confusing labels, no error feedback, impossible to complete on a phone, the usual catalogue of problems that somehow persist across the industry. Sound familiar?
Accessibility and usability aren't separate concerns here. A form that's accessible to screen reader users is almost always a form that's easier for everyone to use, because the same principles apply: clear labels, logical tab order, helpful error messages, and a structure that makes sense.
Labels, not placeholders
The single most common mistake I see is using placeholder text as labels. It looks clean in a mockup, but the moment someone starts typing, the label disappears and they can't remember what the field was for. This is particularly problematic for anyone using assistive technology, but it's also just poor UX for everyone. Every input needs a visible label, associated with the input via the 'for' attribute. No exceptions.
Error handling that actually helps
The second most common problem I see is error handling that amounts to turning a border red with no explanation. Screen readers can't see a red border. Even sighted users often can't tell which field has the error or what they need to fix. Good error messages are specific, not "This field is invalid" but "Please enter a valid UK postcode, for example SW1A 1AA." They're associated with the input via aria-describedby so assistive technology can announce them. And they appear inline, next to the field, not in a banner at the top of the page that forces users to scroll up and then hunt for the problem.
Keep it short
Every field you add to a form reduces the completion rate. This is well-documented, Formstack's research suggests that reducing a form from four fields to three can improve conversion by nearly 50%. Before adding a field, ask whether you genuinely need that information at this stage. Do you need a phone number on an enquiry form? Do you need separate first name and last name fields? Often the answer is no, and stripping back the form to its essentials makes a measurable difference.
The technical bits
Use native HTML form elements wherever possible. A styled div with a click handler is not a button. The autocomplete attribute saves users time and reduces errors, autocomplete="email", autocomplete="postal-code", autocomplete="tel". Group related fields with fieldset and legend. Use inputmode to trigger the right keyboard on mobile, inputmode="numeric" for phone numbers, inputmode="email" for email addresses.
I test every form I build with VoiceOver and NVDA before it ships. It adds maybe thirty minutes to the QA process and catches issues that no amount of visual testing would reveal.
If your forms aren't converting as well as you'd like, or you're not sure they meet accessibility standards, I'd be happy to take a look, get in touch.
Chris Ryan
Managing Director
17+ years in full-stack web development, most of it leading teams agency-side across e-commerce, CMS platforms, and bespoke applications. Specialises in infrastructure, system integration, and data privacy, with hands-on experience as a Data Protection Officer. Founded Innatus Digital in 2020 to offer the kind of honest, technically-led partnership that he felt was missing from the agency world.