The latest proposed updates to the Web Content Accessibility Guidelines (WCAG) are focused on improving keyboard navigation and providing more than one way to authenticate users. The keyboard navigation additions provide more clarity regarding the best practices for how to make buttons and menu items stand out when a mouse isn’t being used.
User Authentication has been a longstanding and increasing problem for people with disabilities. Most sites rely on a username and password for access, but this can be difficult for people with cognitive disabilities to manage. The new guidelines call for at least one other option to be available that doesn’t require solving puzzles or even correct spelling, while still being safe and secure.
A total of nine additional criteria have been proposed for WCAG 2.2. The first public working draft was released in August 2020 and is still in development, so it is not guaranteed all of the items will make it into the final recommendation. The nine proposed criteria are:
Guideline 2.4 Navigable
2.4.11 Focus Appearance (Minimum) (Level AA)
2.4.12 Focus Appearance (Enhanced) (Level AAA)
2.4.13 Fixed Reference Points (Level A)
Guideline 2.5 Input Modalities
2.5.7 Dragging (Level AA)
2.5.8 Pointer Target Spacing (Level AA)
Guideline 3.2 Predictable
3.2.6 Findable Help (Level A)
3.2.7 Hidden Controls (Level AA)
Guideline 3.3 Input Assistance
3.3.7 Accessible Authentication (Level A)
3.3.8 Redundant Entry (Level A)
A quick look at the drafted changes is included below:
2.4.11 Focus Appearance (Minimum)
The Success Criterion for this item ensures the focus indicator is clearly visible and discernible for sighted users who navigate the web page with a keyboard. It requires that focus indicators have a minimum number of pixels that change color with at least a 3:1 contrast ratio. The focus indicator must also contrast with surrounding colors. The element must not be entirely hidden when it receives focus.
2.4.12 Focus Appearance (Enhanced)
In relation to Focus Visible (enhanced), this criterion:
Expands the minimum area to 2 CSS pixels around the perimeter;
Increases the change of contrast to 4.5:1;
Does not allow for any part of the element to be obscured by other content.
2.4.13 Fixed Reference Points
When page numbering is provided in “electronic publications” users must be able to navigate to each page and the page numbering must remain consistent when the content is modified.
This requirement is specifically written for EPUB and other similar publication formats. This criterion allows people using assistive technology to find references to content based on the page break locators found in the default view or printed version of a publication. For example, an electronic publication (EPUB) document includes navigation to page number references that match the print version of the publication.
2.5.7 Dragging
For functionality that uses a dragging movement (e.g. slider, drag and drop, etc) an alternative way must also be provided to achieve the action.
Since the drag and drop action requires a user to keep their finger on the button/screen to perform an action, some people cannot perform these motions in a precise manner. Some users rely on a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator, which makes dragging cumbersome, error-prone, or outright impossible.
The other aspects of the Success Criterion are the same as Focus Visible (Minimum).
2.5.8 Pointer Target Spacing
This requirement is for targets to be at least 24 by 24 CSS pixels in size, except where:
Spacing: The target offset is at least 24 CSS pixels to every adjacent target;
Inline: The target is in a sentence or block of text;
Essential: A particular presentation of the target is essential to the information being conveyed.
This criterion is to ensure that targets can be easily activated without accidentally activating an adjacent target. When targets are small, it is difficult for users with hand tremors and those who have difficulty with fine motor movement to activate them accurately.
This success criterion enhances 2.5.5 Target Size, which was added in WCAG 2.1 at level AAA.
3.2.6 Findable Help
For each page within a set of web pages that provides one or more of the following ways of finding help, access to at least one form of help is included in the same relative order on each page:
Human contact details;
Human contact mechanism;
Self-help option;
A fully automated contact mechanism.
This criterion was proposed to ensure that users can find help for completing tasks on a website when it is available. Locating the help mechanism in a consistent location across pages makes it easier for users to find it. For example, when a mechanism or link is located in the header of one page, it will be easier to find if it is in the header of other pages.
3.2.7 Hidden Controls
Where receiving pointer hover or keyboard focus causes user interface components to be visible, the information needed to identify that user interface components are available is visible, except when:
The information needed to identify the user interface components is available through an equivalent component that is visible on the same page or on a different step in a multi-step process without requiring pointer hover or keyboard focus;
The component is provided specifically to enhance the experience for keyboard navigation;
A mechanism is available to make the information persistently visible;
Hiding the information needed to identify the component is essential.
This criterion ensures that the 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 design approaches hide controls and require certain user interactions (such as mouseover) to display them. Where the hidden controls are needed to complete tasks, the difficulty in discovering the controls can leave some users with disabilities without a path forward.
3.3.7 Accessible Authentication
For each step in an authentication process that relies on a cognitive function test, at least one other authentication method is available that does not rely on a cognitive function test, or a mechanism is available to assist the user in completing the cognitive function test.
This is to ensure there is an accessible, easy-to-use, and secure method to log in and access the content. Most websites rely on usernames and passwords for logging in. Memorizing a username and password (or transcribing it manually) places a very high or impossible burden upon people with certain cognitive disabilities.
This Success Criterion for this item stipulates that authentication processes do not use cognitive function tests that require memorization, transcription, correct spelling, or completion of calculations or puzzles.
3.3.8 Redundant Entry
Information previously entered by or provided to the user that is required to be entered again in the same process and the same user session is either:
auto-populated, or
available for the user to select.
Except when:
re-entering the information is essential,
the information is required to ensure the security of the content, or
previously entered information is no longer valid.
This criterion is designed to ensure users can successfully navigate multi-step processes, and not be required to re-enter information for subsequent steps in a process. It reduces cognitive effort where information is requested more than once during steps in a process. It also reduces the need to recall information provided in a previous step.
Information that is required to be remembered for input can pose a significant barrier to users with cognitive or memory difficulties.
One Other Expected Change
In WCAG 2.2, success criteria 2.4.7 Focus Visible will change from Level AA to Level A.
A Simple Accessibility Solution
As standards advance, it will be difficult for organizations of all sizes to stay current on accessibility issues. That means a small team of web developers will most likely not be enough to handle this growing responsibility, especially since more lawsuits are being filed every year against organizations that don’t have Americans with Disabilities Act (ADA) compliant websites.
This is one area where AI technology can serve as a “magic bullet.” Instead of requiring countless hours to get compliant (and stay that way), organizations can offload most of this responsibility to reliable, automated solutions like the UserWay Accessibility Widget.
The widget can be installed on any website with just one line of code, and it immediately makes the content meet current WCAG standards. The included AI interprets images to create captions, adds accessible labels to input fields on forms, and deciphers all the links, headings, and site structure to make navigation simple. The widget also includes an overlay that provides options such as text and contrast adjustments, a font for dyslexics, and a screen reader.
Visit UserWay.org to learn more about how our widget and other tools can help your organization meet WCAG and ADA requirements. No matter what the code on your website looks like, UserWay can get it compliant and help you demonstrate your guarantee to making the web more inclusive for everyone.
