Web Content Accessibility Guidelines (WCAG) are essential for making web content accessible to everyone, including individuals with disabilities. WCAG 2.2 introduces updates and new success criteria to build upon WCAG 2.1 AA, aiming to further enhance accessibility. Here’s a straightforward look at the changes and new criteria in WCAG 2.2 compared to WCAG 2.1 AA. Public bodies already need to comply with WCAG2.1aa since September 2018. From October 2024, public bodies operating on a gov.uk domain will need to comply with WCAG2.2.
The foundation of WCAG2.1aa remains and the new standard builds on this. NetWise websites already comply from a technical aspect however it’s important that the person or persons responsible for uploading content are familiar with the standard so that they can remain compliant as they add or update content. Lets run through the technical summary of what is changing and then we’ll look at this in a more easy to understand format below.
Key Additions and Changes in WCAG 2.2
Focus Appearance (Minimum) (2.4.11)
What’s New: Ensures that the keyboard focus indicator is clearly visible when an element is in focus.
Why It Matters: Users who navigate using a keyboard need to see where the focus is to interact effectively with the page.
Focus Appearance (Enhanced) (2.4.12)
What’s New: Builds on the previous criterion by specifying even more visible focus indicators.
Why It Matters: This helps users with low vision by making it even easier to see where the keyboard focus is.
Dragging Movements (2.5.7)
What’s New: Ensures that any functionality requiring dragging can also be operated by a single pointer without dragging.
Why It Matters: Users with motor impairments may find dragging difficult, so providing an alternative makes interfaces more accessible.
Target Size (Minimum) (2.5.8)
What’s New: Requires touch targets (like buttons) to be at least 24 by 24 CSS pixels.
Why It Matters: Larger touch targets are easier for users with motor impairments or those using touch devices to interact with accurately.
Concurrent Input Mechanisms (2.5.9)
What’s New: Ensures that web content does not restrict the use of different input methods (keyboard, mouse, touch) at the same time.
Why It Matters: Users should be able to use their preferred input method without restrictions for better accessibility.
Accessible Authentication (3.3.7)
What’s New: Requires that authentication processes (like logging in) do not rely solely on cognitive functions like memory or solving puzzles.
Why It Matters: Users with cognitive disabilities might struggle with traditional authentication methods. This criterion encourages alternative methods like biometrics or password managers.
Redundant Entry (3.3.9)
What’s New: Ensures that users do not have to re-enter the same information multiple times.
Why It Matters: Repeatedly entering the same information can be frustrating and challenging, especially for users with cognitive or motor impairments.
Summary of Key Differences
Enhanced Focus on Visibility and Usability: WCAG 2.2 introduces criteria to ensure that focus indicators are more visible and touch targets are appropriately sized, improving usability for keyboard and touch device users.
Improved Authentication Methods
The new accessible authentication criterion makes it easier for users with cognitive disabilities to log in by reducing reliance on memory and problem-solving.
Flexibility in Input Methods
By allowing concurrent use of different input mechanisms, WCAG 2.2 ensures that users can choose the most convenient way to interact with content.
Reduction of Redundancy
Ensuring that users don’t have to enter the same information multiple times reduces frustration and cognitive load, making interactions smoother.
Conclusion
WCAG 2.2 builds upon the foundation of WCAG 2.1 AA, introducing new success criteria to address emerging accessibility needs and further improve the user experience for individuals with disabilities. Lets have a look at how these changes affect Councils in the real world.
Putting This Into Practice
Most of the above requirements, in the same way as WCAG2.1aa rely on the way the website is coded. NetWise ensure that your website is already compliant in this regard. There are some considerations to bear in mind however that can be affected by the person responsible for updating the website. Let’s take a look at these.
WCAG2.1aa already requires the following:
- Text transcripts – Images, videos etc require a text alternative or a transcript. This is primarily for users that rely on text readers. A text reader can’t normally understand what content an image contains and so adding a descriptive alt text to the image helps the software relay the information to the user. We cover this in more depth in our accessibility guide. Likewise, video content needs a text transcript.
- Keyboard Accessibility – all aspects of the website should be able to be navigated by a keyboard only. Our websites already offer this functionality without the need for third party plugins.
- Contrast and colour – There should be sufficient contrast between the page background and text. This can be easily checked by using the Webaim Wave test that can be accessed here. Additionally, colour should not be used as an identifier, for example, don’t use instructions such as “click on the green button”.
- Website Structure – Your website should be structured in such a way that people can use the keyboard to tab in a logical way throughout the content. This means that headings H1, H2, H3 and so on should be used for structural purposes rather than for styling content. This allows the user to navigate the website in a logical fashion. Headings shouldn’t be skipped. For example. The page title should be H1, the next heading H2, then H3 and so on. You can revert back to H2 if you’ve used H3 for subtitles and section headings. See below for an example hierarchy.
H1 title
– H2 subtitle
— H3 sub-subtitle
– H2 subtitle
— H3 subtitle
— H4 subtitle
There are exceptions to this rule such as widget headings in sidebars when consistency across pages takes a preference. You can read more about structure here.
WCAG2.2 goes further still and again, the technical considerations are already taken care of by NetWise in the coding of your website. You should however be mindful of the following:
- Embedded content – Social media feeds and weather reports etc may not be compliant and as such you need to take the decision to either remove them, or highlight them in your accessibility statement. We’d advise avoiding them and instead linking out to them rather than embedding the content.
- Content Focus – Don’t use elements that cause the page content to move unexpectedly, such as animations .
- Use meaningful headings and descriptions – This includes page titles, document titles, links and so on. For example. Don’t use “click here” as a link. Instead, use a descriptive link such as “view the village hall calendar”. Name your documents so that they are descriptive such as “Agenda 24th June 2024- Full Council”
You can read a more detailed guide published by gov.uk here – Understanding WCAG2.2
You can also read our more in depth guide to accessibility here Public Sector Accessibility Regulations 2018
