使用 JAWS 时如何使 div 元素可通过箭头键导航

Question

I would like to make a div element navigable by arrow keys when JAWS is running. The div should not be navigable using the TAB key; so using tabindex is not applicable.

Here is an example snippet of the html/reactjs structure.

const label1 = 'First label';
const label2 = 'Second label';
const prefix = 'Prefix';
const suffix = 'Suffix';

const screenReaderText = `${prefix} ${label1} ${suffix} ${label2}`;

return (
  <>
    <h1>Heading</h1>
    <div className="container" aria-label={screenReaderText}>
      <div aria-hidden="true">{label1}</div>
      <div aria-hidden="true">{label2}</div>
    </div>
    <footer>Footer</footer>
  </>
);

The two nested div should not be available to the accessibility API; hence the use of aria-hidden="true" . The div with className="container" should be navigable by arrow keys when using JAWS. Moreover, when navigating to the container div , JAWS should read out a label which is a combined and modified text of the contents the two inner div .

The navigation flow should be: h1 -> container div -> footer

I am guessing I should apply an appropriate role to the container div . The tree role gives the desired effect, but reading about it suggests that it is not best practice for this use case.

Answer 1

What are you navigating to when in the <div> if the child elements have aria-hidden="true" ?

If you want the arrow keys to work then you need a role on your <div> that will cause JAWS (or NVDA) to automatically switch from browse mode to forms mode. The valid roles that do that are listed here: https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#x6-1-fundamental-keyboard-navigation-conventions

Answer 2

To avoid confusion about “navigating” the element: You want a screen reader to read the text in browse mode like regular text, which JAWS already does by means of the arrow keys, line by line.

Also, the whole text Prefix Label1 Suffix Label2 should be in a single line, even though it's visually presented in separate lines.

If you want text to be exposed only to assistive technology like screen readers, the famous visually-hidden CSS class comes into play (fka sr-only ).

There's a great explanation on how it works by Scott O'Hara: Inclusively Hidden

 /* ie9+ */.visually-hidden:not(:focus):not(:active) { clip: rect(0 0 0 0); clip-path: inset(50%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; }

 <h1>Heading</h1> <div className="container"> <div class="visually-hidden">Prefix Label1 Suffix Label2</div> <div aria-hidden="true">Label1</div> <div aria-hidden="true">Label2</div> </div> <footer>Footer</footer>

Why not aria-label ?

The accessible name of an element, provided by means of aria-label or aria-labelledby is not announced in browse mode (when reading).

It is only used to build the lists of, fe headlines or landmarks, and in form mode, when navigating with Tab .

By default, the accessible name is built from the text contents, so using visually-hidden is taken into account, should you add a role or interaction.

Mismatch between visual and accessible text

Since the text in your question is probably not the one used in production, I'd like to point out that it's important to not divert too much between visual text and text accessible to assistive technology.

A lot of screen reader users are sighted, and rely on the two matching.

For example, visually presenting the two labels in two separate lines creates the expectation for JAWS users that they'd need to use arrow down twice, not once.

Also, how are sighted users making sense of the two labels without a screen reader, if prefix and suffix are missing?