0

I have a container div whose first child element is another div which acts as a button. The container has one or more additional child elements.

The inner button div is always in the tab order. Our application has a "screen reader mode", and when that is enabled, we also include the outer container div in the tab order. The motivation for this is that we want screen reader users to be able to tab to the whole container, and hear all of the contents read out in order.

The problem is - if the user tabs to the container div and presses the spacebar, the screen reader moves the focus to the child button div, and executes the click action. This happens whether or not the button div has a role of "button". (I'm seeing this happen with JAWS and NVDA. It only happens when the screen reader is running).

Suffice it to say -- we have a complicated UI, and this introduces problems that we'd like to avoid.

Why is this happening? Is there anything I can do to prevent it from happening? I'm open to hacky workarounds. 

<div class="container" tabindex="0">
  <div role="button" title="tooltip" sys:command="command" tabindex="0">
    //Main Content
  </div>
  <div tabindex=0>
    //Secondary Content
  </div>
</div>
AZT
  • 1
  • 1
  • 1
    Why not use a button for the content that behaves like a button? Semantics matter a lot for screen readers. Could you give a more 'real world' example of how this widget would be used as if it is just an attempt to associate text with a button then you are over thinking it, a screen reader user will understand the relationship simply by the order of items in the DOM (or add a heading to each section to split them up if you are trying to split several controls into sections). – GrahamTheDev Oct 05 '19 at 09:41

1 Answers1

1

You need not and must not set the tabindex on this div. Screenreaders have other shortcuts than the tab key (which normally read through focusable elements only) to read non focusable elements.

For instance the description of the browse mode states that

In browse mode, the screen reader cursor can be placed on every element on a website, even on those which aren't inherently focusable, for example headings (<h1>, <h2>, etc.) or paragraphs (<p>).

Adam
  • 17,838
  • 32
  • 54
  • Sorry, I don't understand what you're suggesting. How can I make elements navigable in browse mode? How is the "screen reader cursor" manipulated, other than by arrowing and tabbing? I have a feeling this won't work for container divs that do not have a role. – AZT Oct 04 '19 at 14:15
  • Allowing focus on the div implies some functionality. Since this container doesn't have a function, its ability to receive focus creates your above described problem. If you want screen reader users to know there are multiple elements within the container you could use the `role="region"`, and `aria-label` it with something descriptive. [w3's aria landmarks][1] The core of the issue is wanting to allow users to tab to a container. That role of region didn't change anything in my tests. If you can find an example of a focusable container that might help. – Taylor N Oct 04 '19 at 15:33
  • @AZT WebAIM has a [NVDA shortcuts list](https://webaim.org/resources/shortcuts/nvda). Screenreaders can read all the text. – Adam Oct 05 '19 at 09:32