What Are the Biggest Mistakes Developers Make With Accessible Forms?

Forms are one of those things that seem simple to build but often cause the most problems when it comes to accessibility, and I've spent the last ten years working on apps where forms are the main way users interact with the whole system. The thing about accessible forms is that they affect more people than most developers realise, not just users with screen readers but people with motor difficulties, those with cognitive differences, users on mobile devices with varying input methods, and frankly anyone who's ever tried to fill out a form in a rush. When we built a healthcare app a few years back, we discovered that nearly thirty percent of users were abandoning the registration form, not because they didn't want to use the app but because the form itself was creating barriers they couldn't get past. It was a proper wake-up call.

Making forms accessible isn't about ticking boxes for compliance, it's about making sure everyone who wants to use your app actually can

The patterns I've seen repeated across hundreds of projects tell me that most form accessibility problems come from a few common mistakes, things that seem small during development but become huge blockers for real users trying to complete real tasks. These mistakes cost businesses money through lost conversions, they create support headaches when users can't work out what's gone wrong, and they can even land you in legal trouble depending on where you operate and what sector you're in. What makes this frustrating is that most of these problems are completely avoidable once you know what to look for, and the solutions aren't particularly complex or expensive to put in place.

Forgetting That Screen Readers Need Proper Labels

This is probably the single biggest mistake I see, and it happens because developers test forms with their eyes rather than thinking about how screen reader users experience them. A screen reader needs explicit text labels connected to form fields through proper HTML structure, but what often happens is designers create beautiful forms where the placeholder text sits inside the input box looking lovely, then developers build exactly what they see without adding proper labels. The placeholder disappears as soon as someone starts typing, which is annoying for everyone, but for screen reader users there's often nothing there in the first place to tell them what the field is for.

When you don't connect labels to inputs properly using the 'for' attribute that matches the input's ID, screen readers can't tell users what information each field needs. I've tested forms where screen reader users heard "Edit text, blank" seventeen times in a row with no way to know which edit text was for their email and which was for their postcode. It's kind of like being asked to fill in a paper form where all the labels have been removed.

The fix is straightforward but you need to be consistent about it across every single form in your app. Each input needs a proper label element, that label needs to be visible on screen (not hidden or replaced by placeholder text), and the label must be programmatically associated with its input. This is basic stuff but you'd be surprised how many apps get it wrong, especially when working with AI-generated code that might miss these accessibility fundamentals.

• Use label elements with 'for' attributes that match input IDs exactly
• Keep labels visible at all times, even when users start typing
• Don't rely on placeholder text to explain what a field is for
• Group related fields using fieldset and legend elements for things like address sections
• Make sure icon-only buttons have proper aria-label attributes to describe their function

Making Error Messages Invisible or Confusing

Error handling is where I've seen apps lose the most users, particularly in sectors like fintech where forms are long and the validation rules are strict. The classic mistake is showing error messages that appear visually somewhere on the screen but aren't announced to screen readers, so users submit a form thinking everything's fine, nothing happens, and they have no idea why. Or the error appears as a red border around the field with no actual text explanation, which helps nobody but especially not users who can't see the colour change or don't understand what it means.

I worked on an insurance app where users were getting stuck on a national insurance number field because the error message said "Invalid format" but never explained what the valid format actually was. Users would try two or three times, get increasingly frustrated, then abandon the whole application. When we changed it to "Enter your National Insurance number in this format: AB 12 34 56 C", the error recovery rate went up by something like sixty percent. This kind of user experience issue directly impacts insurance app development costs because you end up spending more time on support and user retention.

Error messages need to do several things at once... they need to be visually clear and positioned near the problem field, they need to be announced by screen readers as soon as they appear, they need to explain what went wrong in plain language, and they need to tell users exactly how to fix it. That's quite a lot of requirements but each one matters.

Add error messages to the accessibility announcement queue using ARIA live regions, and make sure they appear before the form field in the reading order so screen reader users hear the problem before reaching the input that needs fixing.

Ignoring Keyboard Navigation and Focus States

Loads of people can't use a touchscreen the way developers assume they will, whether that's because of motor control difficulties, because they're using a Bluetooth keyboard with their tablet, or because they just prefer keyboard navigation for speed. When forms don't work properly with keyboard controls, these users get completely stuck. The most common problem I see is custom form elements (particularly dropdowns and date pickers) that look gorgeous but completely break keyboard navigation because they're built with divs and spans instead of proper form elements.

