[button] Buttons are announced twice in screen readers

[RomkeVdMeulen]

Testing out the storybook with the NVDA screenreader I immediately notice that the buttons are read out twice (except for the button consisting only of an icon).

Inspecting the DOM, I notice that the lion-button element is given role="button". However, they also contain <button> children. These are given tabindex="-1", and indeed if I navigate by tab each button is only read out once. However since the button elements are not hidden from the a11y tree I can still navigate to them with the screenreader virtual cursor (in my case by pushing the down arrow button). The first button for example is announced as "Button default" in NVDA. Moving the virtual cursor down then announces "Button clickable".

Demo: https://js-mu9ixf.stackblitz.io (edit: https://stackblitz.com/edit/js-mu9ixf)

Affected browsers and screen readers:

• latest Chrome and Firefox with NVDA 2018.1.1 and 2019.1.1
• IE11 with JAWS

[tlouisse]

Thanks for the feedback. The native button is mainly there for compatibility with native forms and implementation of keyboard behavior (enter/space) without writing quite some js for it. I think we can probably get away with putting role=presentation on the native button

[bashmish]

Unfortunately adding role="presentation" to the native button does not make the virtual cursor (pressing Down arrow) to skip it.

@erikkroes any tip on how to fix this without full refactor of lion-button with removal of the native one from Light DOM?

[LarsDenBakker]

aria-hidden="true" should work

[bashmish]

@LarsDenBakker same, no impact on NVDA virtual cursor (tested on Chrome and IE11 on Windows 7).

I also checked if the native buttons even gets focused when Down is pressed. I was looking at changes to document.activeElement, all is in Light DOM, so must be a fair test. And it does not get focused, I guess thanks to tabindex="-1" on it, so how it gets announced I have no clue.

I also tried to reproduce this in VoiceOver on Mac or in JAWS on Windows, no luck, works well.

Looks like an NVDA bug to me.

[bashmish]

I also checked the Elements list in NVDA (btw the latest 2019.1.1), it shows only needed buttons.

And the hotkey "B" only navigates through needed buttons. So the key features work as expected with lion-button at the moment, except arrow navigation.

Since I could not find any way to prevent arrow navigation to announce this internal ("private") button and taking into account the knowledge that other screen readers don't have this problem, I think the next step is to report this problem to NVDA GitHub.

So I have to close this for now. Let's see if NVDA can help fixing this on their side.

Feel free to reopen if you know how to fix it on our side or have other ideas on how to make a lion-button more robust with all current functionality (covered in our tests) without having an extra native button in Light DOM.

[bashmish]

Interesting finding. I decided to make last quick test in IE11 on Windows 7 in NVDA (now latest 2019.1.1). In fact this is a recommended setup - to use for each OS the browser shipped with it, because screen readers are more optimised for them. And now I see that this setup does not have this problem. Not sure if this is fixed for IE11+Windows7 in 2019.1.1 (yesterday I was using 2018.1.1), or I just wrongly tested it yesterday. Anyhow, problem still exists in Chrome and also in Firefox with NVDA 2019.1.1, but exactly due to such inconsistencies and bugs they are often not recommended to be used with screen readers.

Update:
Same on Windows 10: works in Edge (old Edge, not Chromium based one), does not work in Chrome and Firefox.

[tlouisse]

Nice work. About browser/sr combinations: I think the common/recommended combinations (at least for us) are NVDA+Firefox, VoiceOver+Safari and Jaws+IE.

[erikkroes]

@RomkeVdMeulen What browser did you use?

[RomkeVdMeulen]

@erikkroes I tried again just now and can confirm @bashmish's findings: works on Windows 10 in IE / Edge, fails in Firefox, Chrome and Opera.

[RomkeVdMeulen]

Perhaps the problem occurs only in native shadow DOM implementations, but not in the polyfill used in IE / Edge?

[erikkroes]

I finally had some time to dive into this. I noticed that the button in the demo with just the icon was pronounced perfectly fine. That made me think it had something to do with how the accessible name was calculated, as this was the only button with an aria-label. Adding aria-label to the other buttons fixed those as well.
So while I agree with @bashmish that this is most likely a screen reader bug (thanks for chasing that), I also think we can circumvent it. We just have to find a developer-friendly way that preferably doesn't make them label everything twice. Thanks for bringing this one up @RomkeVdMeulen

[erikkroes]

I'm reopening this. I've found it's also an issue with JAWS+IE11. It even seems the same solution works. So I'd very much like to see this fixed.

[bashmish]

It even seems the same solution works.

@erikkroes what solution?

[erikkroes]

It seems like the issue is now fixed for NVDA, but is still there for JAWS + IE11. I've filed a bug with JAWS for this: FreedomScientific/standards-support#258
We're unable to fix this without a major restructure of the component. I'm going to make note of this as a known issue in the documentation.