Form Accessibility – How to Find and Fix Accessibility Issues

According to Zuko’s 2025 form benchmarking data, the average form conversion rate across industries is 51.7%. Nearly half of users who start filling out a form do not finish.

One of the reasons for this abandonment is poor accessibility and usability.

If a form is confusing, too long, or difficult to fill out, many users, especially people with disabilities, may give up. When that happens, you lose leads and sales.

This is why form accessibility is not optional.

In this guide, you will learn what makes a form accessible, how to spot common accessibility issues, and how to fix them the right way.

Form accessibility checklist

Mainly, there are 16 essential checks you should run to evaluate your form’s accessibility.

Some issues can be reliably detected using automated tools. Others are flagged by tools but still require human review. And some can only be found by manually interacting with the form.

The table below lists these checks, along with the type of testing each one requires.

	Check	What to Verify	Type of Check
1	Form labels exist	Every input has a properly linked <label>	Automated
2	Duplicate IDs	No repeated IDs breaking label connection	Automated
3	Color contrast	Text and error messages meet contrast ratio	Automated
4	Empty buttons	Buttons and icon controls have accessible names	Automated
5	No color-only indicators	Required fields, errors, and validation states are not shown using color alone	Semi-Automated
6	Placeholder not sole label	Placeholder text is not the only visible label	Semi-Automated
7	Error association	Error messages programmatically linked to inputs	Semi-Automated
8	Descriptive button text	Submit button clearly describes the action	Semi-Automated
9	Keyboard access	All fields are reachable using Tab key	Manual
10	Logical tab order	Focus follows visual layout	Manual
11	Focus visibility	Clear visible focus indicator on all interactive elements	Manual
12	Screen reader label accuracy	Screen reader announces correct label and state	Manual
13	Error clarity	Errors clearly explain what is wrong and how to fix it	Manual
14	Error announcement	Errors are announced after submission	Manual
15	Zoom support	Form works properly at 200% zoom	Manual
16	Mobile usability	Fields usable and readable on small screens	Manual

How to find accessibility issues in forms

Finding accessibility issues in forms requires a mix of automated tools and manual review.

Automated tools can quickly detect technical problems in the code. However, they cannot fully evaluate usability or interaction. That is why forms also need to be checked manually.

A good approach is to start with automated checks and then review the form step by step.

Step 1: Run automated checks

Start by scanning your form with an automated accessibility testing tool.

The easiest way to do this is by using an accessibility checker Chrome extension. We recommend the Accessibility Checker by WebYes. It quickly scans your form and detects technical issues such as missing labels, duplicate IDs, color contrast problems, and empty buttons.

Step 2: Check labels and required field indicators

Clear labels are the foundation of an accessible form. If a field is not labeled properly, users may not know what information to enter.

Go through each input field, such as name, email, phone number, password, address, and dropdowns. Then verify the following:

• Every form control has a visible label that clearly describes its purpose.
• The label stays visible even after the user starts typing.
• Placeholder text is not acting as the only label.
• Required fields are clearly marked using text like “Required” or a symbol such as *
• If an asterisk is used, it is explained somewhere on the form.
• Required fields are not indicated using color alone.

Labels should be clear, specific, and always visible. Users should not have to rely on memory to recall what a field was asking for.

Step 3: Review error messages and validation

Forms must guide users when something goes wrong. Poor error messages are one of the biggest reasons users abandon forms.

Intentionally trigger validation errors. Leave required fields empty. Enter an invalid email. Use mismatched passwords. Then review how the form responds.

Verify that:

• Error messages appear close to the related field.
• The message clearly states what went wrong.
• The message explains how to fix the issue.
• Errors are not shown using color alone.
• The wording is specific and helpful, not vague.

For example, a message like “Invalid input” is not enough. Users need clear guidance, such as what format is expected or what requirement was not met.

Also, observe what happens after submission:

• Does the page reload and lose user input?
• Does the focus move to the first error?
• Are multiple errors easy to identify?

After submission, the focus should move to the first error so users can correct it immediately.

Users should be able to correct mistakes quickly and confidently.

Step 4: Test keyboard accessibility

Many users rely on a keyboard to navigate and complete forms. If the form cannot be used this way, it creates a serious barrier.

Move through the entire form using only the keyboard. Use Tab to move forward and Shift + Tab to move backward.

Verify that:

• Every field, checkbox, radio button, dropdown, and button is reachable.
• The focus moves in a logical order that matches the visual layout.
• The focus indicator is clearly visible at all times.
• You can select checkboxes and radio buttons using the keyboard.
• You can activate buttons and submit the form without using a mouse.

Pay attention to areas where focus disappears, skips elements, or becomes trapped.

Users should be able to complete the entire form using only the keyboard, from the first field to the final submission.

Step 5: Test dropdowns and interactive components

Forms often include more than simple text fields. Dropdowns, date pickers, autocomplete fields, and other interactive elements require extra attention.