Tab order matters more than most people realise. Users should be able to press Tab to move forward through form fields in a logical order, Shift plus Tab to move backward, and they should always be able to see where they are through a clear focus indicator. I've tested apps where the focus indicator was removed entirely because someone thought it looked ugly, which meant keyboard users were navigating blind. Other times the tab order jumps around the screen in random ways because the HTML structure doesn't match the visual layout. Understanding why accessibility matters in mobile app design helps you avoid these fundamental navigation issues.

Testing Keyboard Navigation

Put your mouse away and try to complete your entire form using only the keyboard. If you can't do it smoothly, neither can your users. Every interactive element needs to be reachable and usable with keyboard alone.

Using Colour Alone to Show Errors

About eight percent of men and half a percent of women have some form of colour vision deficiency, which means roughly one in twelve blokes can't reliably distinguish between certain colours. When you show form errors by just changing a field border from grey to red, or when your success message is only indicated by green text, you're creating barriers for millions of users. This isn't just a theoretical problem either... I've watched user testing sessions where colour blind participants kept submitting forms with errors because they couldn't see the visual indicators, then got frustrated when nothing happened.

Colour is a useful additional indicator but it should never be the only way you communicate important information in your forms

The solution is to use multiple visual cues working together. When a field has an error, yes, change the border colour if you want, but also add an icon (like an exclamation mark or X symbol), display text that explains the error, and maybe change the thickness of the border or add a background colour. The more ways you signal that something needs attention, the more likely users are to notice regardless of how they perceive colour. This approach is particularly important when building apps for children with learning difficulties, as they may process visual information differently.

Success states need the same treatment. Instead of just turning a field border green when validation passes, show a tick icon and maybe include some brief text like "Looks good" or "Valid email address". These additional cues help everyone, not just users with colour vision differences, because they provide redundancy in your communication. If someone misses one signal, they'll catch another.

Building Forms That Time Out Too Quickly

Security timeouts are necessary for sensitive apps in banking or healthcare, but I've seen implementations where forms expire so quickly that users with cognitive disabilities or anyone who needs a bit more time to read and understand questions simply can't complete them. A fintech app we worked with had a fifteen-minute timeout on their mortgage application form, which sounds reasonable until you realise the form has forty-three fields and requires users to go dig out documents like payslips and bank statements. People were losing half-completed applications and having to start from scratch.

Timeouts disproportionately affect users with disabilities. Someone using a screen reader takes longer to navigate through form fields because they're listening to each element being announced. Users with motor control difficulties need more time to operate controls precisely. People with cognitive disabilities might need to read questions several times to process what's being asked. When your timeout is too aggressive, you're basically telling these users they're not welcome. This is one of those financial risks you should consider before app launch because inaccessible apps can face legal challenges and lose significant user segments.

Handling Timeouts Properly

If you need timeouts for security or technical reasons, give users at least twenty minutes for any substantial form, warn them before the timeout occurs (with at least two minutes notice), let them extend the session easily, and save their progress automatically so they don't lose work. Some apps I've built use background auto-save that stores form data locally on the device, which means even if a session expires, users can recover their work when they log back in. The technical lift for this is pretty small but the user experience improvement is massive.

Forgetting About Different Input Methods

Mobile users might be typing on a tiny screen keyboard, using voice dictation, or relying on predictive text and autocomplete, while desktop users could be working with a physical keyboard, speech recognition software like Dragon, or switch controls that let them navigate using just one or two buttons. Each input method has different needs, and forms that only consider standard typing can become proper nightmares for other approaches. Voice features can significantly improve app accessibility when implemented thoughtfully alongside traditional input methods.

Input types matter more on mobile than anywhere else. When you specify the right input type attribute on your form fields, mobile operating systems show the appropriate keyboard layout automatically. Email fields should use type equals email so users get a keyboard with the at symbol readily available, phone numbers should use type equals tel to show a number pad, and URL fields should use type equals url to make entering web addresses easier. This seems obvious but I regularly test apps where every field uses type equals text, which means users are hunting through multiple keyboard screens to find basic characters.

