Welcome back 👋
In my previous article, I covered Perceivability, the first WCAG principle.
Today I’ll walk through the second principle: Operability. This one covers implementation guidelines, success criteria, and the most common mistakes developers make.
But first, what do we mean by Operability?
Operability is about the user’s ability to navigate the interface and perform every available action, regardless of their challenges or the tool they use to interact with it.
Most developers assume users will use a mouse and only touch the keyboard for typing. That’s a common mistake. There are many other input devices: keyboards (for full navigation), eye-tracking devices, braille displays, and voice control.
Let’s get into the implementation guidelines.
Ready? Let’s go! 😊
1. Keyboard Access
The interface must be fully operable using only a keyboard. To understand why this matters, you need to understand how assistive technology users navigate:
Arrow Key Navigation
On desktop, screen readers convert web pages into a document-like structure (similar to a Word document), letting users navigate through everything with arrow keys: buttons, links, text, all of it.
On mobile, users swipe left-to-right or right-to-left on the touchscreen to move through elements. This applies to all apps, including the browser.
As you can tell, this method is slow. The user has to read through every element to reach what they want. That’s why faster navigation methods exist.
Tab Navigation
The Tab key moves users between interactive elements only: links, buttons, input fields, checkboxes. It skips non-interactive content like text and images.
Faster than arrow keys, but if you have a lot of interactive elements, it still takes time to reach the one you need.
Quick Navigation Keys
Screen readers let users jump between elements by type. Press “b” to jump between buttons, “e” for edit fields, “r” for radio buttons, “c” for combo boxes, and so on.
These shortcuts are fundamental to screen reader usage, but they only work when developers mark up their elements correctly.
Two takeaways: use native HTML elements whenever possible (don’t reinvent the button), and keep the interface layout consistent.
Custom Elements
If you must create custom elements, make sure to:
-
Tell assistive technology what the element is, using the role attribute in web interfaces.
-
If the element is interactive, make it reachable via Tab by adding a tabindex attribute.
2. Timing
When content is time-dependent (booking pages, online exams), there must be a way to inform users of remaining time and let them extend it.
Assistive technology users need more time to understand the interface and complete actions. Design for that.
If timing controls an animation (like an image carousel), provide a way to pause, restart, and manually navigate. Give users time to read and understand what they’re seeing.
3. Motion Sensitivity
Some disabilities cause sensitivity to rapid motion or flashing. Design your interface to reduce or stop motion when the user has set that preference on their device.
See prefers-reduced-motion on MDN for implementation details.
4. Navigation Mechanisms
Skip Links
If part of the interface repeats on every page (like a header), provide a link that lets users skip past it and jump straight to the main content.
Page Titles
Every page needs a title that accurately describes its content. The title is the first thing screen reader users hear, and it tells them where they are.
Logical Element Order
Elements must be ordered logically and consistently across all pages. Screen reader users read elements based on their position in code, not their visual position. Don’t rely on CSS alone to communicate structure.
Descriptive Link Text
Interactive element names should stand on their own. Users sometimes navigate between links without reading the surrounding text.
Avoid: “Read more”, “Click here”, “Learn more.” Use: “Read more about WCAG guidelines”, “Click here to submit your application”, “Learn more about keyboard navigation.”
Use Headings to Structure the Page
Divide the interface into sections using heading levels. There are six heading levels in HTML. Use them hierarchically to show which sections are main and which are sub-sections.
For example: on a store website, the logo gets heading level 1, main categories get level 2, sub-categories get level 3, and so on.
I worked on the Ehsan Platform as a practical example of this. We divided every page into sections with headings at consistent levels. Users can press “4” to jump between opportunities on any page in any section, because we kept the heading levels consistent. This unifies the browsing experience and eliminates confusion.
Wrapping Up
These are the key Operability guidelines. There’s more I didn’t cover (like dialog handling), and I plan to revisit those with practical examples.
For the full reference, visit the WCAG Quick Reference.
Next: Understandability, the third principle.
Happy to take questions.