allo
allo

Reputation: 83

NVDA screen reader reads clickable word on text

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

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

NVDA will read clickable testing

Upvotes: 4

Views: 7202

Answers (4)

Nicu Surdu
Nicu Surdu

Reputation: 8351

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.

Upvotes: 0

Hrvoje Golcic
Hrvoje Golcic

Reputation: 3696

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:

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 (a.g. deleting currently focused table entry) or moving a focus to an error summary heading after a form submit trial etc.

Upvotes: 0

Camilo Rincon
Camilo Rincon

Reputation: 111

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

Upvotes: 1

Skerrvy
Skerrvy

Reputation: 912

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.

Upvotes: 0

Related Questions