Keyboard Accessibility

Keyboard accessibility is one of the most important aspects of web accessibility. Many users with motor disabilities rely on only using a keyboard to access content. Screen reader users who are blind or vision impaired will also use the keyboard to access and interact with content.  Here are some general best practices.

Users Should Have the Ability to Navigate Using Only the Keyboard

Natively-Accessible Keyboard Elements:

By default, users can navigate to links, buttons, and form controls with a keyboard. These elements are natively-accessible by using the following keystrokes.    

  • Tab: Navigate to links and form controls.

  • Shift + Tab: Navigate backwards.

  • Enter: Activate links and buttons.

  • Spacebar: Activate checkboxes and buttons.

  • Arrow keys: Radio buttons, select/dropdown menus, sliders, tab panels, autocomplete, tree menus, etc.

Keystrokes  Accessible Only Through a Screen Reader:

  • In addition to the natively-accessible keystrokes, screen reader users have many other keystrokes available to them to help them navigate through a webpage. For example they can use the “H” key to tab through all the headings on a page. 

Landmarks and Roles

  • Break the web page into areas/regions and assign landmark roles. Use HTML 5 in combination with ARIA roles.   

  • Assistive technologies such as screen readers provide shortcut keys to navigate through page elements that have been defined as landmarks/regions and roles, or to jump to specific structural elements (for instance, M for the main content), and/or provide a list of all structural elements in the document.

  • Screen readers provide a list of all landmarks/regions on a page and shortcut keys to navigate among them.

  • Screen reader users can also navigate by landmark role.

Here is an example:

<header role="banner">    <p>Put company logo, etc. here.</p> </header> <nav role="navigation">    <ul>       <li>Put primary navigation here</li>    </ul> </nav> <main role="main">    <p>Put main content here.</p> </main> <footer role="contentinfo">    <p>Put copyright, and footer related content , etc. here.</p> </footer>

Common Landmarks and Roles

Provide other landmarks and roles as needed to specify areas/sections on a webpage. 

banner

Site-orientated content, such as the name of the web site, title of the page, and/or the logo.

<header role="banner"> </header>

main
The main or central content of the page.
<main role="main"></main>

search
This section contains the search functionality for the site.
<form role=”search”></form>

article
Stand-alone content that makes sense out of context from the rest of the document.
<article role=”article”></article>

complementary
Supporting content for the main content. For example, related links in a sidebar.  
<aside role=”complementary”></aside>

contentinfo
Informational child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.
<footer role=”contentinfo”></footer>

Buttons and Role Attribute

Most HTML elements have a default role that is presented to assistive technology. For example, a button has a default role of "button" and a form has a default role of "form". 

Always use the native button role so that keyboard only users are able access/select the buttons by using the tab and enter keys. 

Example:

<form action="/action_page.php" method="get" id="form1"></form> <button type="submit" form="form" value="Submit">Submit</button>

But there are also buttons that are created that are not using a form element, just a regular hyperlink. Add a role attribute to those types of button links to help screen reader users identify the purpose of the link and for them to quickly be able to tab to all the buttons on the page by clicking on the “B” key. 

Example:

<a href="#" role="button" onclick="" class="btn btn-primary"><span>Apply Online</span></a>

 

Add a Keyboard Focus Indicator to Menu Items, Buttons, Links, Form Elements 

  • A keyboard user typically uses the Tab key to navigate through interactive elements on a web page—links, buttons, fields for inputting text, etc. When an item has keyboard "focus", it can be activated or manipulated with the keyboard. 

  • A sighted keyboard user must be provided with a visual indicator of the element that currently has keyboard focus. For example a border or outline.

  • Browsers will by default provide a visual border around these elements when they are in focus. Usually a blue border or dotted outline. However the default style may not provide enough color contrast between foreground and background. In other cases the outline may not be visible as the element may have already been styled with a specific border or outline or made invisible.   

  • Apply a keyboard focus outline that has sufficient color contrast by using the following CSS attribute, 

A:focus

Example:

Ensure that Keyboard Users are Not Trapped

Ensure that content does not "trap" keyboard focus within subsections of content on a Web page.

There may be times when the functionality of the Web page restricts the focus to a subsection of the content. When this is the case, keyboard users should be provided with a mechanism to leave that state and "untrap" the focus by using only the keyboard.

Ensure that Keyboard Interactions and Functionality are Predictable

When a user interface component receives keyboard focus, it should not initiate or trigger a change of context.

For example:

  • forms should not automatically be submitted when a form element receives keyboard focus;

  • new windows or popups should not be launched when a component receives keyboard focus;

  • focus should not unexpectedly be changed to another component when that component receives keyboard focus;

Users should be provided with a mechanism to initiate the change of context.

Ensure Keyboard Users Can Accurately Interpret and Parse Content

Ensure that content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

Testing for Keyboard Accessibility

 

https://sfgovdt.jira.com/wiki/spaces/SFGOV/pages/1917157453