In 2016, Guillermo Robles took Domino’s to court because he couldn’t place an order through its website or app using a screen reader. As a blind customer, he relied on this technology to navigate the site, but it didn’t give him the access he needed to complete his purchase. The Ninth Circuit Court of Appeals ruled that the Americans with Disabilities Act applied to Domino’s website and app. Domino’s later appealed to the US Supreme Court, which declined to hear the case in 2019.
It’s a good example of how a website can look great on the surface but still leave some people struggling to use it. What seems like a simple task, such as ordering a pizza, can become frustrating when a website isn’t designed with accessibility in mind.
Think about a simple checkout form. If a screen reader can’t identify the fields, a customer may have no idea what information to enter. If the submit button isn’t properly labelled, they might struggle to figure out how to place their order. Everything may appear to work on screen, yet completing a purchase becomes an unnecessary challenge.
The problem isn’t the person using the website. It’s how the form was designed. Good form design comes down to a few things that are easy to get right but just as easy to overlook. Field labels should make it clear what information users need to enter. Error messages should explain what went wrong and how to fix it, rather than leaving people guessing. And anyone using a keyboard to navigate a website should be able to move through the form and submit it without running into problems.
The trouble is that these details can get lost when the focus is mainly on how a website looks. A form might work perfectly well with a mouse but become frustrating to use with a keyboard or screen reader. That’s why testing a form’s appearance isn’t enough. It also needs to work for people who interact with it in different ways. That’s why accessibility needs to be part of the design process from the start, not something added at the last minute. In this article, we’ll explore how leading web design companies approach accessible form design and why small improvements to labels, error messages, and login experiences can make websites easier for everyone to use.
A Placeholder Is Not a Label
Every year WebAIM scans the home pages of the top one million websites. In 2026, 51% of them had form fields with no proper label. The average page had about seven form inputs, and roughly one in three of those inputs wasn’t labeled. So picture a search box or an email signup where a screen reader user has to guess what goes in the field.
Placeholder text is a big part of this. That’s the light grey hint sitting inside an empty field, and designers like it because it looks tidy. The GOV.UK Design System says not to use it as a label, for a few reasons. It disappears the moment you start typing. Some screen readers skip it. And the default browser styling is often too faint to meet WCAG contrast rules. Put a real label above the field. It’s honestly that simple.
Even Careful Teams Pick the Wrong Input Type
Here’s a good one from the UK government. The GOV.UK Design System team used <input type=”number”> for date fields because it pulls up the big number keypad on phones. Their 2017 research hadn’t turned up any major problems with it.
It turned out there were plenty. People using Dragon NaturallySpeaking couldn’t dictate into the field. The NVDA screen reader listed it as unlabeled. Chrome quietly deleted most letters people typed and gave no warning. Scrolling the mouse wheel over it could even change the number. In 2020 the team switched to a plain text input with inputmode=”numeric”, which still brings up the number keypad.
GOV.UK takes accessibility more seriously than almost anyone, and the problem still went live before they caught it. Which input type to use sounds like a call developers can make on their own. But it decides whether someone using voice control or a screen reader can get through the form, and few teams ever test with those tools.
Error Messages Decide Who Finishes
Baymard Institute studies checkout usability, and its numbers on form errors aren’t great. About 31% of sites it tested have no inline validation at all. Some go the other way and flag an email address as wrong while the person is still typing it. Others leave the error message up after it’s been fixed. And 98% of sites in Baymard’s benchmark show generic error messages, even when the system knows exactly what the problem is.
Now think about someone who can’t see the screen. A field outlined in red means nothing to them. GOV.UK’s guidance asks for plain, specific wording like “Enter your first name.” Its sample code also links each error to its field with aria-describedby, so a screen reader reads the error out. It’s one attribute in the code, and without it a blind user may never find out what went wrong.
More Code Often Means More Barriers
Fancy custom dropdowns, restyled checkboxes, homemade date pickers. These are where forms usually break for keyboard and screen reader users. WebAIM found that pages using ARIA (code that’s supposed to make custom components accessible) averaged 59.1 detected errors, versus 42 on pages without it. To be fair, WebAIM doesn’t say ARIA caused those errors, since the pages using it also tended to be more complex.
WebAIM thinks the bigger problem is that pages keep getting more complicated, with more third-party libraries and more AI-written code. Standard HTML form controls already work with a keyboard and a screen reader. So the sensible move is to start with those. If a custom component is really needed, test it with a keyboard and a screen reader before it goes live.
A Login Form Shouldn’t Be a Memory Test
This one surprises people. WCAG 2.2 counts remembering a password as a “cognitive function test.” If your login depends on one, you need to offer another way in, or something that helps the person get through it. The W3C points out that when login fields are coded properly, browsers and password managers can fill them in automatically.
That’s why blocking paste on password fields is a bad idea, even though plenty of sites still do it in the name of security. GOV.UK’s guidance says not to disable copy and paste. It also recommends the autocomplete attribute so browsers can fill in details people have already entered. If paste is blocked, password managers stop working, and anyone who has trouble typing a long string of characters is stuck.
What To Ask Before You Approve a Form Design
Start with testing. Automated scanners are useful and they’ll catch a missing label. But WebAIM says plainly that tools can’t find every problem, and a clean scan doesn’t mean a page is accessible. Ask the agency whether anyone actually fills out the form using only a keyboard, and then again with a screen reader, before launch.
A few more questions are worth asking. Can they show you an error state and what a screen reader says when it happens? Which form controls are standard HTML and which are custom, and why? An agency that’s done this before will answer without much hesitation. If all you hear is “we run a scanner,” that tells you how much testing your forms will get.
None of this is especially hard to do. It’s just easy to skip when nobody on the team uses a screen reader or a keyboard to test. The agencies that get forms right are the ones that test with those tools before launch. Browse our vetted list of web design agencies to find a team that understands accessible form design.