In my first post, I shared perspectives and best practices on how to interact with the web using a keyboard or screen reader. To recap, both of these devices are useful and robust forms of technology that give web users the capability to interact with and navigate to content that would otherwise be inaccessible to them. Now we’ll talk about what’s next, and how the Web Content Accessibility Guidelines 2.2 (WCAG 2.2) will create a more inclusive user experience across devices and software, and browser versions.
Keyboard and Screen Readers – Upcoming Enhancements with WCAG 2.2
The W3C recently released their working draft of (WCAG) by the Accessibility Guidelines Working Group, with key recommendations for making web content more accessible. According to the W3C, users will strongly benefit from these enhanced guidelines:
“Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address the accessibility of Web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.”
For perspective, WCAG 2.2 is built on earlier versions of WCAG 2.1 and 2.0 and those versions are built from the first version (WCAG 1.0) published in May 1999. Now today, WCAG 2.2 continues the practice of improving guidelines through the introduction of additional use-cases. For example, WCAG 2.2 includes improvement in support for users of small or touch-screen devices, as well as low-vision users and users with cognitive, language, and learning impairments.
There are four WCAG 2.2 Guidelines including related Success Criteria which you will eventually want to incorporate into the design and development of your accessible user experiences. For this installment, we’ll focus on “Navigable,” including both Minimum (AA) Level Success Criteria, Enhanced (AAA) Level Success Criteria, and Level (A) Success Criteria. These success criteria affect a variety of Web users from those with motor skill injury to low contrast sensitivity. In short, these navigation-oriented Guidelines help Web users know where they are as they move through a web page.
New Enhancements on the Horizon with WCAG 2.2 – “Navigation”
Navigation is how we interact with web content and components most of the time. WCAG 2.2 includes key updates to an aspect of navigation called “focus appearance”, an essential design choice to help keyboard users navigate through Web pages and other interactive content. When designers overlook focus appearance, then it’s not obvious to keyboard users where they are while tabbing through a web page. From my experience – and talking to other accessible design colleagues – this is a frequently missed design choice. And when it is included both color and visual treatment are inadequate, they lack the attention-getting requirement to draw users to content or user interface components receiving focus.
A Deep Dive into Guideline 2.4 Navigable Success Criteria
Focus Appearance a “AA” (Minimum) Success Criteria 2.4.11 – For keyboard users, always give a clear visual indication of where they are on a web page (aka, “focus order”). To meet these success criteria, a visual indicator must have a color contrast ratio of at least 3:1 to catch a user’s eye. For example, a form field has a visible outline to show what it’s focused on when the keyboard user clicks inside it.
These are the key “focus” considerations to keep in mind:
- Contrasting area: Large enough to be seen (at minimum 1 CSS pixel thick outline).
- Shape: The area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no thinner than 2 CSS pixels.
- Adjacent contrast: The contrasting area also has a contrast ratio of at least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2 CSS pixels.
- Not fully obscured: The item with focus is not entirely hidden by author-created content. In other words, the item that is focused on is not covered up by something else.
Focus Appearance a “AAA” (Enhanced) Success Criteria 2.4.12
This provides ways to help users navigate, find content, and know where they are. This criterion has greater rigor:
- Contrasting area: There is an area of the focus indicator that has a contrast ratio of at least 4.5:1 between the colors in the focused and unfocused states.
- Minimum area: The contrasting area is at least double the area of a 1 CSS pixel perimeter of the unfocused component.
- Not obscured: No part of the focus indicator is hidden by author-created content.
Enhancing Your Web Accessibility with WCAG 2.2
The WCAG 2.2 Guidelines and Success Criteria we’ve covered on “Navigable” are common sense design choices to consider now, especially “AA” (Minimum). For the next installment, we’ll cover additional WCAG 2.2 guidance:
- Success Criteria 2.5 “Input Modalities” (i.e., Dragging Movements and Target Size)
- Success Criteria 3.2 “Predictable” (i.e., Help and Controls)
- Success Criteria 3.3 “Input Assistance” (i.e., Accessible Authentication and Redundant Entry)
To learn more about creating an accessible design strategy for your business, download our guide, Digitally Accessible Experiences: Why It Matters and How to Create Them, and read our UX for Accessible Design series and UpSkills series. To get started on enhancing your digital accessibility, contact our experts about our Accessibility IQ today.
