Skip to content
wcagc
Create account
←Back to blog
ADAfinancial servicesbankingWCAG

ADA compliance for banks and financial services websites

Why the ADA reaches bank, credit union and fintech sites, what the credit union rulings decided, and the online banking flows that fail.

P

Pavel Charkasau

ADA compliance for financial services starts with a word most industries never find in the statute. Title III lists a "bank," an "office of an accountant," and an "insurance office" among the service establishments that count as public accommodations (42 U.S.C. § 12181(7)(F)). The Justice Department's 2022 web guidance names banks again, in its short list of businesses open to the public whose websites it expects to be accessible (ADA.gov).

What the ADA does not give you is a technical standard. DOJ says in the same guidance that it "does not have a regulation setting out detailed standards" for private businesses, and points to WCAG as helpful guidance. So the practical target for a bank, credit union, lender, broker or fintech is WCAG 2.1 AA at a minimum, and WCAG 2.2 AA if you want the criteria that cover sign-in.

The home page is rarely where a financial site fails. The failures sit behind the login: the session timeout, the one-time code field, the transaction table, the statement PDF. That is where this guide spends most of its time.

Does the ADA apply to bank and credit union websites?

Yes, for the reason above. Retailers and restaurants spend years arguing about whether a website is a place of public accommodation. A bank with a branch doesn't get much of that argument, because the statute names the business type directly, and DOJ's position is that its reading of the ADA covers the goods and services a business offers online (ADA.gov).

Online-only lenders and fintech apps are a harder legal question, and I'm an engineer, not a lawyer. I still wouldn't build a compliance plan around the answer. The customers are the same people either way, and the fix is the same code.

One clause matters more in banking than almost anywhere else. Title III covers discrimination "directly, or through contractual, licensing, or other arrangements" (42 U.S.C. § 12182(b)(1)(A)(i)). Very few banks write their own online banking platform, bill pay module or account-opening flow. The vendor's code is still your customer's experience of your bank.

What did the credit union website rulings actually decide?

They decided standing, and nothing else. This is the part of financial-services accessibility that gets misread most often.

Two credit union website cases reached federal appeals courts in 2019. In Griffin v. Department of Labor Federal Credit Union, 912 F.3d 649 (4th Cir. 2019), a blind tester sued over a credit union site with linked images that had no alt text. The credit union only serves Department of Labor employees and their families, and he was not eligible to join. The Fourth Circuit held that a plaintiff legally barred from using a defendant's services had no concrete injury, so no standing (Fourth Circuit opinion). The Seventh Circuit reached the same result on nearly identical facts in Carello v. Aurora Policemen Credit Union, 930 F.3d 830 (7th Cir. 2019), and relied on Griffin to do it (opinion text).

Here is my opinion, stated plainly: those wins taught the wrong lesson to a lot of compliance teams. Neither court said the sites were accessible, or that the ADA asked nothing of them. They said a person who could never become a member couldn't bring that particular case. A member could. So could anyone eligible to join, and at a bank open to the general public, that is everyone. A missing alt on a linked image is a ten-minute fix. Relying on a membership rule to avoid making it is a strange use of legal budget.

What does a financial services settlement require?

The closest thing to a DOJ template for this sector is the 2014 consent decree with H&R Block, which settled claims brought by the National Federation of the Blind, with the United States intervening (consent decree; DOJ press release). Tax preparation is not banking, but the product (people entering financial data into a web application) is close enough to be useful.

The decree required hrblock.com and the online tax product to conform to WCAG 2.0 Level A and AA by 1 January 2015, and the mobile apps by 1 January 2016, for a five-year term. The interesting parts are the operational ones:

  • a web accessibility coordinator reporting to the enterprise CIO;
  • a written web accessibility policy and mandatory training for anyone who writes code for the site;
  • an automated testing tool, plus testing of changes by people with disabilities, including blind and deaf users;
  • an independent consultant evaluating accessibility each year;
  • a conforming way to use any third-party plug-in or content the company integrates.

Read that list as a description of a working program. Automated testing appears in it, and so do humans testing the changes. The decree did not treat a tool as enough on its own. If your bank receives a demand letter instead, we have a calm walkthrough of how to respond to an ADA demand letter.

Which online banking flows fail most often?

The ones that sit behind authentication, because most audits and nearly every free scan stop at the login page. These are the flows I check by hand on a financial site, with the WCAG criterion each one maps to.

Session timeouts. Banks set short timeouts for good security reasons. WCAG 2.2.1 Timing Adjustable (Level A) still requires that the user can turn the limit off, adjust it, or be "warned before time expires and given at least 20 seconds to extend the time limit with a simple action" (W3C). A dialog that appears without moving focus fails in practice, because a screen reader user never hears it. They find out when the transfer form resets.

One-time codes and passwords. Blocking paste in the password field, or making the user retype a six-digit SMS code by hand, fails 3.3.8 Accessible Authentication (Minimum) in WCAG 2.2. The W3C's Understanding document is explicit that "a service that requires manual transcription of a verification code is not compliant" (W3C). Check for onpaste="return false" on the login form. It is still common.

