Our guide to the WCAG 2.1 continues with the latest success criteria for website accessibility – and this guide is focusing on the second pillar, a.k.a. “Operable.”
First, a quick refresher: The WCAG (Web Content Accessibility Guidelines) are a series of standards put together by global web and accessibility experts to help make sure that websites can be used by individuals with disabilities. Currently on version 2.1 (with more updates planned for the future), the WCAG is considered the go-to source for web accessibility improvements. It’s also referenced by a variety of laws around the world, including federal requirements in the United States – which means following the WCAG recommendations can also help organizations avoid fines or the growing number of ADA-related lawsuits. Plus, it can improve web design and navigation for all visitors.
The WCAG centers its success criteria on four different pillars that describe how a website should function for those with disabilities: Perceivable, Operable, Understandable, and Robust. Since it’s not immediately obvious what those pillars may mean, we’re taking time to dive into the details, and with this guide we’re covering the criteria for Operable.
What “Operable” Means
The Operable pillar refers to the technology used to access a website, especially physical controls. For many users, that means a keyboard and mouse. But individuals with disabilities may also be using different kinds of assistive technology, such as joysticks and screen readers. Some types of disabilities make using a keyboard or mouse very difficult, so there are also users who can only use one or the other. An accessible website should be able to handle all operations without trapping users or making certain features unreachable.
That may sound a little complicated from a website design perspective, but it’s primarily about smart navigation decisions and clean coding. Let’s take a look at the criteria in greater depth to learn more about how it works.
Important Operable Criteria
Keyboard Accessibility
Users that can only use a keyboard need to be able to navigate and easily use all website features. Keyboard navigation typically uses the Shift, Tab, and Enter keys, along with a variety of shortcuts – you can visit any website and try it out right now. But for true accessibility, there are other considerations, too. Keyboard support should include:
- Clear focus indication: Websites should have a clear indicator of where the webpage “focus” is for choosing an option and pressing Enter to select it. That usually means using a color change and outline to show where the focus is at all times. This should also enable automatic dropdown menus, or important features that would be activated by a hovering mouse pointer.
- Easy pathing: Keyboard navigation should follow logical paths through each webpage that allow users to access all features, including links. The website should avoid any keyboard traps, where tabbing to different options cycles through the same few options without the ability to get back to the menu and go elsewhere. Some websites also use shortcut options that allow keyboard users to immediately skip to the important call to action or feature on a webpage.
- Minimal to no website keyboard shortcuts: Some websites enable their own shortcuts to save users time. It’s best to avoid enabling too many shortcuts for accessibility reasons. Some keyboard shortcuts can interfere with the native shortcuts that individuals with disabilities depend on to navigate the website. If shortcuts are included, there should be a mechanism to turn them off or remap them to different keys (such as adding Ctrl +).
- No specific timing required: Keyboard navigation should not require specific timed keystrokes to function properly – i.e., holding enter for 3 seconds to open a link.
Note that the WCAG does make some exceptions for underlying functions that simply can’t be done with a keyboard, but absolutely requires the movement of a mouse point (although this is rare).
Enough Time and Time Limits
Some types of website content are gated by time. They may only show up for a certain amount of time before disappearing, or have a countdown, or similar time limits. That poses problems for certain disabilities and assistive technology that may not be as quick as other methods.
Not all websites need to worry about this, but some do need time-gated content for security reasons, slideshows, tests, and more. In these cases, WCAG criteria require that websites allow users to control the time themselves. Timers should have features such as the ability to turn off the timed content, so it remains, or the ability to adjust or extend the time limit.
There are some exceptions for this criterion: Some tests, for example, may require a time limit as part of the inherent value of the test. If a website is showing real-time content (such as a live webinar), it can’t really be controlled this way. And if a time limit lasts for more than 20 hours, this guideline doesn’t apply.
You may also want to consider additional options in certain cases, such as:
- Moving, blinking, or scrolling content – like the slideshows we mentioned – should allow users to pause, skip, or hide it unless it’s absolutely essential.
- Some content automatically updates, like tickers or live news updates. In this case, users should also be able to pause, stop or hide the content so they can easily freeze it on particular content, or take as much time as they need for each update.
- If time limits include interruptions, like timed pop-ups or reminders, then they need an option to postpone or suppress them, unless the interruption is an important emergency.
- If time limits are for security reasons and require users to re-authenticate or log back in, then the website needs to allow users to resume their activity without any data loss. That generally means designing forms to automatically save data as it is entered. If that’s not possible, then the site must warn users that a timeout could lead to data loss. An alternative option is a system that saves data for up to 20 hours before the user logs back in, in which case no warning is needed.
- Some of these guidelines may be affected by local privacy laws. These laws may require additional consent or warnings about how data is used. If things get complicated (especially with sites used by minors, who cannot give consent to use personal data), the WCAG advises consulting with a legal expert.
Seizures and Physical Reactions
Flashing and strobing content can cause seizures for those who have epilepsy or can cause other problems with those who have visual impairments. It can also be annoying for other users who want to focus on website content and may get distracted. If flashing content is necessary, it should not flash any more than three times per second.
Navigation and Layout
Navigation is an important part of the Operable pillar because some types of navigation are harder with assistive technology. In general, websites should have elements that save time when navigating more complex content. For example, directories or tables of content with anchor links to their respective sections that allows users to quickly skip to the content they want. Headings and labels should effectively describe content to help save time, and links to other content should also be clear about what they do and where users will go.
Input Modalities and Using Pointers
Some users may be using a traditional mouse, some a joystick, and some a touchpad. Websites should be designed to work with all pointer technologies. This criterion can be easily summed up as, “Keep it simple.” Don’t require complex or weird pathing for a pointer/cursor to activate anything. Don’t make clickable features too small or too sensitive to pointer placement. Clicking on a website element should feel organic and logical, with a predictable “down-event” (clicking the mouse or doing the equivalent) and an easy way to undo something if users unintentionally click. Clickable targets should be at least 44 x 44 CSS pixels for easier viewing as well.
A Quick Note on WCAG Levels
As we have briefly mentioned in our other guides, if you look at the WCAG 2.1 in detail, you’ll see that the criteria are divided into different Levels, A through AAA. These are levels of compliance that indicate just how strict a specific criterion is. Level A is focused on the basics of good web design. For U.S. compliance, all businesses should aim for Level AA compliance, which enables accessibility for a broad variety of disabilities. Level AAA compliance is typically reserved for government websites that need to be usable by every citizen, and organizations that aren’t on a government payroll rarely need to worry about them. We are focusing mostly on A and AA in these guides.
Finding a Partner for Your Web Accessibility Needs
The road to website accessibility includes a variety of updates, along with choices about what kind of code to use and what new designs should look like. Not all organizations have in-house experience to make these accessibility decisions, but we can help! Contact Blue Atlas Marketing today to arrange a consultation: We can take a look at your current website and discuss what an accessibility upgrade could look like. When you are ready to make key changes, our experienced developers are ready to help.
