Keyboard Testing for Digital Content

Keyboard Testing for Digital Content

A step-by-step guide to checking keyboard access and focus order, aligned to WCAG 2.2 Level A and AA.

Why test with a keyboard

Automated checkers and AI tools can quickly find some accessibility issues. They cannot tell you whether a learner can move through your course with a keyboard, whether the order makes sense, or whether the learner can see where they are on the screen. Someone has to set the mouse aside and try it.

Many learners navigate with a keyboard or with tools that work like one. That includes people with motor disabilities, people who use screen readers, people who use switch devices or voice control, and people who prefer the keyboard. If an interaction only works with a mouse, these learners cannot finish the course.

What automated and AI tools can flag

• Missing alternative text on images
• Low text color contrast
• Form fields without labels
• Empty links and buttons
• Skipped or missing heading levels

What you need to test by hand

• Whether every interactive element can be reached and used with the keyboard
• Whether the focus order follows the visual and logical order of the content
• Whether the focus indicator is visible at every stop
• Whether you can move out of every component without getting stuck
• Whether popups, tooltips, and dialogs open, close, and return focus as expected
• Whether drag-and-drop, hotspots, and other custom interactions can be completed

Before you start

• Test the published course in a web browser, the way a learner would see it. The preview inside an authoring tool does not always behave the same way.
• Set the mouse or trackpad aside. Press Tab from the browser address bar to move into the page.
• On a Mac, turn on keyboard navigation in System Settings, under Keyboard. In Safari, also turn on "Press Tab to highlight each item on a webpage" in Settings, under Advanced, or use Option + Tab.
• If you can, test in more than one browser, such as Chrome, Edge, Firefox, and Safari.
• Test every page or slide. Include feedback layers, popups, quizzes, results screens, and any content that appears only after an interaction.
• Keep a findings log open so you can record issues as you go.

Keyboard commands to use

These are the standard keys learners expect. If a control does not respond to its standard keys, note it as an issue.

• Moving through the page: Tab moves forward, and Shift + Tab moves back. Focus should move to the next or previous interactive element and be clearly visible.
• Link: Enter opens the link.
• Button: Enter or Space activates the button. Both keys should work.
• Checkbox: Space checks or unchecks the box.
• Radio buttons: Arrow keys move between choices, Space selects, and Tab leaves the group. Only one choice in the group can be selected.
• Dropdown (select) menu: Arrow keys move through the options, Enter chooses, and Esc closes. Typing a letter can also jump to matching options.
• Popup or dialog: Esc closes it. Focus stays inside a modal dialog while it is open and returns to the button that opened it when it closes.
• Accordion: Enter or Space expands or collapses the section.
• Tabs that change content on the same page: Tab enters the tab list, and arrow keys move between tabs. The panel content changes to match the selected tab.
• Slider: Arrow keys change the value, and Home and End jump to the start and end. The value should change in steps and be shown on screen.
• Media player: Tab to each control and use Enter or Space to activate it. Play, pause, volume, captions, and full screen should all work from the keyboard.
• Scrolling: Arrow keys scroll, and Space and Shift + Space scroll by page, as long as focus is not in a control that uses those keys.

Testing steps

Work through these steps on each page or slide. Each step lists the WCAG 2.2 success criteria it checks.

Step 1: Start at the top and find the skip link

What to do: Load the page and press Tab once. Look for a "Skip to main content" link or something similar. Press Enter on it, then press Tab again.

It passes when: A skip link or another way to bypass repeated menus (such as headings or landmarks) is available. After you use it, the next Tab lands in the main content. This matters most when the course player or LMS repeats a menu on every page.

WCAG: 2.4.1 Bypass Blocks (A)

Step 2: Tab through everything

What to do: Press Tab to move forward through every interactive element on the page: links, buttons, form fields, tabs, accordions, hotspots, media controls, and next and previous buttons. Press Shift + Tab to move backward.

