Check keyboard access and visual focus on web pages

On this page:

Overview

Important:

This information is intended for web developers, providing a holistic process for performing an initial pass of evaluating your website for accessibility. This is not a substitute for performing a complete Web Content Accessibility Guidelines (WCAG) 2.0 AA site evaluation, but following this full process will capture most of the WCAG 2.0 AA Guidelines more efficiently.

It is impossible to meet the website accessibility standards in IU's Americans with Disabilities Act Policy (UA-02) using only automated tools.

Some people use a keyboard or keyboard emulator to navigate websites. Many assistive technologies rely on keyboard-only navigation. All interactive elements, such as links, buttons, and form fields, need to be usable with only the keyboard and should clearly indicate when they can be activated with the keyboard.

Make sure that all interactive content is operable using only a keyboard and follows a logical order. Pressing the Tab key repeatedly should move you smoothly through an expected order, based on the onscreen content. At the same time, make sure you can tell where you are on the page. There should be a clear visible indicator of which element has focus and will receive input.

Look for the following:

  • Visible skip links
  • Logical tabbing order
  • Excessive tabbing
  • Interactive elements that are not accessible by keyboard
  • Non-interactive elements that receive keyboard focus
  • Lost focus, where you can't tell which element has keyboard focus
  • Any keyboard traps where a person can't navigate away using only the keyboard

For a brief demonstration, view this one minute YouTube video on testing keyboard support.

Note:

If you are using a Mac, you may need to update your keyboard settings first.

  • In the System Preferences, select Keyboard. Depending on the MacOS version, you may need to select Shortcuts, then either toggle "Keyboard Navigation" to on, check Use keyboard navigation to move focus between controls, or select All controls under "Full Keyboard Access: In windows and dialogs, press Tab to move keyboard focus between:". Do not enable "Full Keyboard Access" in the accessibility keyboard settings (System Preferences > Accessibility > Keyboard).
  • To enable full keyboard accessibility in the Safari web browser, open the Safari Preferences. Select Advanced. In "Accessibility:", check the box next to "Press Tab to highlight each item on a webpage".

Guidelines relevant to keyboard accessibility

Tools

If you find that you can't tell which element has keyboard focus, you can use a focus enhancer tool to help discover problem areas. Focus enhancer tools will indicate where the focus is, helping to identify any focusable elements that lack a visible focus indicator.

Specific things to pay attention to

Certain keyboard interactions beyond using Tab, Enter, and the Spacebar are expected and should be tested. Native semantic HTML elements have built-in keyboard interactions. Complex widgets and modified HTML elements often require added keyboard support.

The following resources may be helpful in determining the expected keyboard interactions:

Skip links

Skip links should be the first interactive items you find when tabbing into a page. Skip links allow someone using a keyboard to skip repetitive content like navigation menus. At minimum, there should be a link to skip to the main content.

Verify that skip links are present and visible. Also activate the skip links to verify the destination matches expectations. For example, "Skip to content" should move focus to the start of the main content.

For a brief demonstration, view this short YouTube video on checking skip links.

Carousels and slide shows

Examine the carousel controls. There should be previous and next buttons, navigation buttons that indicate which slide is currently displayed, and play or stop buttons. The selected item should have visible focus. The carousel should pause when it has keyboard focus or when the mouse hovers over it. Otherwise, there may not be enough time to read the content if the slides automatically advance.

Carousels can cause keyboard traps in many ways, including if they advance faster than a person can navigate with a keyboard.

Resources for accessible carousels:

Accordions

Make sure accordion panels can be opened and closed with either the Spacebar or the Enter key and that they are navigable using the arrow keys on the keyboard. Check that the accordion is not a keyboard trap.

Resources for accessible accordions:

Forms

Make sure that all inputs, buttons, date selections by calendar, and other controls are operable by keyboard. Also check the error messaging, required form fields, and non-form elements.

Error messages must clearly identify specifics about an error and the error location. There should be some suggestion on how to correct the error. For example, was a required field left blank? Or was an email address incorrectly formatted?

For a single error, focus should move immediately to the location of the error. For multiple errors, a list of links at the top of the form listing all error locations makes it easy to navigate directly to each error. Each field with an error should always include an inline error message.

Required form fields need to be clearly identified. If an asterisk (*) is used to identify required fields, the asterisk should be defined at the start of the form. Including (required) in the label instead of using an asterisk is clearer and more robust. Alternatively, a statement that all fields are required except those marked as "optional" is acceptable.

Non-form elements in forms can cause problems for assistive technologies. For example, screen readers enter forms mode in forms. When in forms mode, non-form elements, such as a paragraph of text, are ignored by the screen reader. Note any non-form elements in the form. These are often found in instructions, disclaimers and other fine print within forms.

Resources for accessible forms:

Links and buttons have different semantic functions. Make sure the correct element, link or button, has been used.

Open links and verify that the link goes to the correct location. The link text should accurately describe the link destination.

Make sure any buttons do what they are expected to do. The button text should accurately describe the button action.

Links that go to different places and buttons that perform different actions should have different text. If the same button or link appears on more than one page, it should be consistently identified and have the same name.

Resources for accessible links and buttons:

PDFs and other documents

Make note of any PDFs, Word files, and other documents discovered while checking links. Once all possible PDFs and other documents are found, they will need to be checked for accessibility.

Resources for accessible PDFs and other documents:

Widgets

Make sure all widget controls can be operated with the keyboard. Types of widgets include maps, calendars, chats, social media, and video and audio players.

Resources for accessible widgets:

Next step: Use automated tools to review accessibility
Previous step: Visually inspect web pages for accessibility
Return to index: Perform an accessibility review on your website

Get help

For questions or consultations, email the User Experience Office's accessibility team.

Related documents

Evaluation resources for meeting Web Content Accessibility Guidelines (WCAG) 2.0 AA standards

This is document atfp in the Knowledge Base.
Last modified on 2023-10-04 10:58:37.