Introducing WCAG 2.2
In October 2023, new accessibility guidelines were released.
In technical terms, an updated version of WCAG was released (2.2). While not a major update, this version upgrade does contain several new and updated guidelines to follow. Let’s review what’s changed.
The Web Content Accessibility Guidelines (WCAG) are a detailed set of rules and recommendations to follow for making web-based content more accessible to people with disabilities.
First introduced in 1999, WCAG has become the industry standard for measuring online accessibility. Using a variety of free and paid automated tools, anyone can test their online content (web pages, PDFs, videos, etc.) against WCAG standards. Reports detail where their content is failing to meet accessible guidelines, such as a proper level of color contrast, and offer recommendations to fix issues.
WCAG 2.2 added nine new rules to follow for accessible web content, depending on the level of compliance you are following–A, AA, or AAA.
If you’re not familiar with these levels or what they mean, consider them as "good, better, best" type rules. Most of our projects target the middle level of compliance (AA)–not the easiest, nor the strictest.
Each new rule is unique, but could be summed up as:
- Keep all content visible (when in "focus")
- Make it easier for users to select or click on target areas, such as buttons
- Have a consistent location for help text and contact info
- Offer alternatives to interfaces that require users to manually "drag" items on the page
- Offer alternatives to puzzles and other visual challenges when logging in to a page or application
If you are responsible for a website or application, have your team review the new standards to ensure compliance (or hire an agency like Electric Citizen). And if you'd like a longer summary of each new rule, read on!
Running regular accessibility audits is a best practice, regardless of how you maintain your site
The following are my summaries of each new rule, for those who want more details (but still in an easy-to-read format). If you want to get really wonky, however, a more official explanation is available on a site such as the W3C.
#1: “Focus Not Obscured”, Minimum (AA)
This rule states that when any user interface component receives keyboard focus, it needs to be at least partially visible.
What is “focus”, you may ask? Simply put, it’s the component on the web page or app that you’ve currently selected via keyboard. Many people rely on a mouse or trackpad to navigate content. Not everyone can use these devices, however, and need to rely on a keyboard instead. Using the keyboard tab keys, a user can move around the screen, selecting one component at a time.
Generally speaking, it would be difficult or extremely unlikely to select a hidden component using a mouse, because you wouldn’t see it in the first place, or have trouble selecting it because it was obscured by some other element. But relying on a keyboard, it would easily be possible (using the tab key) to select every component on the screen, including ones that are obscured or completely hidden. That would be a confusing experience for the user, however, for now their “focus” in an area they can’t see.
It might be hard to picture a scenario where this would happen, but it does. For example, an element on the page like a “Sticky Footer” or “chat” widget might be overlaying some other content towards the bottom of the page, obscuring it from view. We want to avoid this experience for our keyboard-based visitors.
#2: Focus Not Obscured, Enhanced (AAA)
This is the same as the previous rule, but under a stricter, level AAA definition. Here the component has to be fully visible when it’s in “focus” (and not just partially visible).
#3: Focus Appearance (AAA)
This rule requires some kind of visual indicator of the current focus. For example, if a user was shifting the keyboard focus around a web page, the currently “focused” component needs to have some visual indicator, such as a thick border around it (2px wide or higher). The indicator also needs to have a contrast ratio of at least 3:1 between focused and unfocused state. This refers to the color of the indicator, such as a purple border when focused.
#4: Dragging Movements (AA)
Any action that requires a “dragging” movement from the user needs to include an easier alternative.
For example: Your app requires users to drag items on a screen to reorder the selections (e.g. photos). This is easy enough for some users with a mouse. But there are others with hand/motor issues who can’t use a mouse. For these users, you need to provide a different means for reordering selections, such as the arrow keys.
#5: Target Size, Minimum (AA)
For any interactive targets, such as a button, you must provide a minimum size to users, or have a good amount of spacing around them for users to “select.”
It’s common to have buttons or other navigation items on a webpage or app that you want users to select as they navigate your content. Not everyone has a precise level of control over their hand movements, however. By making buttons at least 24x24 pixels in size, it is easier for everyone to select them. Spacing around multiple elements is also important to ensure users aren’t accidentally selecting the wrong choice, due to crowding.
There are some exceptions to this rule, such as smaller elements with a wider boundary of space between them, or targets inside a line of text. But the general rule here is to make it easier for any user to select an action on the screen.
#6: Consistent Help (A)
Put any user “help” mechanisms in the same place on every page. The rule defines help mechanisms as “contact details, contact forms, chat forms, and other “self help” options.
This might feel a little vague, but the way I summarize it is, be consistent with where you place your contact and help options on the screen. This rule applies to all levels of compliance.
#7: Redundant Entry (A)
Don’t ask users to input the same information twice in the same session. This is to help users with cognitive disabilities.
An example would be an online form, where users are asked to re-type some information they already had filled out in a previous step. There are reasonable exceptions to this rule, of course, such as verifying an email address or password.
#8: Accessible Authentication, Minimum (AA)
Don’t require users to solve cognitive tests (such as image puzzles) or memorize a username and password, in order to login to your website or application. These are considered barriers to users with cognitive disabilities.
Of course these are commonly used tools to keep out spam and make a site secure. So how do you get around using them? One idea I’ve seen in action for years with a tool like Slack is to simply offer a login via verified email address. Input your email address and a message will be sent to your inbox with a link to login. This method is easier for users, as it only requires remembering an email address, but still maintains a level of security for your application.
This rule does allow for the use of some cognitive testing mechanism, as long as they also include one of the following:
include an alternative method for verifications
a mechanism to help users complete the test, such as audio version of a word test
a test that relies on object recognition
personal content to identify the user, such as an image you selected identify your account
#9: Accessible Authentication, Enhanced (AAA)
Similar to #8, but more restrictive. No cognitive tests (like image puzzles) can be required for any authentication process, unless you also offer an alternative method for logging in, or some other form of assistance in completing the test.
When the rules change, it’s important to review your current website or app for accessibility compliance. If you have an automated accessibility crawler, like DubBot or Site Improve, you may already have received warnings about where you need to make updates. If you don’t, however, now is a good time to audit your site against WCAG 2.2.
Using a free tool like WAVE, aXE or Lighthouse, you can scan your online content against the new criteria, and note where you need to make updates. If you work with an agency like Electric Citizen (or would like to), you can use your support hours to schedule an accessibility audit. We’ll make note of any violations and take steps to fix whatever needs fixing.
Running regular audits is a best practice, regardless of how you maintain your site.