It passes when: You can reach every element with the keyboard that you can click with a mouse, and nothing is skipped.

WCAG: 2.1.1 Keyboard (A)

Step 3: Watch the focus indicator at every stop

What to do: Keep your eyes on the screen as you Tab. At each stop, ask yourself whether you can tell exactly where you are.

It passes when: Every focused element shows a visible outline, highlight, or other change. The indicator stands out against the background, with at least 3:1 contrast against adjacent colors, and the course styling does not remove or hide it.

WCAG: 2.4.7 Focus Visible (AA); 1.4.11 Non-text Contrast (AA)

Step 4: Check that the focus order makes sense

What to do: Compare where focus goes with how the page reads visually. On a slide, watch for focus that jumps between columns, skips the main content, starts on the player controls, or lands on items in an order that does not match the instructions.

It passes when: Focus moves in a logical order that follows the visual and reading order, usually left to right and top to bottom. Related items stay together, for example, a question, then its answer choices, then Submit. Content that appears after an action, such as feedback, comes next in the order.

WCAG: 2.4.3 Focus Order (A); 1.3.2 Meaningful Sequence (A)

Step 5: Make sure focus is never hidden

What to do: Watch for focused items that end up behind a sticky header, a course player bar, a cookie banner, a chat widget, or an open popup.

It passes when: At least part of the focused element is visible on the screen and not covered by other content the author created.

WCAG: 2.4.11 Focus Not Obscured (Minimum) (AA)

Step 6: Check for extra stops on things that are not interactive

What to do: Note any time focus lands on plain text, an image, a decorative shape, or an empty area that does nothing when you press Enter or Space.

It passes when: Only interactive elements receive keyboard focus. Extra focus slows down slow learners and makes the order confusing. Note them as a usability issue, or under 2.4.3 if they disrupt the meaning or operation of the page.

WCAG: Best practice; can affect 2.4.3 Focus Order (A)

Step 7: Operate every control with the expected keys

What to do: Use the keyboard commands listed above. Activate every button, open every accordion and tab, select answer choices, play and pause media, move sliders, and submit every question.

It passes when: Each control works with the standard keys for its type. Buttons respond to both Enter and Space, and radio buttons move with the arrow keys. The result is the same as with a mouse.

WCAG: 2.1.1 Keyboard (A); 4.1.2 Name, Role, Value (A)

Step 8: Test drag-and-drop, hotspots, and other custom interactions

What to do: Try to complete every interaction that was designed for a mouse, including drag-and-drop, click-and-reveal, hotspots, sorting, matching, sliders, and games.

It passes when: The learner can complete the full interaction with the keyboard alone. Otherwise, a keyboard-accessible alternative is provided that covers the same content and earns the same credit.

WCAG: 2.1.1 Keyboard (A)

Step 9: Check for keyboard traps

What to do: Tab into every component and try to Tab back out. Pay close attention to embedded video players, iframes, web objects, text fields, and third-party widgets.

It passes when: You can always move focus away using Tab, Shift + Tab, Esc, or the arrow keys. If a component needs a different key to exit, the learner is told what that key is.

WCAG: 2.1.2 No Keyboard Trap (A)

Step 10: Open and close every popup, lightbox, and dialog

What to do: Open each popup or layer with the keyboard and Tab through it. Close it once with Esc and once with its Close button.

It passes when: Focus moves into the popup when it opens. For modal dialogs, focus stays inside while the dialog is open. Both Esc and the Close button close it. When it closes, focus returns to the button that opened it, not to the top of the page.

WCAG: 2.4.3 Focus Order (A); 2.1.2 No Keyboard Trap (A)

Step 11: Check tooltips and content that appears on focus

What to do: Tab to any element that shows extra content on hover, such as a tooltip, glossary term, or menu.

It passes when: The same content appears when the element receives keyboard focus. It stays visible until you move focus away or dismiss it, and you can dismiss it with Esc without moving focus.

WCAG: 1.4.13 Content on Hover or Focus (AA)

