Accessibility considerations

In order to ensure that this keyboard access is truly accessible, a few key considerations need to be made. The content on this site is made to be accessible — please feel free to try using your keyboard to navigate the site.

Focus

The keyboard focus indicator must always be visible. Do not customize it unless the modification increases the focus’ noticeability.

The browser’s focus indicator can be difficult to see in some circumstances. The image on the top shows the default state of a button. The image at the bottom left shows the focus state in Google Chrome, and the image at the bottom centre shows the focus state in Mozilla Firefox. The image on the bottom right shows the latter focus state styled to augment its visibility.
Focus indication. The browser’s focus indicator can be difficult to see in some circumstances. The image on the top shows the default state of a button. The image at the bottom left shows the focus state in Google Chrome, and the image at the bottom centre shows the focus state in Mozilla Firefox. The image on the bottom right shows the latter focus state styled to augment its visibility.

Traps

If the keyboard focus can be moved onto an element, then the focus must also be able to be moved off of that element using the keyboard. Ideally this should use the unmodified arrow or tab key commands. If a special keyboard command is required, that must be made clear to the user. When this criteria is not met, the end result is the dreaded “keyboard trap,” where the user becomes stuck on a page element, and cannot navigate away.

Shortcuts

If a page component utilizes keyboard shortcuts consisting of only standard printable characters, then those shortcuts should only be active when that page component has keyboard focus. Otherwise, the user needs to have the ability to turn these shortcuts off, or to re-map them to non-printable keyboard characters, such as [Ctrl], [Alt], etc.

Timings

In order to maintain keyboard accessibility, never require the user to perform keystrokes with specific timings. A good user interface should never feel like a test of skill.

Multiple input mechanisms

It’s important to note that although keyboard access is prioritized for accessibility, it shouldn’t be the only input mechanism that is supported. Furthermore, whenever possible allow the user to concurrently use more than one input mechanism at a time.