Developing for keyboard and screen reader users

Allow the user to skip over repeating content

There should at least be a skip link at the start of the page that will skip the main navigation. If there are other repeating materials or blocks on the page, you should provide a method for bypassing them as well.

Slides, accordions, and tabs require attention

Pay extra attention to make sure you can use them with a screen reader and a keyboard. These elements are very often non-accessible and/or illogical for keyboard and screen reader users.

Dynamic content should be respectful to an assistive technology user

If your website has dynamic changes on the page, make sure the information will be passed on to screen readers as well. If you use aria-live attribute, avoid using the assertive value unless it is necessary. Otherwise, it might be confusing or at least annoying. The value "polite" is usually enough.

Hiding elements from assistive technologies

If you use CSS styles visibility: hidden or display: none, the element will be also hidden from assistive technologies. The same goes when you use the HTML5 attribute hidden. I added a link to WebAIM's article about this to the bottom of the page if you want more information about this.

ARIA provides aria-hidden attribute for excluding content from assistive technologies which is not visually hidden. Applying this attribute to an element removes it and all of its descendants from the accessibility tree with the exception of any element which is referred to via an aria-labelledby or aria-describedby attribute.

Hiding an element visually but not from the accessibility tree

An element, which is not visually rendered but not explicitly hidden, is still included in the accessibility tree. For example:

.screenreadercanseethis { height: 1px; left: -10000px; overflow: hidden; position: absolute; width: 1px; }

It's also possible to provide screen reader only text via ARIA, for example with aria-label, aria-labelledby or aria-desbribedby attributes.

Tabindex

The tabindex attribute indicates that its element can be focused and where it participates in sequential keyboard navigation.

The tabindex accepts an integer as a value, with different results depending on the integer's value:

• A negative value, usually tabindex="-1"
  • not in the natural tab order
  • can be programmatically focused with focus() method
• tabindex="0"
  • in the natural tab order
  • can be programmatically focused
• A positive value, like tabindex="5"
  • in the natural tab order
  • jumped to the front of the tab order, tabindex="4" is focused before tabindex="5"
  • max value for tabindex is 32767, not that you should need it.

A negative value is useful when you have off-screen content that appears on a specific event. The user won't be able to focus any element with a negative tabindex using the keyboard.

Avoid using positive tabindex values. Using them can be confusing for screen reader users. It's better to write the document with the elements in a logical sequence.

As a general rule, you shouldn't add tabindex to your site but an exception is when you manipulate the page in response to a user action. For example, a single page app where the navigation menu items change the content on the page without doing a full page refresh. In this kind of a case, you would want to give the content headers tabindex="-1" so they don't appear in the natural tab order and call their focus method after the user has taken their action. This is called managing focus. It's a technique that keeps the user's interactive context in sync with the visual representation of the site.