How To Meet WCAG 2.2 — Some Practical Examples

Posted on 10/17/2023

The new version 2.2 of the Web Content Accessibility Guidelines was released recently. It adds 9 new success criteria and removes the old 4.1.1 Parsing criterion.

I won't bore you with another “WCAG 2.2 is finally here!” article. Other accessibility experts with more experience than me have already explained the changes compared to WCAG 2.1 (see the link section at the end). Instead, I'd like to focus on some of the new criteria and give you practical examples of how to meet them.

A woman's face partially hidden behind a book with a green cover. Photo: © George Milton / pexels.com

The New Criteria of WCAG 2.2

Several new criteria aim to improve the operability of websites and apps: Focus indicators should be clearly perceivable and the focused control should not be obscured by other content on the page.

Controls should be large enough so they can be easily activated without accidentally activating an adjacent target. If a site has functionality that uses a dragging movement for operation, then it must offer an alternative way for mouse and keyboard users.

Here's a list of all new success criteria that relate to operability:

The following success criteria aim to improve accessibility for people with cognitive and learning disabilities:

Now let's look at some practical examples for the new success criteria.

Practical Examples

Use Case: Sticky Page Header

Many websites include a header that sticks to the top of the page, even when the page is scrolled. If done right, this sticky header improves the usability of the website. Imagine a user reading a long article: When they arrive at the bottom of the page, they don't have to scroll back up to access the main navigation in the header.

Unfortunately, a sticky header can hurt the experience of sighted people who can't use a mouse. When they navigate a website using the keyboard, they always need to see what has keyboard focus. A sticky header or footer can lead to focused elements disappearing behind these elements.

Lucky for us, there's a simple and elegant solution for this problem: The CSS property scroll-padding enables us to define offsets for the optimal viewing region of the scrollport — the region used as the target region for placing things in view of the user. All you need is one line of CSS:

html {
    scroll-padding: 4rem 0;
}

Here's a demo of a website with a sticky header and footer. Try navigating with the tab key and pay attention to the browser keeping the focused link in view:

This way, the website conforms to 2.4.11 Focus Not Obscured (Minimum) (AA) and 2.4.12 Focus Not Obscured (Enhanced) (AAA).

Another related CSS property is scroll-margin. You can use it to, e.g., un-obscure content underneath a fixed-position banner, as the WCAG technique C43 demonstrates: “Using CSS margin and scroll-margin to un-obscure content”.

Use Case: Interactive Map with Drag to Move

An interactive map usually allows the user to drag the view of the map with the mouse or on touch. But some people cannot perform dragging movements in a precise manner. Or they use a specialized input device, such as a trackball, or head pointer, which may make dragging cumbersome and error-prone.

An accessible map should also include up/down/left/right buttons to move the view, and conform to the success criterion 2.5.7 Dragging Movements (AA). Users with motor impairments can easily tab to the controls and use them to pan the map. Check out my demo of a map with zoom and pan buttons:

Screenshot of an interactive map that has up/down/left/right buttons to move the view. Photo: © Alexander Lehner

As the screenshot above shows, the focused button is clearly highlighted with a thick outline and color change. Continue to the next section to learn more about accessible focus indicators.

Use Case: Clearly Visible Focus Indicators

Providing visible focus indicators is a basic feature of accessible websites and apps. The success criterion 2.4.7 Focus Visible (AA) states:

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

This criterion has been around for almost 15 years, ever since WCAG 2.0 was released. Unfortunately, there's still lots of websites with no or barely visible focus indicators. One of the reasons might be that WCAG never normatively defined what “visible” meant in practice.

The new sucess criterion 2.4.13 Focus Appearance (AAA) finally defines the minimum dimensions and appearance for focus indicators. They should cover enough space and provide a contrast of at least 3:1 between an element's focused and unfocused state.

Often, a client or designer might oppose strong focus indicators for aesthetic reasons. In this case, I recommend the use of the :focus-visible CSS pseudo-class. It lets you show focus styles only when they are needed (e.g., on keyboard navigation). Check out my demo that compares :focus to :focus-visible.

If you want to go into more details, read my post “Provide highly visible Keyboard Focus with :focus-visible”.

Useful Resources