Exploring the Web Content Accessibility Guidelines v2.2: Part 1. Focus

Introduction

The new version of the W3C’s Web Content Accessibility Guidelines (v2.2) was officially published on 5 October 2023.

In a series of blog posts, we will be looking at what is new in this version, and how you may want to change your approach to accessibility – to one that goes beyond your current level of conformance – to ensure your website is actually accessible.

In this first post we are going to look at three new success criteria (SC) in v2.2 that relate to focus:

  • 2.4.11 Focus Not Obscured (Minimum)
  • 2.4.12 Focus Not Obscured (Enhanced)
  • 2.4.13 Focus Appearance

This is how those success criteria appear in the Web Content Accessibility Guidelines v2.2:

2.4.11 Focus Not Obscured (Minimum) – Level AA

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

2.4.12 Focus Not Obscured (Enhanced) – Level AAA

When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.

2.4.13 Focus Appearance – Level AAA

When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:

  • Is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
  • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

Exceptions:

  • The focus indicator is determined by the user agent and cannot be adjusted by the author, or
  • The focus indicator and the indicator’s background color are not modified by the author.

Before we look at these success criteria, let us understand the reasons why we need them.

What is ‘focus’ and why is it important?

Focus is an attribute of an interactive element on a webpage that helps keyboard-only users navigate to and interact with it.

Interactive elements typically include things with which users expect to be able to interact, such as links, buttons and form input fields. Interactive elements are fundamental to being able to navigate websites (using navigation menus, search, and in-page links) as well as allowing users to input or select information in forms. If you are a keyboard-only user – because you cannot or choose not to use a mouse – you will likely navigate webpages by using the tab key to navigate between and to access interactive elements.

Computer mice are pointing devices that allow us to move a cursor to any point on the screen – they are great for accessing information in a non-linear manner. When we navigate using a mouse, not only can we move to any point on the page, we also know where we are clicking, because we control the cursor. Unlike mice, keyboards generally only provide a linear means of navigating a webpage, from the first element at the top of the page to the last element at the bottom, and everything in between, in order.

When navigating by keyboard alone, it is often difficult to know exactly where the focus will jump to. To help keyboard-only users see which interactive element has focus, and where they are on the page, the browser displays a focus indicator. Focus indicators can vary in appearance based on the browser you are using. As an example, when an interactive element receives focus in Google Chrome, a 2-pixel wide, blue ring appears around the interactive element – this is the default focus indicator for this browser.

You can see a focus indicator in action on Bunnyfoot.com. You should see a focus indicator appear around interactive elements (things you would otherwise click on using a mouse) as you press the tab key. Pressing the tab key will move focus to the next interactive element; pressing the shift and tab keys together will move focus to the previous interactive element.

Screenshot of part of the Bunnyfoot website. A link that has a blue ring around it, indicating that the link has focus and can be interacted with

Focus indicators are critical for users who navigate by keyboard alone. Without a visible and clear focus indicator, keyboard-only users will find it very difficult to know where they are on the page, which elements they can interact with, when to be able to activate links and buttons, and how to navigate around the website.

Unfortunately, the usefulness of the focus indicator is often misunderstood by designers and developers many of whom use CSS to suppress what they might feel is an ugly or off-brand annoyance (this is ridiculously easy to do just using “outline: none”), making navigation and interaction practically impossible for many keyboard-only users.

How the Web Content Accessibility Guidelines address focus

The previous version of the Web Content Accessibility Guidelines (v2.1) went some way to highlighting the importance of focus visibility by including 2.4.7 Focus Visible.

2.4.7 Focus Visible – Level AA

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

By including SC 2.4.7, the guidelines are telling us something important – to make sure our focus indicator is visible. In many cases, the simplest approach is for designers and developers not to suppress the focus indicator that the browser displays by default when an element receives focus. So if we have something telling us to make sure the focus indicator is visible, why do we need SC 2.4.11?

Sometimes designers and developers like to stick page elements to the top or bottom of the screen, to make them consistently easy to reach, for example, headers with navigation menus, and footers with tabs or other controls (especially on mobile). The problem with “sticky” navigation is that to keep it in view at all times, the content of the page – where you might have links, buttons and form elements that you interact with, along with text and images – must scroll behind the sticky areas. If you are using the keyboard alone to navigate a page, when you press tab and land on an interactive element, you need to be able to see that element in the “reduced-by-sticky-navigation” viewable area, not for it to be hidden or obscured underneath those sticky areas.

