0

I am trying to improve a website's accessibility, and I am coming across some issues making things work for both mobile (VoiceOver and TalkBack) and on desktop using NVDA. I am trying to use the Bootstrap Popover widget for a text input, as seen here:

https://codepen.io/gspan/pen/qBEPZOY

<label class="form-group name" for="name">
    Name
    <div class="wrap">
        <input name="name" id="name" class="form-control" value="" type="text" aria-describedby="nameInfo" />
        <div id="nameInfo" tabindex="0" data-trigger="hover focus" data-toggle="popover" data-placement="bottom" data-content="Name Content Popup Here" aria-label="Name Content Popup Here" aria-hidden="true"></div>
    </div>
</label>

My desired functionality is:

  1. For a keyboard user (with no assistive technology) to be able to tab over to the info icon in order for the popover to show.
  2. For a screen-reader user (mobile or desktop) to have the focused input read the content of the popover without needing an additional jump to the icon itself, and then have the icon hidden from the screen-reader focus.

I have addressed #1 with a tabindex on the popover div, and #2 by linking the input and popover with aria-describedby and hiding the icon with aria-hidden.

My issue is that specifically on NVDA it will still focus on the info icon, and read it out as "blank". It will focus and read the content correctly if I remove the aria-hidden, but then it causes the user an unnecessary additional focused item they need to get through.

This is only happening on NVDA, on every browser I have tried (IE, Edge, Firefox, Chrome). Does anyone have a suggestion for getting around this?

Thanks in advance!

Nihil
  • 1
  • 1

2 Answers2

0

Have you tried with JAWS? Anyway, I don't think this is related to any particular screen reader. As long as you can tab on it and it can receive focus this way, the screen reader will try to read it. I suggest you let the "keyboard user" use his pointing device: nobody will actually want to tab over to such an element, even more, if you have a form with multiple inputs, tabbing from one input to the next one without the need to step over such info element is welcome.

So: simply use -1 for tabindex on the icon. Users with pointing devices will be able to focus it, while the screen readers will actually skip it, because it will be out of the reach of the tab navigation.

ZorgoZ
  • 2,974
  • 1
  • 12
  • 34
  • JAWS is functioning as intended, as are VoiceOver and Talkback. Only NVDA is acting in this manner, which still needs to be supported. We also still need to support users who are only using tab-navigation with no screen reader or pointing device, which will not work with tabindex="1" – Nihil Dec 30 '19 at 20:24
  • @Nihil then contact NVDA developers and open a ticket. – ZorgoZ Dec 30 '19 at 20:25
  • @Nihil Check this: https://github.com/nvaccess/nvda/issues/2117 It looks to be realted to the element that is created dynamically. That one has no aria-hidden added! – ZorgoZ Dec 30 '19 at 20:29
0

I've tested your CodePen using Chrome 94 and NVDA 2021.2 and JAWS 2020:

NVDA 2021.2 & Chrome 94 Focus on <input> field, NVDA reads: "name name content popup here edit name content popup here blank". Focus on <div> popup with tabindex="0", NVDA reads: "name content popup here".

JAWS 2020 & Chrome 94 Focus on <input> field, JAWS reads: "name edit name content popup here" Focus on <div> popup with tabindex="0", JAWS reads: "name content popup here edit".

So, when focus lands on the <input>, NVDA is reading the label of the input, followed by the text inside the popup (the value of data-content) linked to the <input> with aria-describedby, followed by the aria-label text. I'd recommend dropping the aria-label on the popup; it's redundant.

Secondly, the popup has an explicit tab stop with tabindex="0" so JAWS and NVDA will follow the tab order of the page, even though you've hidden it with aria-hidden="true". All that aria-hidden is doing is confusing the screen reader; hence the discrepant speech for JAWS and NVDA when focus lands on the popup. I would drop aria-hidden="true" for the popup, because although it's redundant to have the popup text read by aria-describedby as well as when focus lands on the popup button, it's better than the more confusing option of trying to hide it with ARIA and causing confusion to the screen reader users.

As a side note, when I test applications and encounter similar information popups like the one you've shown us, I usually recommend that they be made accessible, both to keyboard users and screen reader users, because you want to try and offer the same user experience to everyone. I disagree with ZorgoZ that users wouldn't want or need to tab to the popup element; many users with mobility impairments don't use pointing devices and rely exclusively on the keyboard accessibility of elements to access them.

George Chapman
  • 462
  • 2
  • 9