1

I have a page that has several HTML elements, that are ignored and skipped when the user is navigating the page from top to bottom using tab key and a screen reader. This is something that I was able to fix by adding the attribute tabindex="0" to the divs that contain the text that needs to be read by the screen reader. some comments say that it is not the right approach to make this. Which is the recommended alternative?

I´m using Talkback on android to navigate the page and on windows both Jaws and Narrator, they all have the same behaviour, elements without tabindex are ignored, it jumps straight to <a> elements skipping the titles and texto that surrounds the <a> tag.

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
Yala Yala Herzlin
  • 552
  • 2
  • 8
  • 25
  • Why don't you just not manually add tabindex to any element and let the browser control the navigation? – Alon Eitan Dec 20 '19 at 17:23
  • @AlonEitan . that's a nice thought but that doesn't always provide a good experience for the people who actually need to use the software with disabilities – idontwantnoscrubs Dec 20 '19 at 18:40
  • @amouratoglou . it would be great if you could add in your code, or even better a link to your website so we can test it with our our assistive technology. – idontwantnoscrubs Dec 20 '19 at 18:47
  • My understanding is that you put `tabindex="-1"` on elements you want to skip, and that's it. Everything else will be read in document order. That's why common practice is to put hidden "skip navigation" links at the top of the document so that screen readers can go right to the content... See https://stackoverflow.com/a/30981602/215552 – Heretic Monkey Dec 20 '19 at 18:53
  • @AlonEitan actually that is what I have made. just wondering if this a good practice. some people say that if the element is not clickable, ie button or link, shouldnt have the tabindex , but, it works for me... so ... just wondering, will remove the blue focus that chrome adds to the div that has the tabindex and leave it like that, seems to be a correct approach, nobody yet proposed another approach. – Yala Yala Herzlin Dec 20 '19 at 19:13
  • @idontwantnoscrubs I can´t share the link because of privacy policies. – Yala Yala Herzlin Dec 20 '19 at 19:13
  • @HereticMonkey I don´t wan´t them to skip things but to rather be able to access to all the elements in the page, using tab, in sequential order that is equal to what is rendered visually. – Yala Yala Herzlin Dec 20 '19 at 19:14
  • 2
    Okay, but as Adam's answer indicates, visually impaired people usually don't navigate the page using tab. So you're already messing with their expectations. You're also messing with people who navigate pages using tab for different reasons than using a screenreader (e.g., manually impaired people who can't use a mouse). I'm going to exit this discussion, as you seem to have a goal in mind that is different from what I had thought. Good luck! – Heretic Monkey Dec 20 '19 at 19:19

2 Answers2

5

After seeing you ask several questions around the same subject there is a common theme, you need to learn how an end user would use a screen reader vs users who have mobility issues as it will make it a lot easier for you to implement accessibility going forward.

I think people get confused by the fact that all active content should be accessible via the tab key for people with mobility issues to get around the page and think that it is the only way users use a screen reader (two different use cases).

The tab key is useful for those with mobility issues who do not need a screen reader to reach active items (the real reason for 'skip links'), but they will consume the content visually so you don't need to make the content focusable (they will likely scroll the page with space or up and down arrow keys).

For PC users who use a screen reader the tab key is actually a secondary way of navigating.

In general headings, forms, landmarks (e.g. <main> or <div role="main">) and links are the way a user discovers your page content and design on a screen reader (so they may press the 1,2,3 keys in NVDA to find the level 1, level 2 and level 3 headings respectively to find the content sections they are interested in and get a feel for page structure and content (which is why it is important not to skip heading levels).

They may also navigate through the links on a page (to get a feel for the menu structure and content the page links to) which is why links need to have meaningful content (i.e. not 'click here').

Content that is not focusable is still accessible as long as your HTML is semantically correct so stop worrying about trying to make it accessible via the tab key, it is accessible via other methods and screen readers have easy methods to start reading from the current cursor position.

This PDF from Deque shows a list of common keyboard commands for NVDA that is a great starting point to learn how to use a screen reader, within 30 minutes you will soon see what actually matters for a screen reader user and it will make the rest of your accessibility journey much easier!

Golden Rule - get your semantics correct and your website will be 95% accessible by default.

GrahamTheDev
  • 22,724
  • 2
  • 32
  • 64
  • 2
    This is the more complete answer. I was confused why text elements weren't read by 'tabbing' around when I first started testing on a screen reader. Once I used a screen reader for a bit longer (both NVDA and JAWS - the most commonly used) I realized that navigating via tab isn't very useful for reading everything and is mainly for navigating interactable elements. – ChaBuku Bakke Dec 26 '19 at 14:58
  • 1
    The misconception about the use of the tab key with screen readers is so common that I think the a11y community needs to do more to clarify the expected behavior, somehow. Quite what to do, I am not sure – brennanyoung Dec 30 '19 at 10:31
3

Users with screenreaders use the tab key to go to activable elements. For standard elements (like text) they can use other navigation shortcuts which depends on their navigation mode (browse or focus mode), their screenreader, and their own preferences, for instance arrows (←↑→↓)

Adam
  • 17,838
  • 32
  • 54
  • thanks, I know this but doesn´t answer the question, just mentions what screen readers use, but if the HTML is not properly set they won´t be able to use these navigation keys... – Yala Yala Herzlin Dec 20 '19 at 19:15
  • 1
    @Amouratoglou All screenreaders read the HTML text content. It does not have to be focusable. No exception. – Adam Dec 20 '19 at 20:42
  • thanks @Adam, what is the best way to simulate, I have used only Talkback for android and it did skip some of the HTML elements! I had to tabindex it to make them work like you would expect, basically get the element read in the right order... and not skipped and completely ignored. maybe the codebase , a very long legacy, has something that im missing that makes it act like this.. cant post code here for legal reasons -contract doesnt allow- but all I can say is i'm using polymer for this app. thanks for your comments. – Yala Yala Herzlin Dec 22 '19 at 20:36