For financial institutions, inaccessible forms can lead to legal exposure, lost conversions, and frustrated users. This guide walks through the key Web Content Accessibility Guidelines (WCAG) standards, common mistakes, and best practices to help you create forms that are compliant, inclusive, and user-friendly.
While the Americans with Disabilities Act (ADA) does not specifically state that websites are included as a “place of public accommodation,” businesses should still be proactive in making their digital services accessible to minimize their legal exposure and risk of financial repercussions. Because the ADA doesn’t outline standards for websites, nearly all rulings and settlements reference the WCAG 2.1 Level AA as the benchmark for compliance.
Banks and credit unions have become frequent targets of accessibility lawsuits:
These cases follow a broader legal trend, where courts have affirmed that online services, including web forms, are subject to ADA compliance.
To meet accessibility standards, your forms need to comply with WCAG 2.1 Level AA. These guidelines ensure that people using screen readers, keyboard navigation, or other assistive tech can access, understand, and submit your forms.
Here are the most important criteria to address:
All form elements: inputs, checkboxes, and dropdowns, must have properly coded labels that assistive technologies can interpret. This ensures screen readers can tell users what each field is asking for.
<label for=”email”>Email Address</label>
<input type=”email” id=”email” name=email” />
It’s been made very clear that the <input> field is asking the user for an email address, and assistive technology knows the <label> is associated with it because the “for” attribute and the “id” attribute say “email” and match each other.
The criterion also applies to submit buttons. Just saying “Submit” is too vague. Saying something like “Submit Application” is better.
Labels must clearly describe what each field is for. Headings should group related fields for better comprehension.
For example: I want to collect a series of personal information from the user: their name and email address. To clearly group these two together, I start with a header.
<h2>Personal Information</h2>
Then, I use clear, descriptive labels to let the user and assistive technology know what information I’m asking for.
<label for="full-name">Full Name</label>
<input type="text" id="full-name" name="full-name" />
<label for="email">Email Address</label>
<input type="email" id="email" name="email" />
If a user makes a mistake, the form must clearly identify which field has the issue and what went wrong.
We start with the basic label and input setup and make it required:
<label for="email">Email Address</label>
<input type="email" id="email" name="email" required />
Then we add the error message that clearly states what went wrong if someone leaves the input blank or doesn’t format their answer as an email address (more on formatting in 3.3.2):
<span id="email-error" class="error-message">Please enter a valid email address.</span>
Now we tie everything together with an aria-describedby attribute that matches the error message’s ID:
<label for="email">Email Address</label>
<input type="email" id="email" name="email" aria-describedby="email-error" required />
<span id="email-error" class="error-message">Please enter a valid email address.</span>
Not only do we have a valid error message, but it’s also next to the field that it’s checking. Moving the message away from the field, either at the top of the form or a popup, removes the visual context of the error message. While technically compliant, it’s not a great user experience.
Instructions, including formatting requirements or character limits, should be visible and clear before the user starts typing.
Common fields that require a certain format are ones that ask for email addresses or phone numbers. We’ll use an email address as an example:
<label for="email">Email Address</label>
<input type="email" id="email" name="email" />
And include messaging that helps the user understand what format we expect them to use:
<label for="email">Email Address</label>
<input type="email" id="email" name="email" aria-describedby=”email-help” />
<small id=”email-help”>Format: [email protected]</small>
When an error is detected, the form should offer helpful suggestions for correction.
<label for="email">Email Address</label>
<input type="email" id="email" name="email" aria-describedby="email-error" required />
<span id="email-error" class="error-message">Please enter a valid email address.</span>
This error message doesn’t just say “Incorrect email”; it tells the user exactly what is expected so they can correct it.
Keep in mind that WCAG 2.1 allows limited error suggestions when being more specific would compromise security, privacy, or fraud prevention. For example:
In those instances, a more generic message is acceptable:
“The username or password is incorrect.”
If a form involves legal or financial commitments (like a loan app), users must be able to review and confirm their entries before final submission. It does not apply to basic contact forms that only ask for name, email, and phone number.
Websites commonly include a review page that allows the user to check for mistakes and go back to make corrections before having the user submit their information.
Form fields must expose their name, role, and current value to assistive technologies. Standard HTML form elements usually meet this requirement by default. The criterion is more for custom HTML builds.
<div role="combobox" aria-haspopup="listbox" aria-expanded="false" aria-labelledby="dropdown-label">
<span id="dropdown-label">Select State</span>
<div role="listbox">
<div role="option">Florida</div>
<div role="option">Georgia</div>
<div role="option">Alabama</div>
</div>
</div>
This example tells screen readers that it’s a dropdown from the role=”combobox”, it contains options with role=”listbox” and role=”option”, and it’s tied to a label with aria-labelledby.
Outside of the form-specific WCAG criteria, there are non-form specific guidelines that need to be followed as well:
If you’re not sure whether your forms are accessible, or you know they’re not and don’t have the resources to fix them, we’ve got you covered. At DiscoverTec, we help financial institutions:
Whether you need a one-time audit or long-term support, we’ll help you meet your accessibility goals. Contact us today to get started.
Published on: September 09, 2025 by Ryan Brooks