The state of bank and financial website accessibility, 2026

Of the 59 bank and financial homepages we tested, the homepage alone showed:

• 69% had at least one serious accessibility failure (a critical or serious WCAG issue), just over two in three.
• 34% had at least one critical issue: about a third, and the kind that can hard-block a screen-reader user.
• Only 8%, about one in twelve, passed every automated check.
• The median site had 7 detectable issues on its homepage; the worst had 127.

Automated scans only see detectable failures, so the true figure is higher. The sample is a hand-picked set of large banks, brokerages, card networks, and fintechs, which is not the whole industry.

The rate matters less than who it belongs to. Financial services is consistently among the most-targeted sectors in US website-accessibility lawsuits, alongside retail, so a failure on a bank homepage is a barrier in the sector most likely to get a demand letter over it.

Against the other sectors we have scanned, banks landed in the middle. A critical issue appeared on 34% of homepages, close to hospitals (35%), well above government (18%), and below online stores (49%). The median financial homepage had 7 detectable issues, similar to hospitals and government and far below the 17 we saw on stores. The money and the legal exposure bought a middling result.

Ranked by the share of tested sites affected, the recurring WCAG problems were:

• Colour contrast (32%) — text that does not meet the 4.5:1 ratio, WCAG 1.4.3. The most common WCAG failure here, as in every sector, and our figure includes text on CSS gradients that most scanners skip.
• Images missing alt text (19%) — WCAG 1.1.1. This ran higher on financial sites than on government or hospital ones. Bank homepages lean heavily on promotional hero imagery and product tiles, which is where alt text tends to get dropped.
• Buttons with no accessible name (14%) — usually icon-only buttons, WCAG 4.1.2.
• Touch target size (12%) — controls smaller than the 24×24px minimum, WCAG 2.5.8.
• Links with no discernible text (12%) — usually icon-only links, WCAG 2.4.4 / 4.1.2.

Structural best-practice issues were more widespread than any single WCAG failure: content not contained in landmarks showed up on 54% of sites and out-of-order headings on 37%. Those are advisory rather than WCAG success-criterion failures, so we have kept them separate from the figures above.

One finding here is about what we could not measure. Of the financial sites we tried, roughly a quarter returned a bot-protection block, a redirect loop, or a protocol error instead of their homepage, the highest rate of any sector in this series. That is a rational security posture for a bank. The side effect is that the same walls that keep bots out also make a site harder to audit from outside, and they do nothing for the accessibility of the page a real user eventually reaches.

We report only the sites that returned a real homepage. If the locked-out sites are no better or worse than the rest, the figures above hold; we simply cannot see them.

The median financial site had 2 items flagged as "needs human review", cases an automated test cannot decide, like whether alt text is accurate or whether a custom account-opening form works from the keyboard.

Automated testing covers only the machine-checkable part of WCAG, which independent research puts at roughly a third of the success criteria, so these rates understate the real barriers. On bank sites the hardest parts to get right (multi-step applications and logged-in account flows) sit behind the homepage, where an anonymous scan cannot reach.

We are not accusing any institution of breaking the law, and we name none; an automated failure is not a legal compliance verdict. Still, in the sector with the clearest financial and legal reason to get accessibility right, a serious homepage failure is the common case. Most of those failures are ordinary front-end work: contrast, alt text on promotional imagery, button and link names.

If you run a financial site, start with the free scan on your public pages, then add the CLI and GitHub Action to your pipeline so a release cannot quietly bring them back.

• Sample: homepages of 59 US bank, brokerage, card-network, and fintech sites, scanned in July 2026. We attempted 78; 19 were excluded because they returned bot-protection blocks, redirect loops, or protocol errors rather than a real homepage, the highest exclusion rate in this series, which is itself discussed above. This is a curated sample of recognisable financial brands, not a random or asset-ranked one, so read it as a snapshot of major financial sites rather than a census.
• Engine: the axe-core rules for WCAG 2.x Level A and AA, plus our own resolution of colour contrast over CSS gradients. The same engine and settings we used for the other reports, so all four are directly comparable.
• Scope: public homepages only. Account opening, online banking, and transfer flows sit behind login and often fare worse; they are out of reach of an anonymous scan.
• As loaded: pages were scanned as they rendered, including any cookie or consent overlays, which can both add and mask issues.
• Not a compliance audit: detectable WCAG failures are not a legal determination, and automated testing does not cover the criteria that need a human. We have reported aggregate figures only and named no individual institution.