Quick Summary
- Most forms fail when fields don’t have clear labels.
- Make every field usable by keyboard and screen readers.
- Show clear errors in text and explain how to fix them.
- Accessible forms reduce drop-offs and legal risk in the EU.
Forms can make or break someone's experience with your website. Forms allow your visitors or clients to connect with you by providing information, feedback, or obtaining a service or product.
The problem? According to WebAIM's 2024 Million Report, 48% of homepages fail Web Content Accessibility Guidelines (WCAG) audits due to missing form input labels. This single issue affects nearly half of all websites and is one of the leading triggers for accessibility complaints under the European Accessibility Act (EAA).
Problems arise when website designers and developers do not create forms that are built for anyone to use regardless of who they are. Issues occur when someone doesn't know how to fill out a field, receives a vague error message, or cannot navigate the form with a keyboard. Keyboard barriers remain common and can make forms impossible to complete for many users.
Why Forms Trigger EAA Complaints
EAA enforcement is complaint-driven and task-based. Regulators don't audit every WCAG criterion but they respond when users cannot complete essential tasks like:
- Making a purchase
- Booking an appointment
- Submitting a contact form
- Accessing account information
Real enforcement is already happening: In November 2025 it is reported that French disability rights organizations ApiDV and Droit Pluriel filed the first EAA lawsuits against four major retailers (Auchan, Carrefour, E.Leclerc, and Picard), specifically citing inaccessible checkout forms and processes. In the Netherlands, the ACM (Authority for Consumers & Markets) can impose fines for accessibility violations.
Our job is to guide people through the forms on our website to ensure that they are filled out correctly and allow someone to meet their end goal. The more direct and intentional we are with creating forms, the less likely someone will abandon the form or be unable to achieve their goal.
Check the Length and Complexity of Your Form
Before you do anything else, you need to determine the purpose of having this form on your website. Write the end goal and then critically look at the form, its length, and whether it is doing its job to achieve that goal.
Research shows that form abandonment increases significantly with form length. According to multiple UX studies, form abandonment rates can exceed 70% for longer forms. This step is often overlooked because we often think everything is important. Many of us want to know everything about the person to make sure we do not miss anything. This approach often backfires and leads to form abandonment since it becomes too much work.
Focus on information that you cannot obtain without asking it through this form. Consider whether this information is necessary for the end goal. (wcag: 3.3.7 label: Redundant Entry) specifically addresses this by requiring that information previously entered should not need to be entered again in the same process.
I recommend keeping your form fields to the minimum necessary. Start with your most important question first. Form abandonment typically increases after the first few questions, especially if they are complex. For example, if you really want to know what someone thinks about your website or service, put that question first. If name is first and that's the only field someone fills out, it won't help you since you're looking for website or service feedback.
Create a map of the form by having the goal or end result at the top. Add the fields under it that will help you reach that goal or end result. For more complex forms or dynamic forms, you can branch them off so questions are only added for specific answers and not for all users.
Of course the number of questions is situational, but overall, your mission should be to reduce cognitive load for the person filling out the form. This is particularly important for users with cognitive disabilities, ADHD, or dyslexia. These conditions affect approximately 15-20% of the population according to accessibility research.
Build Accessibility in From the Start
Our forms need to work for everyone, not just someone who can use a mouse. Before a developer starts creating the form, it should be built with accessibility and usability in mind. This means that forms have proper labels, help text, and clear directions.
This aligns with multiple WCAG 2.1 Level AA success criteria required by the EAA:
- (wcag: 1.3.1 label: Info and Relationships): Form labels must be programmatically associated with their inputs
- (wcag: 3.3.2 label: Labels or Instructions): Labels or instructions must be provided when content requires user input
- (wcag: 4.1.2 label: Name, Role, Value): Form controls must have accessible names that assistive technologies can understand
Proper implementation looks like this:
<!-- CORRECT -->
<label for="email">Email address (required)</label>
<input type="email" id="email" required aria-required="true">
<!-- INCORRECT - Placeholder is not a label -->
<input type="email" placeholder="Email address">
Make it easier for everyone to understand what you're looking for and make sure it works the same whether someone is using a screen reader, keyboard navigation, or mouse.
According to W3C guidance, labels must be:
- Visible to all users (not hidden)
- Positioned close to their inputs (typically above or beside)
- Persistent (unlike placeholders which disappear when typing)
Don't Rely on Color Alone
Labels and error messages should not rely on color to convey meaning. This addresses (wcag: 1.4.1 label: Use of Color). Color can be used as long as there are other ways someone can get the same message.
For example, an error state should include:
- Text describing the error
- An icon (âš )
- Color (red)
- ARIA attributes (
aria-invalid="true")
Never use just a red border without accompanying text—users who are colorblind or using screen readers won't know an error occurred.
Use Error Messages to Help
Nothing is more frustrating than filling out a form and having it rejected because a field was not filled out properly. (wcag: 3.3.1 label: Error Identification) requires that when an input error is automatically detected, the item in error must be identified and the error described to the user in text.
Additionally, (wcag: 3.3.3 label: Error Suggestion) states that if an error is detected, suggestions for correction should be provided unless it would jeopardize security or the purpose of the content.
Error messages should be:
- Clear and specific at the top of the form
- Positioned near the field with the error
- Linked programmatically using
aria-describedby
Instead of writing, "This field is not filled out properly," use something like:
Full Name Error: Please enter your full name with at least 2 characters. If your name is shorter than 2 characters or you're having difficulty, please contact support at support@yourwebsite.com.
Why the rewrite works:
- Identifies which field has the error (Full Name)
- Explains the requirement (2 characters minimum)
- Provides context and an alternative solution
- Gives the person agency to fix it or seek help
For financial or legal transactions you must go one step further. (wcag: 3.3.4 label: Error Prevention) requires that submissions be reversible, checked before submission, or confirmed before finalizing.
Explain Why You're Collecting Information
Building trust starts with being transparent about what you plan to do with the data once you obtain it. This gives the person a choice on whether they want to continue filling out the form or object to filling out certain fields.
This intersects with both accessibility and privacy compliance. The EU's General Data Protection Regulation (GDPR) requires transparency about data collection, and the EAA requires that privacy controls and consent forms themselves be accessible. An inaccessible cookie banner or consent form could violate both regulations.
Many countries also have laws and legal requirements that allow individuals to see what data is being collected and have it removed in a timely manner. Consult with legal counsel in your area to see if there are any requirements that apply to your organization.
Conduct User Testing Within Your Organization
Conducting user testing prior to launching to a wider audience is helpful even for a small team. By testing with people within your organization, it's a great way to gauge how well your form is structured.
This test is very informative because if people most familiar with your line of work are struggling to complete the form, then it's time to go back to the drawing board. Once you establish the form is useable and obtaining the expected results, you can move on to outside organizational testing.
Form testing should be done with a diverse group of people, including users with disabilities. According to W3C's Forms Tutorial, testing should include:
- Keyboard-only navigation
- Screen reader testing (NVDA, JAWS, VoiceOver)
- Users with cognitive disabilities
- Mobile device testing
- Various browser combinations
This is crucial to identifying pain points within your form and what you need to do to fix them. The EU has approximately 87 million people with disabilities; that's a significant market you're potentially excluding with inaccessible forms.
Do Not Get Fancy With Design or Layouts
Simple is better. You do not necessarily need someone to spend a lot of time completing the form unless that is the goal.
Layouts should be optimized for:
- Multiple devices and screen sizes
- Sufficient color contrast (4.5:1 for normal text, 3:1 for large text per WCAG 1.4.3)
- Single column layout for easier navigation
- Clear visual hierarchy
Use a single-column layout for your form as it is easier to see the fields and navigate with screen readers.
For required fields: You can indicate them with text "(required)" or with an asterisk, but not by color alone. If using an asterisk, you must:
- Explain what the asterisk means at the top of the form
- Use
aria-required="true"on the input element - Include text like "(required)" for screen reader users
When designing forms, they should load quickly with information clearly visible on all platforms. While fun designs may make your form stand out, it may not be in a positive way. People expect forms and websites in general to behave a certain way. Do not sacrifice usability and accessibility for visual design.
Ensure Keyboard Accessibility
This addresses (wcag: 2.1.1 label: Keyboard) and (wcag: 2.4.7 label: Focus Visible). All form functionality must be operable through a keyboard interface, and there must be a visible focus indicator.
Test by unplugging your mouse and using only Tab, Shift+Tab, Enter, and arrow keys:
- Can you reach every form field?
- Is there a visible outline showing which field has focus?
- Can you select options in dropdowns?
- Can you submit the form?
- Are you ever trapped in an element?
Common keyboard failures:
- Custom dropdowns built with
<div>instead of<select> - CSS that removes focus outlines (
outline: none;) - Modal dialogs that trap keyboard focus
- Submit buttons that aren't keyboard accessible
Check Your Form Regularly
Forms can break over time, especially when new updates are implemented or other changes are made to the website. Regular web form checks are essential to ensuring that your form is always able to be completed.
Forms should also be checked for regulatory and legal compliance throughout the year. With the EAA now in effect since June 28, 2025, ongoing monitoring is legally required. Each EU Member State has established enforcement authorities that can:
- Investigate complaints
- Conduct audits
- Issue corrective orders
- Impose financial penalties
Seek legal counsel in your area to ensure compliance with applicable requirements. Laws can change, and checking your form regularly helps you stay ahead.
Remove Barriers With Security
I am all for website security, especially when it comes to forms. With that said, there are some barriers when it comes to form security that not everyone can complete. This includes CAPTCHA fields you see across the web when trying to complete a form.
Traditional CAPTCHAs create significant accessibility barriers:
- Image-based CAPTCHAs exclude blind users
- Audio alternatives are often distorted and difficult to understand
- They're time-consuming and error-prone for everyone
(wcag: 3.3.8 label: Accessible Authentication) addresses this by requiring that cognitive function tests (like remembering passwords or solving puzzles) not be required for authentication unless alternatives are available.
Better alternatives include:
- Honeypot fields (invisible fields that bots fill out)
- Time-based validation
- reCAPTCHA v3 (invisible, score-based)
- Two-factor authentication via SMS or email
- Biometric authentication where appropriate
Be sure to keep your form and the data you're collecting secure. Investigate methods that work for your team and organization while maintaining both security and accessibility. Depending on the data being collected, you may need multiple secure authentication and validation methods for data security and protection.
The Bottom Line
Forms frequently have accessibility and usability issues. This often leads to people being unable to fill out the form, frustration over completing the form, or both. With 48% of websites failing on form labels alone and the EAA now actively enforced through lawsuits and regulatory complaints, accessible forms are no longer optional—they're legally required for businesses serving EU markets.
For a more inclusive web, all of us should strive to make sure our forms can be filled out by as many people as possible. This isn't just about compliance, it's about not excluding 87 million potential customers in the EU from doing business with you.