What is WCAG?
The Web Content Accessibility Guidelines provide guidance on ensuring that your web content is accessible for people living with disabilities. The World Wide Web Consortium (W3C) released WCAG 1.0 back in 1999, and this version is now obsolete. This was replaced by WCAG 2.0 which is currently adopted and implemented by Australian government websites since the start of the National Transition Strategy in 2010. In 2018 the first update to the WCAG guidelines happened since 2008. Fundamental changes in the mobile space were created next iteration of digital accessibility.The new Understanding WCAG 2.2 (w3.org) will become a W3C recommendation, which will set the new standard on web content accessibility on an international level.
Evalution of WCAG
In 2018, WCAG 2.1 was published. It was backward compatible with WCAG 2.0. WCAG 2.1 added 17 new criteria:
- Level A (minimum accessibility requirement) had 5 new criteria,
- level AA (medium accessibility requirement) had 7 new criteria, and
- level AAA (highest level of compliance )had 5 new criteria.
The number of criteria increased from 61 in WCAG 2.0 to 78 in WCAG 2.1.
What will be new in WCAG 2.2?
WCAG 2.2 is a step towards creating an online space that is inclusive of all different people with all different abilities. Essentially WCAG ensures your content can reach and be engaged with by the widest possible audience. Web Content Accessibility Guidelines (WCAG) 2.2 describes how to make Web content more accessible to people with disabilities. The term “accessibility” encompasses many disabilities, including those affecting the visual, auditory, physical, speech, cognitive, linguistic, learning, and neurological systems.
WCAG 2.2 will add 9 new criteria— 4 new levels A criteria, 4 new level AA criteria, and 2 new level AAA criteria.
Note: In addition to the above new Success Criteria, Focus Visible has been promoted from Level AA to Level A.
- Focus Appearance-(Level AA)
- Focus Appearance-(Minimum) (Level AA)
- Focus Appearance-(Enhanced) (Level AAA)
- Dragging Movements (Level AA)
- Redundant Entry(Level A)
- Target Size-(Minimum) (Level AA)
- Consistent Help (Level A)
- Accessible Authentication (Level AA)
- Accessible Authentication-(No Exception) (Level AAA)
1. Success Criterion 2.4.11 Focus Appearance-(Level AA)
The purpose of this Success Criterion (SC) is to ensure a keyboard focus indicator is clearly visible and discernible. Focus Appearance is closely related to 2.4.7 Focus Visible and 1.4.11 Non-text Contrast.
Example
When buttons receive focus, an outline is displayed within the button (around the text) that contrasts with the button’s background. Read More- Source W3
2. Success Criterion 2.4.12 Focus Not Obscured (Minimum)-(Level AA)
Due to author-created content, a user interface component won’t be completely hidden when receiving keyboard focus. For sighted people with mobility impairments who use a keyboard-like device (e.g., a switch, voice input), knowing the current point of focus is very important. As you progress through a page, other content may hide the focused element. Focused elements should not be hidden when they overlap with other content
Example
A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not hidden by the footer. Read More- Source W3
3. Success Criterion 2.4.13 Focus Not Obscured (Enhanced)
The purpose of this Success Criterion is to ensure that a component with keyboard focus is visible. When a user interface component receives keyboard focus, no part of the focus indicator is hidden by author-created content.
Examples
A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not overlapped by the footer at all. Read More- Source W3
4. Success Criterion 2.5.7 Dragging Movements – (Level AA)
This will be a new criterion under the Operable principle in guideline 2.5.7 under Input Modalities. This guideline focuses on making it easier for users to operate functionality through various inputs beyond the keyboard. All functions that use a dragging motion can also be accessed with a single pointer without the need to drag. There are exceptions, such as when dragging is essential or the user agent determines the functionality.
Examples:
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. Read More- Source W3
5. Success Criterion 3.3.9 Redundant Entry-(Level A)
To reduce cognitive load, SC 3.3.9 prevents users from having to re-enter information that they’ve already entered before (within the same session).The intent of this Success Criterion is to ensure that users can successfully navigate multi-step processes. It reduces cognitive effort where information is asked for more than once during steps in a process. It also reduces the need to recall information provided in a previous step.
Example
A form on an e-commerce website allows the user to confirm that the billing address and delivery address are the same address. Read More- Source W3
6. Success Criterion 2.5.8 Target Size (Minimum)
A downgrade of SC 2.5.5 Target Size (which is Level AAA) makes SC 2.5.8 a AA checkpoint, relaxing the size requirements. As opposed to SC 2.5.5, which requires a minimum pointer-target size of 44×44 CSS pixels, SC 2.58 only requires a target size of 24×24 pixels. Target spacing, on the other hand, allows the target size to be less than 24×24 if the space between the targets is at least 24 pixels.
Example
Three buttons are on-screen and the target area 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, the Success Criterion passes. Read More- Source W3
7. Success Criterion 3.2.6 Consistent Help (Level A)
This will be a new criterion under the Understandable principle in guideline 3.2.6 under Predictable. This guideline describes how to make web pages appear and operate in predictable ways so that users can navigate through pages more freely. This criterion is about help mechanisms on web pages and their location.
Example
Medical appointment scheduling form – When the service a patient is trying to book is not easily findable within the interface, they may need human help. A built-in messaging option (chat client) enables them to quickly interact with a staff person that can help, without requiring them to manage a second interface. Read More- Source W3
8. Success Criterion 3.3.7 Accessible Authentication-(Level AA)
A key objective of WCAG standard 3.3.7 is to assist users with cognitive disabilities in logging in and accessing the content in a simple, secure, and accessible way. Authentication should not rely on cognitive tests, such as memorizing usernames and passwords or using ReCAPTCHA to identify a certain object. If there is more than one step in the authentication process, such as with multi-factor authentication, all steps should comply with this Success Criterion.
Example
A web site does not block paste functionality. The user is able to use a third-party password manager to store credentials, copy them, and paste them directly into a login form. Read More- Source W3
9. Success Criterion 3.3.8 Accessible Authentication (No Exception) – (Level AAA)
The user shouldn’t have to memorize information or spell it correctly. Tests of cognitive ability include these and other tasks. The site should provide an alternative that doesn’t require a cognitive function test in a step or provide a help mechanism if it does. In addition–and this is a key difference between SC 3.3.7 and 3.3.8–authentication by using object recognition or user-provided content (e.g., a pic uploaded by the user) isn’t permitted at this level.
Example
A web site uses a properly marked up username (or email) and password fields as the login authentication (meeting Success Criterion 1.3.5 Input Purpose and Success Criterion 4.1.2: Name, Role, Value). The user’s browser or integrated third-party password manager extension can identify the purpose of the inputs and automatically fill in the username and password. Read More- Source W3
Conclusion
WCAG 2.2 is scheduled for publication in early 2023. As of September 2022, the WCAG 2.2 W3C Candidate Recommendation Snapshot has been approved for publication. WCAG 2.2 Editors’ Draft may include more recent proposed changes that have not yet been approved. Sourc-w3.org/WAI