NVDA 屏幕阅读器读取文本上的可点击单词

Question

Any idea why NVDA reads clickable word when tabbing through text in html example:

<h1 tabindex="1"> testing </h1>

NVDA will read clickable testing

Answer 1

Short answer:

the tabindex attribute implies functionality to some screenreaders.

Long answer:

Two primary ways that a screen reader user will navigate your webpage are by skipping through interactive elements or by headings. Interactive elements are things like links, buttons, form fields and any other piece of functionality that the user will initiate on your page. These are navigated by using the 'tab' key.

The other primary way they will navigate your page is by headings. In fact, a survey from webaim lists headings overwhelmingly as the primary method of navigating a page to find information ( source ). In your example, you have given the heading a tabindex which will give the impression that it has some functionality or interactivity to it. To my understanding, both JAWS and NVDA will read out 'clickable' on elements that have a tabindex, as they could easily (and typically would) have some javascript click handlers that are not evident from the screenreader.

Answer 2

In first place remember that tabindex are not a good practice in a11y, and also headers don't need a tabindex NVDA provides a header navigation with the H key. About the clickable I can say from my experience is a known issue for NVDA, if you check that in other SR (Voice over or Chromebox) should be read properly

Answer 3

Answer:

It's because of attribute tabindex which makes this element keyboard focusable. One can focus it by pressing TAB key on a keyboard.

Hint #1: Attribute tabindex with value above 0 should be generally avoided!

Don't use tabindex="1" , tabindex="2" and so on. Only tabindex="0" or tabindex="-1" can be useful in some cases. Otherwise you can create a complete mess for a user experience.

Read more:

• Google: Using a tabindex greater than 0 is considered an anti-pattern .
• WebAIM (accessibility): This is almost always a bad idea .
• MDN: Avoid using tabindex values greater than 0 .

Hint #2: Generally no need to make focusable elements that a user cannot interact with.

As in specific case no sense to make a heading element keyboard focusable if a user cannot interact with it.

If you are concerned about screen reader users have no worries as they read non focusable content just fine. A quote from Accessibility Developer Guide : As opposed to keyboard only users, screen reader users usually do not use the Tab key to read a page! Read the "Screen readers browse and focus modes" to know the difference between navigation using Arrow keys and Tab key.

But... Exception to the rule exists

Exception to the rule exists and it's probably a good idea in cases where developers set tabindex="-1" to headings which they want the focus to be moved programmatically for the purpose of accessibility. Such cases are for example fresh content update with AJAX in single page applications. The focus would be moved to a heading for a user to get aware of the content update and to be able to start from there. Also it can be useful when currently focused content is about to get removed from the DOM (ag deleting currently focused table entry) or moving a focus to an error summary heading after a form submit trial etc.

Answer 4

In my case (VoiceOver on MacOS), it seems that H1 is announced as clickable only on Firefox. On Chrome, it's announced correctly.

This leads me to believe it's a Firefox bug.