The Web Content Accessibility Guidelines (WCAG) have seen a significant update with the introduction of WCAG 2.2. This latest version builds upon the foundation of WCAG 2.1, with a particular focus on addressing the needs of individuals with cognitive and learning disabilities, low vision, mobile user experiences, and older individuals facing changing abilities due to ageing.
What is WCAG?
The Web Content Accessibility Guidelines (WCAG) are a set of standards designed to enhance the accessibility of web content for people with disabilities. These guidelines are structured around four key principles:
- Perceivable: Information and user interface components must be presented in a way that users can perceive.
- Operable: User interface components and navigation must be operable and accessible.
- Understandable: Information and the operation of the user interface must be understandable.
- Robust: Content must be robust enough to work with current and future technologies.
You can explore these principles in more detail on the W3C website.
What’s new in WCAG 2.2?
WCAG 2.2 provides 9 additional success criteria from WCAG 2.1. See below to view each criterion, their objective and an example.
2.4.11 Focus Not Obscured (Minimum) (AA): When a user interface component receives keyboard focus, the component MUST NOT be entirely hidden due to author-created content.
Objective: Keep the focused item visible
Example: A notification is implemented as a sticky header and the keyboard focus is moved to the notification so at least part of the focus indicator is in view. The notification disappears when it loses focus so it does not obscure any other controls, and part of the prior keyboard focus indicator is visible.
2.4.12 Focus Not Obscured (Enhanced) (AAA): When a user interface component receives keyboard focus, the focus indicator SHOULD NOT be hidden at all (even partially) by author-created content.
Objective: Do not cover any part of the item with focus
Example: A notification is implemented as a sticky header and the keyboard focus is moved to the notification. The notification disappears when it loses focus, and does not obscure any other controls (including the focus indicator visible prior to the notification).
2.4.13 Focus Appearance (AAA): When the keyboard focus indicator is visible, an area of the focus indicator SHOULD meet specified size and colour contrast requirements.
Objective: Make it easier to spot the keyboard focus
Example: The easiest and most common way to meet this requirement is to use a solid outline around the component. The outline must be at least 2px thick.
2.5.7 Dragging Movements (AA): All functionality that uses a dragging movement for operation MUST BE achievable by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
Objective: Don’t rely on dragging for user actions
Example: A map allows users to drag the view of the map around, and the map has up/down/left/right buttons to move the view as well
2.5.8 Target Size (Minimum) (AA): The size of the target for pointer inputs MUST be at least 24 by 24 CSS pixels (with some allowable exemptions).
Objective: Make controls easier to activate
Example: Three buttons are on-screen and the target size of each button is 24 by 24 CSS pixels. Since the target size itself is 24 by 24 CSS pixels, no additional spacing is required, therefore this passes the Success Criterion.
3.2.6 (Consistent Help) (A): Certain help mechanisms that are repeated on multiple web pages MUST occur in the same relative order to other page content unless a change is initiated by the user.
Objective: Consistently locate user help
Example: On-line job application: Some of the application questions may be hard for new job seekers to understand even after reading the contextual help. For example, the form may request their identification number, but they may have several and not know which one to enter. Consistently located contact information will enable them to use phone or email so they can get an answer to their question.
3.3.7 Redundant Entry (A): Information previously entered by or provided to the user that is required to be entered again in the same process MUST be either auto-populated or available for the user to select, with several allowable exceptions.
Objective: Stop users having to enter the same information twice
Example: A form on an e-commerce website allows the user to confirm that the billing address and delivery address are the same address
3.3.8 Accessible Authentication (Minimum) (AA): A cognitive function test MUST NOT be required for any step in an authentication process, unless specified criteria are met.
Objective: Make logins possible with less mental effort
Example: A website does not block paste functionality. The user can use a third-party password manager to store credentials, copy them, and paste them directly into a login form.
3.3.9 Accessible Authentication (Enhanced) (AAA): A cognitive function test SHOULD NOT be required for any step in an authentication process unless there is an alternative method without a required cognitive test or there is a mechanism to assist the user.
Objective: Make logins possible with less mental effort
Example: A website that requires two-factor authentication displays a QR code which can be scanned by an app on a user's device to confirm identity.
What does this mean for councils?
Currently, all local authorities are required to conform to the WCAG 2.1 AA standard. However, upcoming legislative changes mean that WCAG 2.2 AA will become the new standard for public sector websites and mobile apps. While GOV.UK initially mentioned monitoring for WCAG 2.2 criteria in early 2024, this timeline may be subject to changes due to the publication of the new standard.
Councils can gain an advantage by proactively addressing the upcoming changes in WCAG 2.2. This approach not only reduces the stress of last-minute compliance but also enhances web content usability for all users.
Webcurl – Your Accessibility Partner
At Webcurl, we are deeply committed to ensuring that our public sector clients' online presence is accessible to everyone. Accessibility is at the core of our services. We proudly offer LocalGov Drupal, a content management system aligned with WCAG guidelines. Additionally, we provide innovative solutions such as Webcurl Voice Assistant Search (V.A.S) designed to enhance your council's web accessibility and user experience.
If you have any questions or wish to discuss your accessibility goals with our experts, please don't hesitate to contact us. We're here to help you create an inclusive online platform for your community.