Transfers and payments. WCAG 3.3.4 Error Prevention (Legal, Financial, Data) is one of the few success criteria that names this industry. For pages that cause "legal commitments or financial transactions," the submission has to be reversible, checked for input errors, or confirmed before it is final (W3C). A review screen before "Send $2,500" satisfies it. A one-click transfer does not.

Transaction history. Account activity is almost always a table. Built from divs with no header cells, it fails 1.3.1 Info and Relationships, and a screen reader announces "−48.20" with no date, payee or running balance attached (W3C). Our guide to accessible data tables shows the markup.

Statements and disclosures. Monthly statements, fee schedules and loan disclosures ship as PDFs, often generated by a core-banking system nobody on the web team controls. An untagged PDF has no reading order and no table structure. You can check one quickly with the PDF accessibility checker.

Account opening. Identity verification is usually a third-party widget: document upload, a camera capture, sometimes a CAPTCHA. It is also the flow where an inaccessible step stops someone from becoming a customer at all. Ask the vendor for their conformance report and test the flow yourself, because the § 12182(b)(1)(A)(i) clause above puts it on your side of the line.

None of these shows up on a home-page scan. We wrote about that gap in why homepage scans miss risk, and financial services has a larger version of it than most sectors, since the public site is marketing and the product is behind the login.

Which WCAG version should a financial institution target?

WCAG 2.2 AA. Content that conforms to 2.2 also conforms to 2.1 and 2.0, per the W3C (WCAG 2.2), so you lose nothing against a settlement that names an older version. You gain 3.3.8, which is the criterion online banking fails most visibly. Why no US regulation picks a version for private businesses is covered in does the ADA require WCAG, and our ADA overview explains how that gap gets filled in practice.

Two other standards come up in this sector. Fintech vendors selling to federal agencies are asked about Section 508, which incorporates WCAG 2.0 AA. Banks serving customers in the EU also answer to the European Accessibility Act, which lists consumer banking services in its scope (Directive (EU) 2019/882, Art. 2(2)(d)); our EAA banking guide covers that side.

What should a bank or fintech team do first?

List the flows before you scan anything. Write down every digital path a customer takes to open an account, sign in, check a balance, move money, pay a bill, dispute a charge and download a statement. Include the subdomains. Most teams find a legacy loan-application tool they had forgotten about.

Then scan those paths, including the signed-in ones. wcagc can scan the authenticated area of a site you have verified, using a stored login profile, so the transfer form and activity table get the same checks as the home page. Fix in this order: labels on every form control, paste allowed in every authentication field, keyboard operation through sign-in and transfers, timeout warnings, then table headers. The WCAG checklist lists the criteria in order.

Be honest about what a scanner covers. Deque's study of more than 2,000 audits found automated testing covered about 57% of issues by volume (Deque); counted by WCAG success criteria, the figure is closer to 30%. Our scanner will flag the unlabeled amount field and the low-contrast "Pending" badge. It cannot tell you whether a screen reader user understands that the transfer they just reviewed is going to the wrong account. That needs a person with a screen reader completing a real transfer. Full conformance needs human review, and the results of that review belong in the accessibility statement you publish, which documents your efforts rather than certifying an outcome.

FAQ

Does the ADA apply to bank websites?

Yes. Title III lists a "bank" among public accommodations (42 U.S.C. § 12181(7)(F)), and DOJ's 2022 guidance names banks among businesses whose websites must be accessible (ADA.gov). No federal regulation sets a technical standard, so WCAG 2.1 AA or 2.2 AA is the practical target.

Do credit unions have to make their websites accessible?

Yes. The 2019 Fourth and Seventh Circuit rulings in Griffin and Carello held only that testers ineligible for membership lacked standing to sue. Neither court decided that credit union websites are exempt, and neither case was brought by a member.

What WCAG criterion covers online payments and transfers?

Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data), Level AA. For pages that cause financial transactions, the submission must be reversible, checked for errors, or confirmed by the user before it is final (W3C).

Is blocking paste on a banking login an accessibility problem?

Yes, under WCAG 2.2. Blocking paste in a password or one-time code field fails 3.3.8 Accessible Authentication (Minimum), because it forces users to remember or retype a value instead of using a password manager or copying the code (W3C).

Is the bank responsible if its online banking vendor's platform is inaccessible?

The obligation stays with the bank. Title III covers discrimination "directly, or through contractual, licensing, or other arrangements" (42 U.S.C. § 12182(b)(1)(A)(i)), so a vendor's inaccessible transfer form is still a barrier your customer meets at your bank.

Scan your sign-in, transfer and statement pages to see the exact selectors that fail, then decide what to fix first: scan your site.

Written by Pavel Charkasau, founder of wcagc.com. I read both credit union opinions and the H&R Block decree before writing this, so the holdings and requirements above trace to the published text.

Last updated: September 30, 2026

Sources