Introducing WCAG 2.2

The following are my summaries of each new rule, for those who want more details (but still in an easy-to-read format). If you want to get really wonky, however, a more official explanation is available on a site such as the W3C. 

#1: “Focus Not Obscured”, Minimum (AA)

This rule states that when any user interface component receives keyboard focus, it needs to be at least partially visible. 

What is “focus”, you may ask? Simply put, it’s the component on the web page or app that you’ve currently selected via keyboard. Many people rely on a mouse or trackpad to navigate content. Not everyone can use these devices, however, and need to rely on a keyboard instead. Using the keyboard tab keys, a user can move around the screen, selecting one component at a time. 

Generally speaking, it would be difficult or extremely unlikely to select a hidden component using a mouse, because you wouldn’t see it in the first place, or have trouble selecting it because it was obscured by some other element. But relying on a keyboard, it would easily be possible (using the tab key) to select every component on the screen, including ones that are obscured or completely hidden. That would be a confusing experience for the user, however, for now their “focus” in an area they can’t see.

It might be hard to picture a scenario where this would happen, but it does. For example, an element on the page like a “Sticky Footer” or “chat” widget might be overlaying some other content towards the bottom of the page, obscuring it from view. We want to avoid this experience for our keyboard-based visitors.

#2: Focus Not Obscured, Enhanced (AAA)

This is the same as the previous rule, but under a stricter, level AAA definition. Here the component has to be fully visible when it’s in “focus” (and not just partially visible). 

#3: Focus Appearance (AAA)

This rule requires some kind of visual indicator of the current focus. For example, if a user was shifting the keyboard focus around a web page, the currently “focused” component needs to have some visual indicator, such as a thick border around it (2px wide or higher). The indicator also needs to have a contrast ratio of at least 3:1 between focused and unfocused state. This refers to the color of the indicator, such as a purple border when focused.

#4: Dragging Movements (AA)

Any action that requires a “dragging” movement from the user needs to include an easier alternative. 

For example: Your app requires users to drag items on a screen to reorder the selections (e.g. photos). This is easy enough for some users with a mouse. But there are others with hand/motor issues who can’t use a mouse. For these users, you need to provide a different means for reordering selections, such as the arrow keys. 

#5: Target Size, Minimum (AA)

For any interactive targets, such as a button, you must provide a minimum size to users, or have a good amount of spacing around them for users to “select.”

It’s common to have buttons or other navigation items on a webpage or app that you want users to select as they navigate your content. Not everyone has a precise level of control over their hand movements, however. By making buttons at least 24x24 pixels in size, it is easier for everyone to select them. Spacing around multiple elements is also important to ensure users aren’t accidentally selecting the wrong choice, due to crowding.

There are some exceptions to this rule, such as smaller elements with a wider boundary of space between them, or targets inside a line of text. But the general rule here is to make it easier for any user to select an action on the screen.

#6: Consistent Help (A)

Put any user “help” mechanisms in the same place on every page. The rule defines help mechanisms as “contact details, contact forms, chat forms, and other “self help” options. 

This might feel a little vague, but the way I summarize it is, be consistent with where you place your contact and help options on the screen. This rule applies to all levels of compliance.

#7: Redundant Entry (A)

Don’t ask users to input the same information twice in the same session. This is to help users with cognitive disabilities. 

An example would be an online form, where users are asked to re-type some information they already had filled out in a previous step. There are reasonable exceptions to this rule, of course, such as verifying an email address or password.

#8: Accessible Authentication, Minimum (AA)

Don’t require users to solve cognitive tests (such as image puzzles) or memorize a username and password, in order to login to your website or application. These are considered barriers to users with cognitive disabilities.

Of course these are commonly used tools to keep out spam and make a site secure. So how do you get around using them? One idea I’ve seen in action for years with a tool like Slack is to simply offer a login via verified email address. Input your email address and a message will be sent to your inbox with a link to login. This method is easier for users, as it only requires remembering an email address, but still maintains a level of security for your application.

This rule does allow for the use of some cognitive testing mechanism, as long as they also include one of the following:

• include an alternative method for verifications

• a mechanism to help users complete the test, such as audio version of a word test

• a test that relies on object recognition

• personal content to identify the user, such as an image you selected identify your account

#9: Accessible Authentication, Enhanced (AAA)

Similar to #8, but more restrictive. No cognitive tests (like image puzzles) can be required for any authentication process, unless you also offer an alternative method for logging in, or some other form of assistance in completing the test.