The problem hiding in plain sight
A member using a screen reader visits your website to compare share certificate rates. Your rate table looks clean on screen: three columns, five rows, clearly labeled. But what the screen reader announces is a string of disconnected numbers with no context. "4.75. 12. 500." The member has no idea what those figures mean or how they relate to each other. They leave, and you never know why.
This is not a hypothetical. Rate tables are among the most common accessibility failures on credit union websites, and they are also among the most consequential. Rates are often the primary reason a prospective member lands on your site. If that information is inaccessible to someone using assistive technology, you have not just created a compliance risk. You have turned away a potential member before they ever filled out an application.
Why rate tables fail assistive technology users
The core issue is that most rate tables are built for visual scanning, not for linear reading. Sighted users can glance across a row and understand that a 12-month certificate at $500 minimum earns 4.75% APY. A screen reader moves through the table cell by cell, left to right, top to bottom. Without proper HTML markup, it has no way to communicate which column header belongs to which data cell.
WCAG 2.2 Success Criterion 1.3.1 (Info and Relationships) requires that information conveyed through visual formatting also be available through the underlying structure of the page. For tables, that means using the <th> element with a scope attribute to explicitly associate headers with their rows or columns. A table built entirely from <td> cells, or worse, a table faked with CSS and <div> elements, gives a screen reader nothing to work with.
A few specific failures show up repeatedly in credit union rate tables:
- Missing or misused scope attributes. A
<th>element withoutscope="col"orscope="row"does not reliably associate with its data cells across all screen reader and browser combinations. - Merged cells without proper markup. A header that spans multiple columns needs a
colspanattribute and, in complex tables, explicitidandheadersattributes on the data cells below it. - Rate tables built as images. A screenshot of a rate sheet dropped into a page as a JPEG has zero accessibility. Even a well-written
altattribute cannot convey a multi-row table in a useful way. - No caption or summary. A
<caption>element gives screen reader users immediate context about what table they are entering, before they hear a single data cell.
The regulatory context you should understand
The Americans with Disabilities Act does not include a specific website standard by name, but federal courts have consistently found that websites operated by financial institutions are places of public accommodation subject to Title III. The Department of Justice has pointed to WCAG 2.1 Level AA as the benchmark in its rulemaking guidance for state and local governments, and that standard carries practical weight for private entities as well. WCAG 2.2, released in October 2023, is largely backward compatible with 2.1 AA and adds several new criteria, none of which weaken the table requirements that already existed.
Litigation in the financial sector has accelerated. Plaintiffs' firms have developed efficient workflows for identifying accessibility violations, and credit unions are not too small to be targeted. A $200M credit union in a major metro area is just as reachable as a regional bank. The cost of defending a demand letter, even one that settles quickly, typically exceeds the cost of fixing the underlying issues. Your compliance team and legal counsel should be aware of your current exposure, particularly if your website has not had a formal accessibility audit in the past 18 months.
NCUA has not issued a specific rule on website accessibility as of this writing, but examiners have raised digital accessibility as part of broader fair access and member service reviews. That is worth noting when you are making the internal case for budget or vendor action.
What good looks like, and how to check yours
A properly marked-up rate table is not complicated to build. The HTML structure should use <table>, <thead>, <tbody>, and <caption> elements. Column headers should carry scope="col". Row headers, if present, should carry scope="row". The visual design can still be clean and on-brand. Accessibility and good design are not in conflict here.
You do not need to hire an accessibility consultant to do a first pass on your own site. Free tools like WAVE (from WebAIM) and the axe browser extension will flag missing table headers and other structural issues in minutes. Run them on your rate pages specifically. If you see errors related to missing header associations or empty table headers, those are the issues to prioritize.
If your website is managed by a vendor, including us, you have standing to ask specific questions. Ask whether your current rate table markup passes WCAG 2.2 AA Success Criterion 1.3.1. Ask how rate tables are generated: are they hand-coded, pulled from a CMS component, or output by a third-party rate feed? Each of those paths has different accessibility implications and different remediation paths.
Your next step this week
Open the WAVE tool (wave.webaim.org) in your browser and run it against your share certificate or loan rate page right now. Look specifically for any errors flagged under "Structural Elements" related to tables. Screenshot the results and share them with whoever manages your website, whether that is an internal team member, your CMS vendor, or your web agency. Ask for a written response on what it would take to bring those tables into WCAG 2.2 AA compliance. That single conversation, grounded in actual findings from your own site, is more productive than any general accessibility discussion you could schedule.