Operable: everything works, even without a mouse

What it is

Operable is the second principle of WCAG. Everyone must be able to use everything on your website: the menu, the buttons and the forms. Not only with a mouse, but also with just the keyboard or with voice control.

It has five guidelines. They cover using the keyboard (2.1), enough time (2.2) and flashing images that can trigger an epileptic seizure (2.3), as well as finding your way (2.4) and other ways of operating a site, such as touch and speech (2.5). Under these are 20 success criteria at level A and AA: requirements you can test a website against. The most important ones are below, with their number in WCAG 2.2. You use that number when you report a problem to your web developer or supplier.

Why it matters

People who are blind often use the keyboard, as do some people with a motor disability. Someone with a tremor easily misses small buttons that are close together.

People who can’t use a keyboard or a mouse sometimes work with speech recognition or with a special switch. If one button in your sign-up form only works with a mouse, they can get stuck there, however good the rest is.

How to do it

Your web developer does the building. You can check most of the points below yourself with the keyboard or a phone.

1. Everything works with the keyboard (2.1.1 Keyboard, level A). Tab takes you to the next link or button, Enter selects it, and you never get stuck anywhere (2.1.2 No Keyboard Trap, A). A common problem: the buttons of a video player.
2. You can always see where you are (2.4.7 Focus Visible, AA). The focus is a visible outline or colour around the link or button you are on. If your web developer removes the browser’s standard outline, another visible focus must take its place. The button with focus also must not disappear completely behind, for example, a fixed chat bar (2.4.11 Focus Not Obscured (Minimum), AA, new in 2.2). Ask your web developer to show you what the focus looks like on every background colour you use.
3. The order makes sense (2.4.3 Focus Order, A). With Tab, you move through the page in a logical order, usually from top to bottom.
4. You can skip the menu (2.4.1 Bypass Blocks, A). A “Skip to content” link at the top saves a lot of key presses.
5. Titles and headings say what it is about (2.4.2 Page Titled, A, and 2.4.6 Headings and Labels, AA). “Sign up with the neighbourhood team” in the browser tab says more than “Home”.
6. Link texts are clear (2.4.4 Link Purpose (In Context), A). “Read more about signing up” instead of “click here”.
7. There is more than one way to reach a page (2.4.5 Multiple Ways, AA). For example the menu and a search function, or an overview of all pages. Someone with low vision sometimes finds a page more easily by searching than through a large menu. If your site only has three or four pages, links from the home page can be enough.
8. There is enough time (2.2.1 Timing Adjustable, A). Does the client portal log someone out after a while? Then warn them first, and give them at least 20 seconds to ask for more time with a single action. Or let someone turn off the time limit beforehand.
9. Nothing moves without a pause button (2.2.2 Pause, Stop, Hide, A). News items that change by themselves and keep going for more than five seconds must be possible to pause, stop or hide. And nothing flashes more than three times per second (2.3.1 Three Flashes or Below Threshold, A).
10. It also works without dragging and swiping (2.5.7 Dragging Movements, AA, new in 2.2, and 2.5.1 Pointer Gestures, A). Do you move an appointment by dragging it? Then also provide a button or drop-down list. Can you zoom in on a map of the neighbourhood with two fingers? Then also add a plus and a minus button.
11. The visible text is in the name (2.5.3 Label in Name, A). If a button says “Sign up”, that word is also in its name in the code. This is because someone who uses speech says what is on the button: “click Sign up”. If the button is called “Send form” in the code, nothing happens.
12. Click areas are big enough (2.5.8 Target Size (Minimum), AA, new in 2.2). A button is at least 24 by 24 CSS pixels, a measurement web developers use, or there is enough space around it. A link in the middle of a sentence doesn’t count. The stricter size of 44 by 44 belongs to level AAA (2.5.5 Target Size (Enhanced)).

Points to watch

• Test it yourself. Put your mouse away and fill in your sign-up form using only Tab, Shift+Tab, the arrow keys and Enter. The Keyboard test takes you through this in ten short steps.
• Check drop-down menus separately. A menu that opens when you point at it with the mouse must also work with the keyboard.
• Check which version a checklist follows. Older rules and checklists are based on WCAG 2.1, and the requirements called “new in 2.2” above are not in them. You can read which version the rules for Dutch government bodies require in What is WCAG?

Find out more

• The other principles: perceivable, understandable and robust.
• Making your website accessible: the steps for your organisation.
• Accessible website checklist