Test your forms with voice dictation turned on, both on iOS and Android, because you'll quickly discover which fields have problems when users aren't typing manually, and you'll find labels or instructions that made sense visually but are confusing when read aloud.

• Match input types to the data you're collecting (email, tel, number, url, date)
• Enable autocomplete attributes so password managers and browser autofill work properly
• Don't disable paste functionality, especially in password fields, because many users rely on password managers
• Make tap targets at least 44 by 44 pixels for mobile users, bigger if possible
• Provide enough space between form fields so users don't accidentally tap the wrong one
• Test with speech recognition software to make sure voice commands work

Making Required Fields Unclear

Users waste so much time on forms that don't clearly mark which fields are required versus optional. The red asterisk has become sort of standard, but on its own it's not enough because screen reader users might not know what the asterisk means unless you tell them, and users with cognitive disabilities might not understand the symbol convention. I've seen forms where required fields were marked with an asterisk but there was no legend anywhere explaining what the asterisk meant, which is like writing in code and not providing the decoder ring.

The opposite problem happens when everything looks required but actually some fields are optional. Users get stressed trying to complete fields when they don't have the information, or they abandon the form entirely thinking they can't proceed. An e-commerce app we built originally marked every field as required, including things like "Company name" and "Address line 2", which meant loads of residential customers thought they couldn't complete checkout. When we switched to marking optional fields with "(optional)" next to the label instead, completion rates jumped up noticeably. This kind of user experience testing should happen before you launch, and it's worth understanding how much thorough development and testing affects your app budget.

Clear Required Field Marking

The best approach I've found is to use multiple indicators working together. Add the word "required" or "optional" in text next to or inside the label, use visual indicators like asterisks if you want but don't rely on them alone, add aria-required equals true to required fields so screen readers announce them properly, and include a short note at the top of the form explaining your convention.

Not Testing With Real Assistive Technology

You can't really know if your forms are accessible until you test them with the actual tools that disabled users rely on, but most development teams never do this. They might run an automated checker that finds some basic problems, tick the accessibility box, then ship it. Automated tools are useful, they'll catch missing labels and colour contrast problems and broken HTML structure, but they can't tell you if your form actually makes sense when someone's using VoiceOver or TalkBack or Dragon speech recognition.

I've seen forms that technically passed every automated accessibility test but were completely unusable with a screen reader because the reading order was illogical, the error announcements were confusing, and custom components didn't behave the way users expected. The only way we discovered these problems was by sitting down with actual screen reader users and watching them try to use the app. It was kind of humbling, to be honest, because things that seemed fine when we tested them visually fell apart completely when approached differently. This kind of testing is essential, especially if you're trying to avoid the kinds of issues that come up when checking whether your accessibility implementations might infringe on existing patents or standards.

Real user testing with assistive technology will teach you more in an hour than a hundred automated scans, because it shows you how people actually experience your forms rather than just whether your code follows technical rules

Every mobile platform has built-in screen readers you can turn on right now... VoiceOver on iOS, TalkBack on Android. Learning to use them takes a bit of time but it's not complicated, and once you've tested your own forms with a screen reader enabled you'll never look at form design the same way. You'll notice things like how many swipes it takes to reach the submit button, whether error messages are announced properly, if custom controls make any sense when you can't see them, and whether the whole form has a logical flow when navigating by touch. This testing approach is particularly valuable when researching what competitors are doing right in terms of accessibility features.

Conclusion

Form accessibility affects every single user of your app at some point, whether they have a permanent disability, a temporary impairment, or are just using your app in difficult circumstances with one hand while holding shopping bags. The mistakes I've covered here are the ones that cause the most problems across the projects I've worked on over the years, but they're all fixable with a bit of thought and testing. Start by getting the basics right... proper labels, clear error messages, keyboard navigation, multiple visual cues, reasonable timeouts, appropriate input types, obvious required fields, and real testing with assistive technology. None of this is particularly hard or expensive to implement, it just needs to be part of your process from the start rather than something you try to bolt on at the end. When you build accessible forms, you build better forms for everyone, and that means more people can actually use what you've made.

If you need help making your app's forms more accessible or want someone to review what you've already built, get in touch with us and we can talk through what would work best for your situation.

Frequently Asked Questions