What to Expect From WCAG 2.2
The Web Content Accessibility Guidelines (WCAG) have been the standard for digital accessibility the world around for two decades. This autumn, the W3C is preparing to publish version 2.2 of WCAG. WCAG 2.2 adds several new success criteria focused on extending requirements for users with low vision, cognitive impairments, and limited fine motor skills.
New Success Criteria
The WCAG 2.2 proposal currently has nine new success criteria. These are still in active development, so it is not guaranteed all of them will make it into the final recommendation. The list of new success criteria, as of the wide review draft of August 11th, is as follows:
- 2.4.11 Focus Appearance (Minimum) (Level AA)
- 2.4.12 Focus Appearance (Enhanced) (Level AAA)
- 2.4.13 Fixed Reference Points (Level A)
- 2.5.7 Dragging (Level AA)
- 2.5.8 Pointer Target Spacing (Level AA)
- 3.2.6 Findable Help (Level A)
- 3.2.7 Hidden Controls (Level AA)
- 3.3.7 Accessible Authentication (Level A)
- 3.3.8 Redundant Entry (Level A
Focus appearance
These two success criteria ensure that sighted users who navigate the web page using a keyboard have a clearly visible “focus indicator” that shows where they are in the page. This goes beyond the existing 2.4.7 visible focus requirement, in that it defines a minimum size of the focus indicator and a minimum contrast. The level AA variant expects a contrast ratio of 3:1. On level AAA the expected contrast ratio increases to 4.5:1.
Fixed Reference Points
This requirement is specifically written for EPUB and other similar publication formats. It requires that things like page numbers and other pagebreak locators are accessible, and stay unchanged when in the same place in the content when a user adjusts the way the page is displayed. This helps people find where pages start and end, even if those pages are laid out differently.
Dragging
Drag and drop actions require a fairly precise motion, and for someone to be able to keep their finger on the button/ screen without accidentally releasing. This can be challenging for some folks with motor disabilities, which is why this new success criterion requires that drag and drop not be the only way that certain actions can be achieved.
Pointer Target Size
Activating a small button on a touch screen is a challenge for many people, but especially for people who struggle with fine motor skills in their hands. This is equally true when using the mouse or some other pointer device. This success criterion sets a minimum distance that two interactive elements can be away from each other to reduce the chance of people accidentally activating the wrong element. This success criterion enhances 2.5.5 Target Size, which was added in WCAG 2.1 at level AAA.
Finding Help
This success criterion makes it easier for users who need help to be able to find it. The criterion requires that if help features (such as contact information or an FAQ) are available somewhere in the website or web app, that this information or a link to it is in the same place on every page.
Hidden Controls
Controls to complete a process, such as submit buttons for a form, or the send button in an e-mail application must be clearly visible. This helps people quickly understand how to complete a task. Some designers will hide buttons to reduce the visual clutter in the page. If this is done with controls to complete an action, visitors may struggle to complete the task at all.
Accessible Authentication
Logging into a website or app can be a struggle. People forget their passwords, and transcribing authentication codes sent to your phone into the page can be prone to error. This success criterion requires that authentication must be possible without such cognitive tests, for instance, by adding a feature for users to have their password reset via their email address.
Redundant Entry
Some forms require that information is input more than once, for example a shipping and billing address. Completing forms can be straining for some users, and so this success criterion requires that such forms include a mechanism to avoid this.
Publication
WCAG 2.2 is expected to be published as an official W3C recommendation by June 2021. As regulators pick up this update, we may slowly start to see this becoming a legal requirement in various countries from 2021 onward.
Deque is planning to make WCAG 2.2 available as an option for our audits as soon as it is available. We also plan to add new rules to axe-core for WCAG 2.2, and new guided tests to axe Beta.
which version of Axe-core is the best for WCAG 2.1 and 2.2 rules? I am building automation framework. How can assure that the given Json result is compatiable with WCAG?