What WCAG 2.2 means for bank website accessibility

7/26/23

Website accessibility principles continue to evolve, which means banks and other entities that rely on government-mandated regulations can’t afford to fall behind.

Last year, the Department of Justice (DOJ) weighed in on website accessibility and compliance. Instead of constructing its own rules, the DOJ merely reiterated its stance that websites are, in fact, covered under Titles II and III of the American with Disabilities Act (ADA) and provided a few examples of maintaining accessible website.

In short, the DOJ conveyed the position that websites must accommodate people with disabilities, citing the Web Content Accessibility Guidelines (WCAG) 2.0 and Section 508 Standards, specifically WCAG 2.0 Level AA criteria.

Even then, versions 2.2 and 3.0 of WCAG were already in the works, leaving forward-thinking website agencies (like us) to wonder what those changes will hold — and when/whether the DOJ will tacitly adopt them as well.

But before we dive into the anticipated updates to this set of criteria for best practices of website accessibility, let’s take a moment to review what came before.

Highlights from WCAG 2.1

Even though the DOJ won’t officially commit to a minimum level of compliance for public websites or weigh in how such compliance should be measured, WCAG 2.1 has outlined — and BrownBoots has adopted — the following Level AA requirements for ADA compliance:

• Our bank websites maintain acceptable color contrasts in text.
• Our bank websites provide text cues when using color in text and don’t use color alone to give information.
• Our bank websites use text alternatives (i.e. alt text) to describe images.
• Our bank websites include labels, keyboard access and clear instructions for online forms.
• Our bank websites optimize mouse and keyboard navigation.
• We provide a means for users to report accessibility issues.
• We also recommend the inclusion of captions for embedded videos.

What we expect from WCAG 2.2

To be clear, the WCAG 2.2 update is still in draft form. Changes may occur between now and when editors finalize it, which is expected to happen before the end of September 2023. The good news is 2.2 doesn’t significantly alter earlier guidelines, which means the work we’ve already done remains viable and valuable.

Rather, the new criteria build upon the foundation of earlier versions with nine updates, of which six are required for Level AA compliance. Here’s an overview of the changes that impact Level AA-compliant websites (like ours!). The full details can be found at w3.org.

1. Focusing on one thing shouldn’t obscure another.

Make sure elements that receive keyboard focus are not entirely hidden by other interactable components. This includes popups, sticky footers and other banners.

2. Dragging shouldn’t be a drag.

When dragging is required to perform a function, provide a single-pointer alternative to accomplish it — for example, clicking an up or down arrow instead.

3. Clicking links shouldn’t be a crapshoot.

Make buttons at least 24 by 24 pixels. Barring that, sufficient space should be inserted between them so users don’t unintentionally click/tap the wrong one. (Few things are as frustrating as clicking “Cancel” instead of “Submit,” forcing the user to enter information all over again.)

4.  Getting help shouldn’t be a struggle.

Position help mechanisms, such as contact info, live chat, FAQ elements, and other self-help tools, in the same place, position, and/or order so users don’t have to hunt for them as they navigate from page to page or section to section.

5. Users shouldn’t have to provide the same info twice.

If you’ve already captured user information somewhere, don’t request it a second time. Auto-populated fields and dropdown selections can help mitigate this inconvenience, or let the user select details that have already been collected (e.g. previously used mailing address).

6. Authentication shouldn’t rely solely on memorization.

A cognitive function test, such as remembering a password or solving a puzzle, isn’t a viable login practice for all users, though object recognition tests currently used by CAPTCHAs are still acceptable. Supporting password entry via password managers can satisfy this criterion. When one-time passwords or tokens are needed to authenticate from a separate device, make the codes copy/paste friendly.

Putting it all into practice

As with the earlier guidelines, exceptions abound. Most of the updates acknowledge that going against these principles may be “essential” at times. However, abiding by WCAG 2.2 as closely as possible/practical not only makes website visitors’ experiences better, but also reduces the chances of legal actions based on inclusivity concerns.

We are already evaluating our live bank websites to ensure they adhere to these new criteria as well as building our new sites to conform to the new Level AA compliance requirements.

Because WCAG is a living, evolving set of protocols, we can expect the guidelines to remain in a state of flux for the foreseeable future, rather like the internet itself. Looking ahead, the already-in-the-works WCAG 3 aims to be broader in scope and easier to understand — appropriately, more accessible.

Need an accessibility consultation? We’re happy to help!

Learn more about our ADA-compliant approach to bank websites.