WCAG tips: Operable

Guideline 2.1 - Keyboard Accessible

The criteria in this guideline can be summarized into the following topics:

• Make sure all content is operable through a keyboard interface
• Make sure focus can be moved away from any component you can access using a keyboard interface
• For keyboard shortcuts that use only a letter (uppercase and lowercase letters), punctuation, number, or symbol characters, users need to be able to turn the shortcuts off or change the shortcuts.

Guideline 2.2 - Enough Time

Users need enough time to read and use the content. If you have time limits, make sure to check the criteria under this guideline.

Guideline 2.3 - Seizures and Physical Reactions

Avoid content that is known to cause seizures or physical reactions.

2.3.1 Three Flashes or Below Threshold (Level A) and 2.3.2 Three Flashes (Level AAA)

Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

Often the flashing is not a purposeful result of a design (unless you are attempting to create something that is highly annoying). Check animations and hover effects to ensure that flashing isn't a byproduct when an effect doesn't render as intended.

2.3.3 Animation from Interactions (Level AAA)

Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

One of the sufficient techniques for this success criterion is to use the CSS reduce-motion query to prevent motion. I recommend always having this on every website.

Guideline 2.4 - Navigable

Help users navigate, find content and determine where they are at all times.

2.4.3 Focus Order (Level A)

If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

The focus order may not be identical to the programmatically determined reading order (see Success Criterion 1.3.2) as long as the user can still understand and operate the Web page. Since there may be several possible logical reading orders for the content, the focus order may match any of them. However, when the order of a particular presentation differs from the programmatically determined reading order, users of one of these presentations may find it difficult to understand or operate the Web page. Authors should carefully consider all these users as they design their Web pages.

Guideline 2.5 - Input Modalities

Help users operate functionality through various inputs beyond the keyboard.

2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

This success criterion only applies when the element contains text or images of text — it would not apply to an image of an arrow with no text.

WCAG defines an element's label as: "text or other component with a text alternative that is presented to a user to identify a component within Web content." It defines name as: "text by which software can identify a component within Web content to the user". These definitions are almost identical, but there is one important difference: "label" is presented to the user and "name" is presented to software.

For most HTML elements, the WCAG name and label should be the same. For example, if a link has the text of "Apply now" (<a href="application">Apply now<a/>), this text will serve as both the label (what a sighted user sees) and name (what a screen reader user would hear).

However, finding the accessible name is not always straightforward, especially in one of these three scenarios:

1. For images, you must check the alternative text to discover the accessible name.
2. If an element has multiple bits of information competing for the accessible name, you must determine what rises to the top. This is especially common for form controls.
3. If an element uses ARIA labels (aria-label or aria-labelledby), this will override any other contender for an accessible name, sometimes with disastrous results.

Sufficient techniques listed are including the text of the visible label as part of the accessible name and matching the accessible name to the visible label.

If you add more information to the link with an aria-label, you need to have the words of the visible label in the same order they are in the visible text and the wording must be identical. You cannot, for example, have a link text "This is my excellent link text" and then have an aria-label "This is my link text". There are two clear failures for this criterion: 

• Accessible name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text.
• Accessible name contains the visible label text, but one or more other words are interspersed in the label.

So pay attention to this, there are a lot of failures for this around the web. And do remember that add ARIA only if you need it. If the text content is clear enough, you don't need any ARIA.