User interface components and navigation must be operable. - WCAG2.2

Guideline 2.4 - Navigable

Provide ways to help users navigate, find content, and determine where they are. - WCAG2.2

Success Criterion 2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

There should be more than one way to navigate to a page on a site.

WCAG suggests using two or more of the following techniques:

• providing links to navigate to related pages
• providing a table of contents
• providing a site map
• providing a search function
• providing a list of links to all other webpages
• linking to all of the pages on the site from the homepage.

In practice, this success criterion is implemented by providing links to the most common pages in the header and footer, a site map and/or search, and using links throughout the site.

Success Criterion 2.4.6 - Headings and Labels

Headings and labels describe the topic or purpose.

To comply with this success criterion, provide descriptive headings and labels.

Descriptive headings identify sections of the content in relation both to the Web page as a whole and to other sections of the same Web page. For instance, this same document has descriptive headings. If we were to change the heading here to "Another success criterion", it would be much less descriptive. If we were to change it to "Reflow" or "Donuts", it would lose meaning.

Descriptive labels make a component's purpose clear. For instance, a "Zoom in" label for a button to zoom in on a map is a descriptive label, while the label "Plus" might not be.

Success Criterion 2.4.7 - Focus Visible

Any keyboard-operable user interface has a mode of operation where the keyboard focus indicator is visible.

To comply with this success criterion, you can use one of the following techniques:

• use CSS to change the presentation of a UI component when it receives focus

input:focus {
 border: 2px solid blue;
}

• use the default focus indicator for the platform so that high visibility default focus indicators will carry over

To use this technique, don't override default browser styles for focus states, such as outline rules.

You can fail this success criterion if you:

• use a script to remove the focus when focus is received
  • we've discussed this failure state in Success Criterion 2.1.1 - Keyboard
• remove or hide the visual focus indicator

// A very bad CSS reset.
* {
 outline: none;
 border: none;
}

Find out more techniques and failures for this success criterion

Success Criterion 2.4.11 - Focus Not Obscured (Minimum)

To keep the focused item visible, we need to ensure that when an item gets keyboard focus, it is at least partially visible. This way people who can't use a mouse can see what element the keyboard focus is on.

This criterion allows some leeway, realising the complexity of modern responsive design, so at least partial focus is required to meet it. It still encourages more thought on avoiding obstructive elements in the design. Next step is a AAA level rule 2.4.12 - Focus Not Obscured (Enhanced), which requires that the focused element is fully visible.

Overlapping content, such as footers, sticky headers, sliding sidebars, and other non-modal dialogs, often obscure keyboard focus. We can ensure that elements are visible by using modal dialogs (with trapping focus), adding scroll padding, or allowing notifications to close automatically when losing focus.

This criterion also delves deeper on user-movable content and user-opened persistent content (dropdown menus, toolbars, chat windows, etc.) If a persistent sidebar is opened and is blocking keyboard focus, we need to ensure that it can be easily collapsed or dismissed, or the content is correctly repositioned. This criterion also reaffirms that dropdowns (non-persistent elements) should be collapsed when focus moves away.

When checking this criterion, make sure to pay attention to sticky footers and headers. If they are big enough, they can often obscure elements that are located towards the top or the bottom of the page. Situations like these can be resolved using scroll-padding, creating space around scrollable content, to ensure that focused elements remain visible within the viewport. You can read more about this in the documentation about Sufficient Technique C43: Using CSS scroll-padding to un-obscure content.

Guideline 2.5 - Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard. - WCAG2.2

Success Criterion 2.5.7 - Dragging Movements

For any action that involves dragging, we should provide a simple pointer flow or other alternatives. Since some people cannot use a mouse to drag an item, we shouldn't rely solely on a dragging action.

Since dragging involves multiple actions, it can be challenging, or even impossible for some users. We must provide alternative methods to these flows. One example of this is to provide numerical input fields to assign the order of elements.

The alternative doesn't need to be incorporated into the original component. An example of that would be a color field that requires the user to drag the selection indicator around the component. Having a text input next to this component where the user can input a color hex code would ensure that the color selection flow is accessible.

A common component that relies on dragging action is a drag-and-drop sortable list. There we can provide a functionality tied to navigation keyboard keys (up arrow/down arrow) to move the focused option to different positions within the list.

Success Criterion 2.5.8 - Target Size (Minimum)

This criterion focused on making controls easier to activate for people with physical impairments who cannot click small buttons that are close together. We need to ensure targets meet a minimum size or have sufficient spacing around them.

The element size defined as sufficient is 24x24 pixels, but there are five exceptions to this rule: - Even smaller targets can pass this criterion if they have at least 24px of spacing around them. There should be no overlap of elements. - Smaller targets are allowed if the same function has an alternative method to activate it. - Links inside blocks of text are exempt to prevent layout issues. - If the size is determined by the browser, the requirement does not apply (ex. default calendar picker design). - If resizing elements changes their meaning, the elements are exempt from this criterion. An example is a pin on the map, that is pointing to a precise position. If there are many pins on the map on a given zoom level, these pins will commonly overlap with each other. If we would ensure this criterion on this flow, the intended context of these pins would be discarded, so this criterion does not apply here.

More examples and visual aids regarding the spacing are provided in Understanding SC 2.5.8: Target Size (Minimum) (Level AA).