skip to content
Primary navigation


Successful Teams Ensure 100% of their Members Understand Keyboard Accessibility

Do You Know Your Role?

2/23/2023 3:58:39 PM

Hierarchy chart. 1st level: “Keyboard testing”. 2nd level (text with icons): Who (head), What (gear), Why (talking bubble with question mark).

By Jennie Delisi, Accessibility Analyst

Who Tests, What Gets Tested, and Why

Keyboard testing is one of the most basic digital accessibility tests. If you are going to learn one test, start with this one! It helps many people, including people who:

  • Use screen reading software, such as people who are blind.  
  • Use alternative access methods like keyboard only (no mouse), switches, or use their voice to operate their computer. These may be people with tremors, or people with other types of mobility challenges.

The goal of keyboard testing is to answer these questions:

  • Can someone use all interactions without a mouse?
  • Can that person (visually) tell which interaction they are on?
  • Are the interactions in the order a person expects?

Anyone that makes digital communications needs to know how to do these tests. Even if you create basic digital communications! Some examples include:

  • Emails.
  • Social media posts.
  • Documents.
  • Web pages (including SharePoint pages).
  • Mobile apps.
  • E-learning.
  • Digital maps.
  • Data visualizations.

Are you on a team building or reviewing a technology solution? Each team member needs to understand what keyboard accessibility is and why it is important. Depending on their role, they may also need to know how to test. This includes team members like the:

  • Project manager.
  • Business analyst.
  • Designer.
  • Developer.
  • Testers (both accessibility and quality assurance professionals).

Keyboard tests check interactive elements. If you are a mouse user, these are things you click on (links, buttons, menus). For forms, they are the ways you can give your response: radio buttons, check boxes, dropdowns for choices, text areas. More complex interfaces sometimes have accordions, dialogs/modal windows, toggles. Don’t worry if you are not yet ready for the complex ones! We will start with the basics.

This leaves many elements you do not need to test with a keyboard. Anything you are to read or notice, but not interact with, should not get keyboard focus. This includes:

  • Headings.
  • Paragraph text.
  • Images that do not have a link.

What about access to alternative text? It depends.

  • Screen reading software’s access to alternative text is tested during other types of accessibility testing.
  • If you are testing something that allows you to add alt text (when testing an authoring tool itself, not if you are a content author), this should be keyboard accessible. An example: when creating an email, you can insert an image. In Outlook, to add the alternative text using just your keyboard:
    • Bring focus to the image.
    • Shift + F10 opens the context menu.
    • Arrow keys bring you to the “edit alt text” menu option.
    • Enter key selects this option, and you are brought to the text field for entering alt text.

Ready to learn more? This article covers: 

  • Keyboard testing basics.
  • Keyboard-only use planning and requirements writing.
  • Reporting and fixing problems.
  • Resources for learning more.

Keyboard Testing Basics

Your keyboard test needs 3 basic checks:

  • Keyboard-only use works.
  • Visual indicators are present.
  • Predictable and correct order.

Do them twice:

  • At regular size/magnification.
  • Magnified to 200%.

For intermediate and advanced testers: Learn more details by reviewing How to Meet WCAG (Quick Reference), with WCAG 2.1 A and AA selected for success criteria related to keyboard

Test #1: Identify and evaluate interactive elements

You are checking to be sure that all interactions can happen without a mouse. You can use your tab key (and sometimes arrow keys and other keys on your keyboard) to go between these elements and use them. Some examples:

  • Use your tab key to move between links, buttons, form controls, or groups of radio buttons.
    • Within the radio buttons, use your arrow key to move between the options.
  • When in a dropdown (like a submenu), use your up and down arrow keys to move between the options.
  • Use your enter key, and sometimes the space bar, to select something. You can use the enter key when your focus is on a link to go to that page. 

How to identify interactive elements

Beginners ask: how do I know if something is interactive? 

Answer: If you are able to use a mouse, you can slowly move your mouse across the area you are testing. If your pointer changes from an arrow to something else, that is interactive. Here’s an example: for Windows operating systems, pointers can change from an arrow to a caret or text cursor for text entry areas. Microsoft shares more information and image examples in Windows 7 Mouse and Pointers.

Arrow (pointer) next to unfocused link with text “Read the quick cards.” Underneath is same link, with index finger (pointer) over it, darker text color.

Mouse pointers may also change from an arrow to a finger pointing to show there is a link. When checking which elements are interactive, you are not checking what shape it changes to, just noticing when it changes. When you do your keyboard test, you want each of the areas with changes to the mouse pointer to also be usable with just a keyboard.

Another way to complete this check for interactive elements is to review the code. This is useful if you are testing a web page or app. Look for the names of elements (like <button>), input type, and events (like onclick).

