As a blind person, I often encounter avoidable barriers when completing mobile web forms—barriers that turn simple tasks into frustrating challenges. Fillable forms are as common on mobile websites and apps as on desktop platforms. Since portable devices are slowly replacing traditional systems for many computing tasks, I feel it is pertinent to cover this subject again.
In the remainder of this blog, I will discuss some common shortcomings with mobile web form accessibility. This discussion will exclusively pertain to touch-based screen readers, as those interactions present a unique set of challenges often overlooked.
Common Accessibility Issues in Mobile Web Forms
Blind users navigating forms on mobile devices with screen readers often encounter these significant barriers:
These issues can make it impossible to complete basic tasks like logging in or submitting a purchase—unless mobile forms are built with accessibility in mind.
On many occasions, I'll use a mobile web form only to discover that I cannot enter some—or even all—of the text fields for data input. The symptoms of this shortcoming vary from form to form. Sometimes, I hear all the text field name labels, but activating the relevant option with a double tap does nothing. The virtual keyboard doesn't appear, and the screen reader does not indicate that I've enabled the text edit mode.
Other times, activating the field name will technically put the screen reader into edit mode, but the virtual keyboard fails to populate. Either way, I can't fill out the form because I can't interact with the on-screen keyboard.
I have a theory about what causes this very common problem. If the text field doesn't have a corresponding label in the code, screen readers will often wholly miss or ignore the field. However, the visual text name label above the field is discovered and spoken aloud. Since that label is just plain text, activating it does nothing.
Screen reader users must activate the field to invoke the keyboard and input text, but that's impossible if the field is virtually invisible to the screen reader.
Evidence supports this theory when examining correctly working accessible forms on mobile. Let's say I'm moving through a web form using manual swipe navigation to advance one web element at a time:
In this case, my screen reader will detect the field and the visual label as separate web elements, and both are accessible. But when the website doesn't have the field coded for screen reader detection, users only hear the plain text label—unlinked, unactionable, and ultimately useless. This experience is why code-based labeling is essential for screen reader accessibility.
You can read more on the importance of proper form labeling in this guest blog on accessible form design.
Keyboard overlap is another highly frustrating accessibility defect often appearing on mobile web forms. Let's say I'm filling out a lengthy web form using the virtual keyboard on my smartphone. While the first few fields are visible on the top half of the display, the rest of the form is hidden behind the keyboard, occupying the screen's bottom portion.
As I swipe through the form and reach the point where the keyboard begins to overlay the next fields, the screen reader's focus leaves the form and jumps to the first row of letters on the keyboard. At that point, I can't easily place the focus cursor in the visibly hidden fields.
The only workaround is:
Doing this repeatedly is long, clunky, and tedious—especially on longer forms. One might ask, "Why not just scroll to unhide the fields?" That seldom works well. Websites will calibrate screen scroll gestures to move the display by a full page at a time. So if the hidden section of the form is part of page one, scrolling will take me to the beginning of page two—skipping right over what I need.
When this works properly, the screen reader's focus stays with the form. As I reach the point where the keyboard begins to obscure the screen, the page advances just enough to reveal the following field. Each field is uncovered as I move through the form.
I know from experience that this interaction can be accessible. However, too many mobile web forms fail to do it.
Another issue I sometimes encounter when interacting with fillable forms on mobile is that focus will jump away from the field I'm editing—sometimes to a completely unrelated spot on the page. This jump can happen without any indication, which means I may enter data in the wrong field without realizing it.
Here's how this typically plays out:
Touching a letter and double-tapping inputs it into the selected field. Because I'm familiar with the keyboard layout, I can usually do this quickly. But on some forms, I'll return to review the field contents—only to find that not all the text I entered is there. It has sometimes ended up in a different field altogether.
That happens because of a random focus jump during the typing process. Since my attention is on the keyboard, I don't hear the change in focus. The screen reader announces each letter I tap, so it doesn't reflect what's happening elsewhere on the screen. When I review the form and discover the misplaced text, I'll only find out later.
Sometimes, the errant text lands in another text field. Other times, the focus may have jumped to a non-text web element—at which point the typing feedback changes, and I realize something has gone wrong. Either way, I'm left hunting through the form to find where my input went. It's annoying, time-consuming, and makes the process feel unreliable.
Text entry on mobile devices is a necessary part of full digital access. And yet, for screen reader users, that experience is often compromised in subtle but impactful ways.
The issues described above—whether it's invisible fields, inaccessible layouts, or unpredictable focus behavior—are more than technical bugs. They are barriers to participation in everyday tasks like shopping, submitting forms, or accessing services.
These challenges were also the focus of my earlier post on accessibility challenges faced by blind screen reader users, in which I explored similar frustrations on the desktop.
Developers and designers working toward compliance with WCAG 2.2 or newer regulations like the European Accessibility Act (EAA) will want to ensure mobile forms meet both functional and usability expectations. If your forms block people from completing them, they're not genuinely accessible—regardless of whether they technically pass an audit.
To create mobile forms that are truly accessible, consider these steps:
Accessible forms aren't just about compliance, inclusion, efficiency, and equal opportunity. If your business operates in the EU, the EAA compliance timeline makes it even more urgent to get this right.
If you're working to improve mobile form accessibility, tools like UsableNet's Accessibility Checker can help you identify and prioritize common issues. And if you're looking to go deeper, the guest blog on accessible form design offers practical advice for building better forms from the ground up.
What does it take to get started or how different solutions compare?
Explore our pricing and product comparison page to find the best accessibility fit for your team.