The difference between keyboard and screen reader navigation


18/5000
한국어 번역

People often include screen reader users in the much larger group of keyboard-only users. Whilst this is correct (most screen reader users don’t use a mouse), it also creates a false impression of the way screen reader users navigate content.

To help explain this, I’m going to generalise and refer to the two following groups of people:

  • Keyboard users: people who don’t use a mouse but can see the content.
  • Screen reader users: people who don’t use a mouse and can’t see the content.

This is a massive over-simplification of the different groups, but the ability to see the content or not is the crux of the difference in navigation.

Keyboard navigation

Keyboard users navigate through content using a limited set of keyboard shortcuts:

  • The tab key moves to the next focusable element (like a link, button, or form field) and scrolls it into view if it wasn’t already contained within the viewport. The shift and tab keys together move to the previous focusable element.
  • The space key scrolls the next chunk of content into view, and the shift and space keys together scroll the previous chunk of content into view. The pagedown and pageup keys do the same things respectively.
  • The home key brings the top of the page into view, and the end key brings the bottom of the page into view.

This isn’t a very refined way of navigating content, and it isn’t without problems, but it generally works if you can see the content as it moves into view. That, of course, is where screen reader users come unstuck.

Screen reader navigation

Apart from things like live regions, screen readers only speak the content they’re focused on, and here we need to draw an important distinction: keyboard focus and screen reader focus are not the same thing!

Keyboard focus is restricted to tabbing between focusable elements. If a screen reader user uses the tab key to navigate content, all they will hear is the name of each focusable element as it receives keyboard focus. What they won’t hear is all the other content like text, headings, and images.

When using the tab key, keyboard focus and screen reader focus are synchronised with each other. The rest of the time, screen reader users have an enormous range of commands at their disposal for reading and navigating content independently of keyboard focus. The commands vary between screen readers, but they all have one thing in common: they’re tied to different HTML elements. There are commands for moving screen reader focus between things like headings, images, paragraphs, sectioning elements, lists and listitems; for moving between tables, as well as the rows and columns inside them; for moving to specific types of form field, like checkboxes, radio buttons, text fields, or buttons; and many more commands besides.

You can see a screen reader in action in this Smashing TV webinar. It’s a little long, but there’s a short extract available too.

Whether someone is a keyboard user or a screen reader user, the importance of HTML cannot be emphasised enough. Without well-formed HTML that uses the appropriate element for the purpose, screen reader navigation breaks down completely, and keyboard navigation is at a high risk of doing the same.

6 comments on “The difference between keyboard and screen reader navigation”

Skip to Post a comment
  1. Comment by Digital A11Y

    Leonie,
    Sometimes I observed it is not possible to activate a link or button when screen reader is turned on & without screen reader only in keyboard navigation it kind of works ok… Any specific reason for this? The same is observed on mobile too where an element doesn’t get activated when double tapped but when assistive tech is switched off it works…

    1. Comment by Léonie Watson

      One reason is that something interferes with the command or gesture before it reaches the browser/content. This can be caused by things like the event handler being attached to the wrong element, particularly with custom controls; by Jaws sending a click event on buttons (instead of a keyboard event), which can sometimes be unexpected; or by screen readers intercepting key commands, and only sending them back to the browser if it doesn’t need them.

      A quick test for the last one is to use the pass-through command/gesture for the screen reader in question. This will tell the screen reader to ignore the next key press after you use the pass-through command/gesture, and send it back to the browser: For Narrator, press the modifier key (capslock) then m, followed by enter; for NVDA, press the modifier key (insert or capslock) then f2, followed by enter; for Jaws, press the modifier key (insert or capslock) then 3, followed by enter; for VoiceOver on iOS, double tap the control and hold your finger down, then tap once with another finger elsewhere on the screen.

  2. Comment by Yong Ui Lee

    Hello, Leonie.
    I’m YongUi Lee from Korea.

    I enjoyed your article and want to share with korean who is interested in a11y.

    Can I translate your article and share in my personal blog?

    I started bloging recently for sharing good overseas articles.

    This is my first and recent translation.
    https://web-for-all.tistory.com/2

    I look forward to hearing from you.
    Thanks.

    Yong Ui Lee

    1. Comment by Léonie Watson

      Yong Ui Lee,

      I am happy for you to translate this article. Please let me have a link to the translation when it is available, and I will link to your post from here.

      1. Comment by Yong Ui Lee

        Thanks for your permission.

        Here is the link!
        https://web-for-all.tistory.com/4

        Can I translate your another article without leave a comment?
        If it is possible, I’ll leave the link of translated article in my blog when I’m done.

        1. Comment by Léonie Watson

          Yong Ui Le, I sent you an email but maybe it didn’t reach you? Please translate any of my articles, but send me a link to the translation so I can link to it from my blog (like I have done with this article).

Comment on this post

Will not be published
Optional

This site uses Akismet to reduce spam. Learn how your comment data is processed.