These components may look fine visually but fail during interaction.

Review each interactive element and verify that:

• The dropdown or picker can be opened using the keyboard.
• Options can be navigated using arrow keys.
• An option can be selected using Enter or Space.
• Focus remains visible while interacting.
• Focus does not get trapped inside the component.
• The selected value is clearly displayed after selection.

Also, check how these components behave after an error. If a required dropdown is left unselected, the error message should clearly indicate what needs to be chosen.

Custom-built components are especially prone to accessibility issues because they do not always inherit native browser behavior. Testing them carefully ensures they remain operable and predictable for all users.

Step 6: Check screen reader output

Visual clarity is not enough. The structure and relationships between labels, fields, and errors must also be announced correctly.

Move through the form field by field using a screen reader and confirm that:

• Each input is announced with its correct label.
• The field type is communicated, such as edit field, checkbox, or radio button.
• Required status is announced where applicable.
• Instructions or helper text are read when the field receives focus.
• Grouped options, such as radio buttons, are announced within the correct group.

Next, trigger validation errors and observe what happens.

Verify that:

• The error message is announced automatically after submission.
• The error is associated with the correct field.
• Moving focus back to the field announces the error again.
• Multiple errors are easy to identify and navigate.

The screen reader output should reflect the logical structure of the form. If labels, instructions, or errors are missing or unclear, users may not be able to complete the form independently.

Step 7: Verify zoom and responsive behavior

Finally, check how the form behaves when the layout changes.

Users may zoom in to read content more clearly. Others may complete the form on a mobile device. The form must remain usable in both situations.

Zoom the page to 200 percent and review the form carefully.

Verify that:

• Labels remain aligned with their fields.
• Text does not overlap or get cut off.
• Error messages remain visible.
• Buttons are not pushed off-screen.
• No horizontal scrolling is required.

Next, check the form on a small screen.

Confirm that:

• Fields stack properly and remain readable.
• Tap targets such as checkboxes and buttons are large enough.
• Spacing between elements prevents accidental taps.
• The on-screen keyboard does not hide important content.
• Error messages remain easy to notice and understand.

A form that works on desktop but breaks on mobile is not fully accessible.

How to fix accessibility issues in forms

Once you identify accessibility issues in your form, the next step is to fix them.

Some fixes involve improving the structure of the form, while others focus on interaction, labels, or layout. Addressing these issues helps ensure that all users, including those using assistive technologies, can complete the form successfully.

Below are the most common fixes for form accessibility problems.

1. Use native HTML form controls

Use native or semantic HTML form controls whenever possible. Avoid building form controls using elements like <div> or <span>. These elements have no built-in meaning and do not work correctly with keyboards or screen readers.

<!-- ❌ Bad practice: Custom checkbox using div -->

<div class="checkbox"></div> 
<span>Accept Terms</span> 
<!-- Not announced as checkbox, not keyboard accessible -->

<!-- ✅ Good practice: Native checkbox --> 

<input type="checkbox" id="terms"> 
<label for="terms">Accept Terms</label> 
<!-- Works with keyboard, announced correctly by screen readers -->

Here, the advantage is that native HTML controls automatically expose their name, role, and state to assistive technologies.

For example, a native checkbox is already announced correctly by screen readers and works with keyboards without extra effort.

If a custom control is created using WAI-ARIA techniques, however, all of this information must be provided manually using attributes such as role, aria-label, and aria-checked. This also requires additional work to manage keyboard interaction and state changes.

2. Provide visible and properly connected labels

Every form control must have:

• A visible label
• A programmatic connection between the label and the field

A visible label is the text placed next to a field that tells users what information to enter. Without it, users may not understand what the field is asking for.

However, a visible label alone is not enough. The label must also be programmatically connected to the input field so assistive technologies can recognize the relationship.

For example, the label “Email” should be programmatically connected to the input field where the user enters their email address.

So when a user navigates through a form using a screen reader and focus moves to the input field, the label tells them what the field is for.

For example, if the label is correctly connected, the screen reader will announce:

“Email Address, edit text.”

If the label is missing or not connected, the screen reader may only say:

“Edit text.”

Without the label, the user has no idea what information the field is asking for.

The correct way to connect a label is by using the for and id attributes:

<label for="email">Email Address</label> 
<input type="email" id="email">

When a screen reader user navigates to the field, the label is announced along with it.

This ensures that assistive technologies correctly identify the purpose of the field.

3. Ensure IDs are unique

Every form input must have a unique id.

The id is used to connect the label to the input field. If multiple fields share the same id, assistive technologies may associate the wrong label with the wrong field.

Bad practice:

<label for="email">Email Address</label> 
<input type="text" id="email">

<label for="email">Confirm Email</label> 
<input type="text" id="email">

Here, both inputs use the same id. A screen reader may read the wrong label when the user focuses on the field.

Good practice:

<label for="email">Email Address</label> 
<input type="text" id="email"> 

