Keyboard and visual focus
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.
Check keyboard navigation and visual focus
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.
If you are using a Mac, you may need to update your keyboard settings first.
- In the System Preferences, select , and then . Depending on MacOS version, at the bottom of the window check or select under "Full Keyboard Access: In windows and dialogs, press Tab to move keyboard focus between:".
- To enable full keyboard accessibility in the Safari web browser, open the Safari . Select . In "Accessibility:", check the box next to "Press Tab to highlight each item on a webpage".
Guidelines relevant to keyboard accessibility
- WCAG 2.1 SC 2.1.1: Keyboard
- WCAG 2.1 SC 2.1.2: No Keyboard Trap
- WCAG 2.1 SC 2.4.1: Bypass Blocks
- WCAG 2.1 SC 2.4.3: Focus Order
- WCAG 2.1 SC 2.4.7: Focus Visible
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
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:
- WebAIM's guide to Keyboard Testing
- WAI-ARIA Authoring Practices: Developing a Keyboard Interface
- WAI-ARIA Authoring Practices: Design Patterns and Widgets
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:
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:
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:
- Creating accessible forms
- G83: Providing text descriptions to identify required fields that were not completed
- G139: Creating a mechanism that allows users to jump to errors
- H90: Indicating required form controls using label or legend
- WAI-ARIA Authoring Practices: Design Patterns and Widgets
- Error Suggestion: Understanding SC 3.3.3
- Error Identification: Understanding SC 3.3.1
Links and buttons
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:
- Chrome Developers A11ycasts: Just use a button (YouTube video)
- Links vs. Buttons in Modern Web Applications
- Link Purpose (In Context): Understanding SC 2.4.4
- Headings and Labels: Understanding SC 2.4.6
- Consistent Identification: Understanding SC 3.2.4
- Quick accessibility test: Link text (YouTube video)
- Quick accessibility test: Visual presentation of links (YouTube video)
PDFs and other documents
Make note of any PDFs, Word files, and other documents discovered while checking links. Once all possible PDF and other documents are found, they will need to be checked for accessibility.
- Checking a PDF: Start checking PDF accessibility with Adobe Acrobat DC's built-in accessibility check.
- Checking a Word document: Use the built-in accessibility checking tool on Windows computers.
Resources for accessible PDF and other documents:
- PDF Accessibility
- Understanding Success Criterion 2.4.9: Link Purpose (Link Only)
- Run the accessibility checker in Microsoft Word
- Microsoft Office, Adobe, and other cheatsheets
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:
- Guidelines for accessible maps
- Deque University accessible datepicker example
- WhatSock accessible datepicker example
For questions or consultations, email the User Experience Office's accessibility team.