Step 12: Watch for unexpected changes

What to do: As you Tab onto elements and change form fields, radio buttons, and dropdowns, watch for anything that happens on its own.

It passes when: Moving focus to an element does not open a new window, submit a form, move to a new slide, or start media. Selecting an option does not change the page unless the learner was told it would.

WCAG: 3.2.1 On Focus (A); 3.2.2 On Input (A)

Step 13: Check single-key shortcuts

What to do: With focus on the page and not in a text field, press a few letter and number keys.

It passes when: Nothing happens. If something does, the single-key shortcut can be turned off or remapped, or it works only when its control has focus. Learners who use voice control can trigger these shortcuts by accident.

WCAG: 2.1.4 Character Key Shortcuts (A)

Step 14: Check timed and moving content

What to do: Look for timed quizzes, slides that advance on their own, carousels, and animations, and try to reach their controls with the keyboard.

It passes when: Time limits can be turned off, adjusted, or extended with a simple keyboard action. Anything that moves, blinks, or scrolls for more than five seconds has a pause or stop control that the learner can reach and use with the keyboard.

WCAG: 2.2.1 Timing Adjustable (A); 2.2.2 Pause, Stop, Hide (A)

WCAG 2.2 success criteria covered

Keyboard testing covers these Level A and AA success criteria:

• 1.3.2 Meaningful Sequence (A): The order of content matches the order needed to understand it.
• 1.4.11 Non-text Contrast (AA): The focus indicator has at least 3:1 contrast with adjacent colors.
• 1.4.13 Content on Hover or Focus (AA): Tooltips and popups that appear on focus can be dismissed and stay visible until they are dismissed.
• 2.1.1 Keyboard (A): Every function works with the keyboard alone.
• 2.1.2 No Keyboard Trap (A): Focus can always move away from every component.
• 2.1.4 Character Key Shortcuts (A): Single-key shortcuts can be turned off or remapped, or work only on focus.
• 2.2.1 Timing Adjustable (A): Time limits can be turned off, adjusted, or extended with the keyboard.
• 2.2.2 Pause, Stop, Hide (A): Moving or auto-updating content can be paused with the keyboard.
• 2.4.1 Bypass Blocks (A): A skip link or another method bypasses repeated content.
• 2.4.3 Focus Order (A): Focus moves in an order that preserves meaning and operation.
• 2.4.7 Focus Visible (AA): The keyboard focus indicator is visible.
• 2.4.11 Focus Not Obscured (Minimum) (AA): Focused elements are not fully hidden by other content.
• 3.2.1 On Focus (A): Receiving focus does not trigger a change of context.
• 3.2.2 On Input (A): Changing a setting does not trigger an unexpected change of context.
• 4.1.2 Name, Role, Value (A): Custom controls behave like the type of control they present as.

If your organization targets Level AAA, keyboard testing also covers 2.1.3 Keyboard (No Exception), 2.4.12 Focus Not Obscured (Enhanced), and 2.4.13 Focus Appearance.

Recording what you find

For each issue, record:

• The page or slide where it happened
• What you did
• What happened
• The WCAG success criterion it relates to
• The severity

Example: On Lesson 2, slide 4, I tabbed to the drag-and-drop activity. I could not pick up or move items with the keyboard, and no alternative was provided. This fails 2.1.1 Keyboard (A), and the severity is Critical.

Severity levels

• Critical: Stops a learner from completing the content or the course.
• Significant: Makes the content very difficult to use, though a workaround may exist.
• Moderate: Causes confusion or extra effort but does not stop the learner.
• Recommendation: Not a WCAG failure, but fixing it improves the experience.

Resources

• WCAG 2.2 Quick Reference (W3C)
• Keyboard Accessibility (WebAIM)
• ARIA Authoring Practices Guide: expected keyboard patterns for common controls (W3C)

Need this in a Word Document? Download Keyboard Testing for Online Courses and edit as needed.