Operable
We should design web content to ensure that interface forms, controls, and navigation are functional for all users, regardless of ability.
People access content in different ways. For example, people with physical disabilities, which may prevent them from using a mouse, may opt to use alternative input methods such as a keyboard, or voice recognition, instead of a mouse or trackpad.
Guideline 2.1 – Keyboard Accessible
Ensure all features and functions of a website or digital service can be accessed and used solely through keyboard navigation without relying on a mouse or other pointing device.
2.1.1 – Keyboard
It's crucial to ensure that all functionality can be accessed without a mouse, as some users may rely solely on keyboard navigation. To make your website keyboard accessible, check the following elements:
- Forms
- Submission buttons
- Action buttons
- Navigation menus and submenus
- Sidebar content
- Embedded content
- Audio and video players
By implementing keyboard accessibility, you will improve usability for users with physical disabilities and also those who prefer using keyboard shortcuts for efficiency.
2.1.2 – No Keyboard Trap
It's essential to ensure that users can navigate all parts of the site without a mouse, which means users should be able to move away from any element using only the keyboard.
However, in some cases, the functionality may require users to stay within a specific section of the content, such as modals. Provide clear instructions to help users to exit this state and shift their focus to other areas, especially when using modal windows or other restricted content.
2.1.4 – Character Key Shortcuts
Avoid keyboard shortcuts unless you can thoroughly test them with a diverse range of devices, platforms, and assistive technologies – Ensuring no unintended conflicts arise.
If you do decide to use a keyboard shortcut, it should meet at least one of the following conditions:
- It is possible to switch off the shortcut.
- Allow remapping the shortcut to include one or more non-printable keyboard keys (e.g. Ctrl, Alt).
- It is only active when the component has focus.
Guideline 2.2 – Enough Time
Ensure users have enough time to read and understand the content and complete any actions they need to take without feeling rushed or hurried.
2.2.1 – Adjustable Time Limit
A website must provide at least one of the following options when implementing any time limits:
- Allow the user to turn off the time limit before encountering it.
- Allow the user to adjust the time limit before encountering it to a range at least ten times the length of the default setting.
- Warn the user before the time expires and provide at least 20 seconds to extend the time limit with a simple action (such as pressing the space bar) and allow the user to extend the time limit at least ten times.
Exceptions to time limits include the following:
- Real-time Exception: If the time limit is an essential component of a real-time event, such as an auction, where there is no alternative to a time limit.
- Essential Exception: If the time limit is part of an activity, and extending the time limit would render the activity invalid, the time limit may be necessary.
- 20-Hour Exception: If the time limit is longer than 20 hours, it may be exempt from the guidelines on time limits.
2.2.2 – Pause, Stop, Hide
Flashing content can cause seizures or other adverse reactions in some users, while auto-updating content can distract users and interfere with their ability to read other content on the page.
All moving, blinking, scrolling or auto-updating content which begins automatically, persists for more than five seconds and is presented simultaneously with other content must provide users with the option to pause, stop, or hide it unless it is an essential part of an activity.
Auto-updating content should also allow the user to control the update frequency, for instance, a live Twitter feed.
Guideline 2.3 – Seizures and Physical Reactions
Your content should not trigger seizures or physical reactions that could be harmful. Be mindful of flashing lights, moving patterns, or colour changes that could cause problems for people with medical conditions such as epilepsy or migraines.
2.3.1 – Three Flashes or Below Threshold
To avoid causing seizures or distractions, ensure nothing on your website or application flashes or blinks more than three times in one second.
Note that blinking may be classified as flashing if it occurs at a frequency faster than three times per second.
Guideline 2.4 – Navigable
Your website should be easy to navigate for all users. Users should be able to locate specific content, identify their current location, and understand their position within a website. Provide features such as clear and consistent navigation menus, search functions, and descriptive page titles to help users move around.
2.4.1 – Bypass Blocks
To aid users in quickly accessing the main content of your website, add a "skip-to-content" link in the top left corner. Allows users to bypass the header, which often features site-wide branding and navigation.
The link doesn't need to be visible until it receives keyboard focus, but ensure it's the first focusable element on the page.
Linking "skip-to-content" to the primary heading on the page, rather than its containing block, is considered a best practice. The reasoning is the containing block may have interactive elements which could potentially cause focus-related issues.
<a class="skip-to-content" href="#h1">Skip to content</a>
…
<h1 id="h1" tabindex="-1">Main content heading</h1>
.skip-to-content {
left: 0.5rem;
padding: 0.5rem 1rem;
position: absolute;
transform: translate3d(0, -5rem, 0);
transition: 0.3s ease-out;
transition-property: transform;
z-index: 10;
}
.skip-to-content:focus {
transform: translate3d(0, 0, 0);
}
@media print {
.skip-to-content {
display: none;
}
}
2.4.2 – Page Titled
Ensure your website's page titles are unique and descriptive, accurately describing the page's content or purpose.
Prioritize the most important keywords at the beginning of the title. This practice helps users and search engines quickly identify the page's topic.
<title>Page title – section name – company name</title>2.4.3 – Focus Order
Ensure the tab order of your web page content follows a logical flow when users navigate using the keyboard.
2.4.4 – Link Purpose (In Context)
Make your links user-friendly via descriptive and meaningful text which accurately describes the linked page content.
Avoid long URLs or generic or ambiguous phrases like “click here” or “more info”, and opt for concise, clear language that gives users a clear idea of what to expect.
Image link alt text should describe the linked page content, not just the image itself.
Link text should make sense when taken away from its page context, as it may be read by screen readers or used in other situations. While the
2.4.5 – Multiple Ways
To improve user experience and make it easy for users to find the information they need, ensure your website provides multiple ways to locate a specific page unless it arises from a process or step.
Features to help achieve this include:
- A sitemap which gives an overview of the website structure and available pages.
- Search functionality which enables users to find specific pages by entering keywords.
- A related pages section to suggest relevant pages that users may find of interest.
By incorporating these features, you can enhance the accessibility and usability of your website, making it easier for users to navigate and find the information they need.
2.4.6 – Headings and Labels
Ensure your content headings and interactive element labels are descriptive and easy to understand, indicating the content or function of the element.
The headings and labels should convey the information that users can expect to find or the input required in the form field. It will help users quickly identify and locate the information needed and provide a better user experience.
Write clear, descriptive headings for content and labels for form fields and other interactive elements.
The key here is that headings and labels are clear and descriptive, so a user knows what content follows or what input a form field expects.
2.4.7 – Focus Visible
When an interactive element (link, button, form field, selectable element, etc.) receives focus, a visual indicator is displayed, usually an outline, so the user can easily see what element they are currently on. Do not disable this behaviour, but it may be enhanced if required.
An example can be seen in the Codepen Focusable elements - focus ring enhancements.
2.4.11 – Focus Not Obscured (Minimum)
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
For users who rely on keyboards, it's crucial that they can always see where the keyboard focus is. Some web pages have elements like sticky headers, sticky footers, cookie banners, or floating menus that can cover up the keyboard focus indicator when scrolled or overlap with existing content. This can make it particularly hard for keyboard users.
To address this, make sure that when an element receives keyboard focus, it remains at least partially visible. CSS techniques, such as the scroll-padding property, can help depending on the content type. As a good practice, try to avoid content overlap in the first place.
For interfaces that allow users to open and reposition content, this rule applies to where the content first appears. Likewise, if users can open extra content and reveal the focused item without changing the focus, you meet the requirement.
2.4.13 – Focus Appearance (AAA)
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:
- is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
- has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.
Exceptions:
- The focus indicator is determined by the user agent and cannot be adjusted by the author, or
- The focus indicator and the indicator's background color are not modified by the author.
While this criterion is level AAA, and is not strictly required, it is considered a best practice.
The WCAG introduced "2.4.7 Focus Visible", but what qualified as "visible" wasn't precisely defined. While guideline 1.4.11 sets contrast requirements, it didn't specify size or appearance. This criterion specifies the size and contrast for a visible focus indicator.
To meet this, the focus indicator should be distinct when an element gains keyboard focus. You can use CSS techniques, examples in the Codepen Focusable elements - focus ring enhancements.
For simplicity, a 2-pixel outline with sufficient contrast (per
For example: Use a solid 2px minimum border with a minimum contrast of 3:1 against the 2px of background it covers.
I'd also advise ensuring there's a 3:1 colour contrast between the border and along both the inside and outside edges. An offset can help with this. For example:
:is(a[href], button, summary, [tabindex], input, select, textarea, [contenteditable], [document]) {
outline: 2px solid transparent;
outline-offset: 2px;
}
:is(a[href], button, summary, [tabindex], input, select, textarea, [contenteditable], [document]):focus {
outline-color: blue;
}
@supports selector(:focus-visible) {
:is(a[href], button, summary, [tabindex], input, select, textarea, [contenteditable], [document]):focus:not(:focus-visible) {
outline: none;
}
}
:focus-visible {
outline-color: blue;
outline-offset: 2px;
}Guideline 2.5 – Input Modalities
Support multiple input methods. Users should be able to use various input methods, not just the keyboard, to operate website functionality for improved accessibility and usability. Consider supporting input methods such as voice commands, touch screens, or trackpads to help users with mobility impairments or repetitive stress injuries.
2.5.1 – Pointer Gestures
To improve accessibility, and usability, offer simple options for touchscreen interactions.
Avoid using multi-point gestures like “pinching” to operate a web page unless essential. Instead, provide single-pointer inputs that can replace complex finger movements.
By avoiding multi-point gestures, you can eliminate barriers to users with physical or cognitive disabilities which hinder their ability to use your website or application.
2.5.2 – Pointer Cancellation
Make it easy for users to avoid unintended clicks or touches by providing a way to cancel pointer input. It is critical for users with disabilities who may have difficulty controlling their movements.
For example, users can cancel the activation of a link by sliding away from it after touching or clicking.
When using JavaScript, avoid using a down event to trigger a function. Instead, use a click or touch event to ensure activation only occurs when the user intends. The exception is functions which emulate a keyboard or numeric keypad where keypresses are considered essential.
2.5.3 – Label in Name
Ensure the words that visually label a component are also the words associated programmatically, such as when using an ARIA label or an alt text.
Most controls have a visible text label and a programmatic name. When the text in the label matches or is contained within the programmatic name, it makes it easier for users who rely on speech recognition applications or screen readers to navigate the page. They can speak the visible text labels of components like menus, links, and buttons and get where they need to go.
If a component doesn't have a visible text label, this doesn't apply.
Best practice: If an ARIA label provides additional information, be sure the visible text comes first inside the label.
2.5.4 – Motion Actuation
If your app or website includes features which activate by motion, provide an alternative, more-simple method. In addition, users should be allowed the option to disable the motion activation altogether.
2.5.7 – Dragging Movements
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
Websites with dragging actions (like drag-and-drop, carousels, map panning, or sliders) can be tricky for users with limited dexterity when using a mouse or touch. To fix this, offer an easier way for mouse and touch users to do the same actions.
Ensure users can achieve actions with simple clicks or taps. For drag-and-drop, let users click or tap to pick up and drop items. For maps, add directional buttons for panning. Carousels need previous/next controls or navigation dots. Sliders should respond to clicks or taps on the track.
Remember, a keyboard alternative isn't enough here. Users should do these actions with a mouse or touch, not be forced to switch to a keyboard.
For more information read the Tetralogical post
2.5.8 – Target Size (Minimum)
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
- Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
- Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
- Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
- User agent control: The size of the target is determined by the user agent and is not modified by the author;
- Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
Small targets can be tough for people with fine motor challenges, especially when they're close together. WCAG 2.1 tried to help with a 44 by 44 CSS pixel size requirement at AAA level.
This guideline sets a 24 by 24 CSS pixel minimum but with spacing exceptions. To meet this, ensure targets are at least 24 by 24 CSS pixels. Or, leave enough space around each target: a 24 CSS pixel diameter circle centered on each target should be free from other targets or intersecting circles. This prevents small targets from being too crowded and hard to use.
Exceptions apply for targets with larger alternatives, inline targets, browser-controlled targets, and naturally small targets like map points.