Keyboard exercise

Buttons must have discernible text (WCAG SC 4.1.2)

You probably spotted this one right away. The button doesn't have any text in it, which violates WCAG Success Criteria 4.1.2.

Adding text to the button element will fix this. Alternately, adding an aria-label attribute to the button will also suffice, but remember that native HTML solutions are preferred according to best practices.

Links must have discernible text (WCAG SC 2.4.4)

There's an anchor tag below containing a link, but it doesn't have any text in it. This situation is similar to the button issue above, but this one violates WCAG Success Criteria 2.4.4, which requires text that describes what the link does or where it goes.

It's also an issue for sighted users, who can't even see the link. Note that you can still tab to the link (it still receives keyboard focus) and activate it by pressing the enter key.

All functionality must be keyboard accessible (WCAG SC 2.1.1)

This is a violation of WCAG Success Criterion 2.1.1, which states that everything interactive on the page must be operable via keyboard input. If you can do something with a mouse, you must be able to do it with a keyboard.

In the navigation menu example below, the submenu items can be seen upon mouseover but are not present when using a keyboard. You may recall the usable keys for manual page navigation, listed in the "How to test" section for keyboards; none of these inputs allows you to view the submenu dropdown, which is especially crucial in real-life cases like this because a significant amount of content would be hidden from the site visitor. To fix this, you must allow the site visitor to see the dropdown submenus.

Expected behavior: when a top-level menu item is in focus (e.g. the "Cruisers" item), you should be able to view its submenu (if applicable) by pressing the enter key.

Meaningful error messages (WCAG SC 3.3.3)

For error messages to be meaningful, you must include instructions that explain to the user how to correct the error. In this example, if you start typing a phone number in the field, the input returns an error that says "Wrong. Try again." So what's wrong with what you typed in the field? Is it too long or too short? What did you do wrong? This cryptic error message isn't at all helpful for the person using this form.

Expected behavior: generated dialogue informing the user of any field restrictions and what they must do to meet form submission requirements.

Links must have visual focus indicators

If a link receives focus from a keyboard (e.g. via the TAB key), the page must render a visible border around the object indicating the location to the user. In the example below, the text "spaghetti recipe" links to another location but does not show when it is in focus. This is a violation of WCAG SC 2.4.7, which can only be resolved with the addition of a visual focus indicator.

Links must have visual focus indicators (WCAG SC 2.4.7)

This example can also be found on the Screen Reader exercise page. The expectations for a keyboard-only use case are different, but the accessibility impediment is just as serious since the component doesn't communicate essential information to the user. These Accordion buttons don't show a visual outline when they receive focus, so they are inaccessible to users who rely on a keyboard as a sole means of input. When receiving focus from a keyboard (e.g. via Tab key), all interactive elements must display a visual focus indicator.