Screenshot of Office of Accessibility’s January newsletter, web version. Numbers go from link (#1), to an obscured button (#2), logo (#3), link to view as a webpage (#4).

When you use a tool like Accessibility Insights for Web, you can get instructions and visuals while testing, as shown in the image above. I completed the keyboard-only test on the web version of our January newsletter (use this link to try for yourself!). The tool showed each element that got focus with the tab key as I moved across the page. It also shows me the order (we cover this in Test #3). This type of tool can make it easier to share your results with other people. Note: this tool works for web apps and sites only. 

Use WebAIM’s table in the Keyboard Testing article, Keyboard section while testing. They list expected keyboard behaviors.

There are other tools that can help you run this test, like ANDI.

Identify keyboard traps!

You don’t want to find a keyboard trap! A trap is where you cannot move away from something after getting to it with the keyboard – being “trapped.”

Get ready for WCAG 2.1

Intermediate and advanced testers can also check for these:

  • If you get access to more content when you mouse over something. Make sure you can also access this with just a keyboard. Example: a tooltip.
  • If you can use a single letter keyboard shortcut, make sure you can turn this off, remap it, or it is only active when the component has focus.

Test #2: There is a visual indicator when you move to an interactive element

Once you start using your tab key on a webpage, you may see a rectangle around the interactive elements on the page. This rectangle follows as you move to the different interactive elements with your tab key. This is called a focus indicator. They are not always rectangles. They could be a background and emphasis change, or some other visual that tells you “you are here.” Each interactive element needs a focus indicator.

Expanded hamburger menu. Sub-menu item with focus: collapsed accordion “For Government” is 2 of 4. It has a dotted line around the text

The submenu item “For Government” has a dotted line around it, indicating it has focus.

Test #3: You arrive at interactive elements in a predictable order

When reading English text, we go from left to right, top to bottom. When we review information on an unfamiliar webpage or document, this is how we visually scan the page to see what is there. As you complete your check, ensure that interactive elements get focus in this order. 

Here’s an incorrect order:

  1. Footer link.
  2. Button on the top of the page.
  3. Link in the main content.

This order passes the test:

  1. Button on the top of the page.
  2. Link in the main content.
  3. Footer link.

Keyboard-Only Use Planning and Requirements Writing

For email writers, document authors, social media professionals, map makers, and data visualization creators

You may feel overwhelmed at the idea of testing everything you create. Most of your content will only use a few interactive elements. By getting comfortable using keyboard-only to access your content, you will quickly learn how to ensure keyboard accessibility for those interactions you commonly use. Your audience will notice! Key elements to think about include:

  • Links, radio buttons, and check boxes.
  • Placement of hashtags.
  • Interactions that reveal additional content.

Project Managers

Work with your project team to determine the best ways to ensure keyboard-only accessibility. This includes the business analyst, designer, developer, quality assurance professional, and your digital accessibility subject matter expert. Reserving time in the early stages of the project for this work will reduce testing time and rework at the end of the project. Key questions to ask include:

  • How will someone use this component with just a keyboard (no mouse)?
  • How will someone using a keyboard know they have focus on this area?
  • What order do elements get keyboard focus on this page?
  • Who (which role) will conduct and be responsible for testing?

Business Analyst

Depending on how specific your business requirements need to be, you can take different approaches to make sure the project’s end product is accessible with a keyboard. For a more global approach you can add a requirement like “Meets the state of Minnesota’s digital accessibility requirements” then include a link to the latest version found on the Accessibility Policies and Standards webpage. The project team can then pull the current requirements from document. Be sure to use the most current version of the standard. For example, in the future, the state of Minnesota may require WCAG 2.1 success criteria for levels A and AA related to keyboard-only use. This includes: 1.3.2, 1.4.13, 2.1.1, 2.1.2, 2.1.4, 2.4.3, 2.4.7, 2.5.4. As of February 2023, the standard only requires WCAG 2.0 A and AA (1.3.2, 2.1.1, 2.1.2, 2.4.3, 2.4.7).

If your plan is to capture detailed accessibility requirements, they might read something like:

  • The calendar widget operates both with mouse-only and keyboard-only interactions.
  • The browser’s default focus indicator is visible during keyboard-only use for all interactive elements.
  • The page’s focus order is header region elements, search, menu/navigation area elements, main content elements, footer elements.

Note that you may not need this low-level detail on large efforts when working with developers and testers with a lot of experience and digital accessibility expertise. They will understand all the details. On a small agile-style effort this level of detail might be exactly what is needed.


As you work, review:

  • Can each component operate with keyboard-only?
  • Is the visual indicator present for each element?
  • Do elements receive focus in the proper order (left to right, top to bottom)?

Reporting and Fixing Problems

Not all project team members are responsible for discovering and fixing accessibility issues, but everyone’s contributions are important! As you get better at communicating about the problem, the faster it will get fixed. Some tools    include:

  • Document steps to replicate the problem. Include the page, the section, and the elements before and after the element with the problem.
  • Capture screenshots. This should show the area just above and below the element. When pasting this into a report or email, add alternative text.
    • Bonus tip: use the “snip in 10 seconds” for areas that may disappear before you can take your screenshot.
  • Describe the expected behavior. Sometimes the person receiving the information is not familiar with keyboard accessibility. Repeat the steps to replicate the problem but reword with how it should operate.
  • Reference the relevant WCAG criteria. For some situations, sharing the specific part of Minnesota’s accessibility standard can help support getting it fixed more quickly. 

Learn More

People are not born knowing how to do a keyboard accessibility test! This is something I learned by studying and practicing. You can gain these skills too! Here are some resources to get you started.

Why to test using just a keyboard

Write better requirements, design

Practice testing

Subscribe to our Newsletter

Would you like to learn more about the accessibility work being done by Minnesota IT Services and the State of Minnesota? Once a month we will bring you more tips, articles, and ways to learn more about digital accessibility.

Subscribe Today



back to top