SC 2.4.11 aims to ensure that elements that receive focus are visible by advising that the element “is not entirely hidden” by other things on the webpage (in the example we have been talking about, sticky headers and footers). Where SC 2.4.7 helps to ensure the focus indicator is visible, SC 2.4.11 ensures that the element itself is not entirely hidden.

Taking focus further with level AAA

2.4.12 Focus Not Obscured (Enhanced) is very similar to SC 2.4.11 except that rather than advising that an element that receives focus “is not entirely hidden”, SC 2.4.12 advises that “no part of the component is hidden”, so the whole of the link, button, form element must be visible when you tab to it.

When we understand that SC 2.4.12 says that “no part” of the focused element is hidden, it is easy to understand what “not entirely hidden” in SC 2.4.11 could mean, and the potential for abuse of that success criteria within the realms of conformance. For example, it is possible to conform to SC 2.4.11 with just a tiny part of element visible – even if that is only the top, left-hand pixel of a button, just the underline of a link, or the last pixel of an input field – as SC 2.4.11 only requires the element to be “not entirely hidden“. Clearly, the issue of obscured focus is only robustly addressed in SC 2.4.12.

Screenshot of part of the Bunnyfoot website. Just the underline of a focussed link is visible beneath the navigation menu which is pinned to the top of the page

2.4.13 Focus Appearance addresses issues that have existed with 2.4.7 Focus Visible since the previous version of the Web Content Accessibility Guidelines, namely, there is no definition of “visible”. Focus indicators are bound by 1.4.11 Non-text Contrast – they must have a contrast ratio of at least 3:1 against adjacent colour(s) – however there is no minimum requirement for the size of a focus indicator. By definition, you could conform to SC 2.4.7 with a focus indicator that is just 1 pixel wide by 1 pixel high – practically invisible to most people – spot the focus indicator below…

Screenshot of part of the Bunnyfoot website. The focus indicator has been styled to be 1 pixel wide by 1 pixel high, so is practically invisible

2.4.13 Focus Appearance solves this problem by specifying both minimum dimensions (a 2-pixel wide boundary around the element) and a minimum contrast ratio (3:1 with the element’s unfocused state) for that boundary.

Why the new success criteria might not fix problems with focus

Whilst SC 2.4.12 and SC 2.4.13 solve problems that are not addressed with SC 2.4.11 and SC 2.4.7 respectively, their inclusion in Web Content Accessibility Guidelines v2.2 does not come without additional problems, centred around organisations’ approaches to accessibility and to conformance.

Since September 2018, public sector bodies in the UK have had to comply with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. GOV.UK explicitly states that “Your website or mobile app will meet the legal requirements if you meet the WCAG 2.2 AA accessibility standard”, so it is natural that many organisations might consider level AA conformance as providing an “acceptable” or even “good” level of accessibility.

2.4.7 Focus Visible and 2.4.11 Focus Not Obscured (Minimum) are level AA success criteria, meaning that public sector websites, and those adopting a similar approach to conformance, will want to conform to these SC on the understanding that they would provide a reasonable level of accessibility.

2.4.12 Focus Not Obscured (Enhanced) and 2.4.13 Focus Appearance are level AAA success criteria – many organisations may not consider meeting these success criteria if their commitment to accessibility stops at level AA.

Do not rely on your current approach to conformance for accessibility

For keyboard focus to be truly accessible – and by extension, to be able to provide robust keyboard accessibility – we believe it is important to adhere to the guidance in both the two level AA success criteria AND the two level AAA success criteria, regardless of your current approach to conformance.

If your approach to accessibility is to conform solely to level AA success criteria, we strongly recommend taking focus visibility one step further, also meeting the requirements laid out in 2.4.12 Focus Not Obscured (Enhanced) and 2.4.13 Focus Appearance, and providing a far more accessible experience for your keyboard-only users.

Not sure what to do next or how to do it?

If you want to talk about accessibility with someone who can help – whether you are just getting started, or already on your accessibility journey – please get in touch with us. If you prefer, you can email us or call us on 020 7608 1670. We would love to help you.