<label for="confirm-email">Confirm Email</label> 
<input type="text" id="confirm-email">

Each input now has a unique id, and each label correctly points to its own field.

4. Make required fields clear

Users should be able to immediately tell which fields are required.

Do not rely on color alone to indicate required fields. For example, showing a red border around a field is not enough. Some users may not notice the color difference.

Instead, clearly indicate required fields in the label.

You can:

• Add the word “Required” next to the label.
• Use an asterisk (*) and explain what it means.

However, this visual indicator alone is not enough.

From a code perspective, the field should also include the required attribute. This allows assistive technologies to identify that the field must be filled.

Example:

<label for="email">Business Email *</label> 
<input type="email" id="email" required>

When a screen reader user reaches this field, it may announce:

“Business Email *, required, edit text.”

5. Fix color contrast issues

Low contrast makes text difficult to read, especially for users with low vision.

Common problems include light gray labels, faint placeholder text, or error messages that blend into the background.

To fix this:

• Replace light gray text with darker colors.
• Increase the contrast between the text and the background.
• Make error messages stand out clearly from surrounding content.
• Avoid very faint placeholder text inside input fields.

If your form fails contrast requirements, adjust the text or background colors until the contrast is strong enough for comfortable reading. All labels, input text, and error messages should be clearly visible.

Make sure you validate your fixes using a free color contrast checker.

6. Improve error messages and link them properly

Error messages should help users understand what went wrong and how to fix it.

When an error occurs, make sure the message:

• Appears close to the field with the issue.
• Clearly explains what went wrong.
• Tells the user how to fix it.
• Does not rely on color alone to communicate the error.

Avoid vague messages like: “Invalid input.”

Instead, provide clear guidance such as: “Please enter a valid email address.”

Error messages should also be programmatically connected to the field, so screen readers can announce them.

Example:

<label for="email">Email Address</label> 
<input type="email" id="email" aria-describedby="email-error"> 
<span id="email-error">Please enter a valid email address.</span>

After submission, it is also good practice to move focus to the first field with an error so users can correct it quickly.

7. Provide instructions when needed

Some form fields require extra guidance so users know what format to use. This is common for fields like dates, passwords, phone numbers, or account details. Providing clear instructions helps users enter the correct information the first time and prevents errors.

Example:

<label for="dob">Date of Birth</label>
<input type="text" id="dob" aria-describedby="dob-format"> 
<span id="dob-format">MM/DD/YYYY</span>

Here, the instruction “MM/DD/YYYY” tells users the expected format.

To make these instructions accessible:

• The instruction should be visible near the field.
• Do not place the instruction only as placeholder text.
• Programmatically connect the instruction to the input using aria-describedby
• Ensure screen readers announce the instruction when the field receives focus

8. Fix keyboard navigation and tab order

If users cannot move through the form using the Tab key, the structure of the form needs to be fixed.

To fix keyboard navigation issues:

• Use native HTML form elements like <input>, <select>, and <button> since they support keyboard navigation by default.
• Arrange form fields in a logical order in the HTML structure so the tab order follows the visual layout.
• Avoid using elements like <div> or <span> for interactive controls unless keyboard support is added.
• Ensure interactive elements can receive focus (for example, buttons or links).
• Remove any scripts that trap keyboard focus inside a component.

In most cases, keyboard issues happen when forms rely heavily on custom components or when the HTML structure does not match the visual layout.

Fixing the structure usually resolves the problem.

9. Fix invisible focus indicators

Keyboard users rely on the focus indicator to know which field or button they are currently on.

Browsers normally show a visible outline around focused elements. However, some designs remove this outline using CSS, which makes it impossible for keyboard users to track their position.

To fix this:

• Restore the default browser outline if it was removed.
• Or add a clear custom focus style.
• Make sure the focus indicator is easy to see against the background.

Example:

:focus { 
outline: 3px solid #005fcc; 
outline-offset: 2px; 
}

The focus indicator should always be visible when users move through form fields, buttons, and checkboxes using the keyboard.

10. Fix zoom and mobile layout issues

Forms must remain usable when users zoom the page or view it on small screens.

If the layout breaks at 200% zoom or on mobile devices, users may struggle to read labels, reach buttons, or complete the form.

To fix this:

• Stack fields vertically instead of placing too many fields side by side.
• Increase spacing between inputs, labels, and buttons.
• Prevent text overlap between labels, inputs, and error messages.
• Make buttons and checkboxes large enough to tap easily.
• Avoid layouts that cause horizontal scrolling.

If the form breaks when zoomed, update the responsive styles so the layout adapts properly to different screen sizes.

Wrapping Up

Accessible forms are easier to understand, navigate, and complete.

By fixing issues such as unclear labels, poor error messages, broken keyboard navigation, and low contrast text, you remove common barriers that prevent users from submitting forms.

Regularly reviewing and improving your forms helps ensure they remain usable for all users.