Improving accessibility of twitter.com

Thursday, 22 August 2013

Timelines are the core content of Twitter. And with device independence being one of the core principles of accessibility, we’ve spent the past quarter tuning and enhancing keyboard access for timelines. Our goal was to provide a first-class user experience for consuming and interacting with timelines using the keyboard.

The need for keyboard access isn’t always obvious. It’s sometimes considered a power or pro user feature, but for users who are unable to use the mouse, keyboard access is a necessity. For example, visually impaired users often rely entirely on the keyboard as the mouse requires the user to be able to see the screen. Other users suffer physical injuries which make it either impossible or painful to use the mouse. In The Pointerless Web, @slicknet tells a personal story about how the keyboard became essential for him as a result of his RSI.

The list of use cases is endless. What’s most important is to remember that humans are all different, and because of our differences, we all have different needs. The more options we have as users, the better. Through that lens, the importance of the keyboard is elevated as it offers another option to the user.

Keyboard shortcuts

Since the introduction of our keyboard shortcuts in 2010, users have been able to navigate through timelines using the j and k keys to move the selection cursor up or down. With a clearer understanding of the people who benefit from keyboard shortcuts, we were able to identify and fix gaps in our implementation.

Our goal was to provide a first-class user experience for consuming and interacting with timelines using the keyboard.

A lack of focus

The first and most egregious problem when we started to tackle this was that the shortcuts for timeline navigation didn’t manipulate DOM focus. Specifically, when the user pressed j or k, a Tweet would only be rendered visually selected through the application of a class. This meant the timeline’s selection model was out of sync with the default navigational mechanism provided by the browser, and for practical purposes, limited keyboard access to actions defined by our keyboard shortcuts. For example, you could favorite a selected Tweet by pressing f, but couldn’t easily navigate to a link within the selected Tweet as the subsequent Tab keypress would end up moving focus to some other control in the page.

To remedy this issue, the navigational shortcuts now set the tabIndex of the selected item to -1 and focus it. This enables j and k to function as macro-level navigational shortcuts between items in a timeline, and Tab / Shift + Tab to facilitate micro-level navigation between all of the various focusable controls within a Tweet. In other words, our shortcuts function as highways, and the Tab key as a local street. Further, browser-provided tab navigation is more robust in that it guarantees the user complete access to all of the actions within a Tweet. Any shortcuts we add for actions are just sugar.

Here’s a video illustrating the difference between macro- and micro-navigation.


Screen reader support

As an added benefit to focusing the selected Tweet, those with screen readers can use our shortcuts to both browse and interact with Tweets in timelines. This is because screen readers announce the content of a DOM element when it receives focus. And while screen readers provide their own set of keyboard shortcuts for navigating the web pages, they’re generic (necessarily) and therefore not as optimized as those designed exclusively for twitter.com.

Below is a video demonstrating how the content of Tweets is announced while navigating through a timeline using the j and k shortcuts. As you’ll see, we use three different combinations of browsers and screen readers:

  • VoiceOver and Safari for the Mac
  • NVDA and Firefox for Windows
  • JAWS and Internet Explorer

A more robust selected state

An audit of the the various states of Tweets revealed that the previous visual rendering of selection (a gray background) within timelines was not robust enough to support all of the necessary use cases. As a result, this limited our ability to enable keyboard navigation for certain timelines as the user would be unable to perceive an item in a timeline as being selected (e.g. the default state for Tweets in expanded conversations is a gray background).

Further, the selected state for keyboard navigation shared the the same color with the hover state. This meant users switching between the mouse and the keyboard could end up with two visually selected tweets in their timeline.

To address these issues we’ve introduced a new selection style for items in timelines that is both distinct from the hover state and robust enough to render consistently well across of all of the various states of Tweets.

Previous selection style

Improving accessibility of twitter.com

New selection style

Improving accessibility of twitter.com

With this change, you’ll notice the j and k shortcuts have an increased range (for example, navigation between Tweets in expanded conversations in timelines), and should see a visual rendering of selection where j and k were previously supported, but selection was not perceivable (e.g. the Discover timeline).

Moving forward

If you haven’t already tried using twitter.com with the keyboard, give it a try. (The full list of shortcuts is available by typing “?”) If you’ve been a longtime keyboard-centric twitter.com user, we hope you find these enhancements improve your experience consuming and interacting with timelines.

While this posts details some of the accessibility enhancements we’ve made, it by no means captures them all. We’ll post again about more enhancements that are on their way.

Lastly, we’ve found user feedback is one of the most valuable means of capturing and prioritizing enhancements and fixes. To that end we’ve created the @a11yteam account for the purpose of helping us both capture your feedback as well as broadcast the availability of improvements.