bug: adding aria labels to host and input element inside shadow root causes issues with nvda

[mwcampbell]

Ionic version:

[ ] 4.x
[x] 5.x

I'm submitting a ...

[x] bug report
[ ] feature request

Current behavior:
The ion-toggle component sets ARIA attributes, such as role and aria-checked, on both the checkbox input element and its container. This means there's more than one switch in the accessibility tree, and only the inner switch can actually receive focus or otherwise handle programmatic interaction from assistive technologies.

Expected behavior:
Only the checkbox input element should have these ARIA attributes. The container should have no ARIA attributes, like most HTML container elements.

Steps to reproduce:
This issue can be seen on the online documentation page for the ion-toggle component.

[liamdebeasi]

Thanks for the issue. Can you please clarify what issue this is causing in your application?

Adding these attributes on the host is required for VoiceOver to work properly: https://github.com/ionic-team/ionic-framework/blob/master/.github/COMPONENT-GUIDE.md#example-components-2

Additionally, since ion-toggle is a shadow DOM component, the inner switch should be in its own isolated DOM tree and should not interfere with the host attributes.

[mwcampbell]

I haven't yet decided to use Ionic in my own application, because I was reviewing the code for possible accessibility issues first. (Flawless accessibility is a must for any third-party front-end components that I use.) But I verified that the accessibility tree for the ion-toggle documentation page, as rendered by Chromium-based Edge on Windows, includes nodes for both the host element and the child input element. Both of these accessibility nodes have the role for a toggle button, but only the child one is marked as focusable. Meanwhile, the NVDA screen reader only presents the parent (host) element in its browse mode. So there isn't a single, canonical accessible element. This ambiguity is bound to cause problems. For example, if I navigate to the "Blueberry" toggle with NVDA's find command, NVDA puts its cursor on the parent element, and the child doesn't get the keyboard focus. Then if I press Tab, the focus doesn't move to the next toggle as expected, but somewhere else entirely.

[liamdebeasi]

Could you provide a code sample of the issue with steps to reproduce? Our testing with NVDA did not present these kinds of issues so I am interested in learning more about how we can improve ion-toggle.

[mwcampbell]

Rather than write my own code sample, I'll give steps for reproducing the problem using the ion-toggle documentation page.

1. Start NVDA and a Chromium-based browser (tested with the latest stable versions of Edge and Chrome).
2. Go to https://ionicframework.com/docs/api/toggle
3. Press x to jump to the first checkbox (NVDA treats toggles as checkboxes)
4. Assuming you're using the NVDA desktop keyboard layout, press Insert+NumPad 5 (with NumLock off) to report the current navigator object.
5. Press Tab.

These steps expose two problems:

1. The current navigator object should be the BLueberry toggle. Instead, it's the document, which is what has the keyboard focus.
2. Tab should move to the next toggle. Instead, it jumps to the "Open" link after all of the toggles.

I've verified that neither of these problems happen with bare HTML checkboxes.

[liamdebeasi]

Thanks for the clear instructions. I was able to reproduce the behavior. I definitely agree that this is undesirable behavior, though the process to fix this is not very clear cut.

What NVDA Does

When you press "X", NVDA grabs the first checkbox/toggle. In this case, it sees <ion-toggle role="switch"> and grabs that. When you press "Tab", Chrome moves focus to the first focusable element, which is the <input type="checkbox"> inside of your ion-toggle. To someone using NVDA, they hear "Blueberry" twice, implying that there are two toggles named "Blueberry".

If we remove aria-label and role from the host, this issue would go away. This leads to the next question: Why do we have it on both the host and the inner input element in the first place? The answer is due to how different browser engines handle focusing with the keyboard. In particular, there is a big difference between Chromium (Chrome, Edge, etc) and WebKit (Safari) that makes this necessary.

Chromium

Chromium considers checkboxes, radios, buttons, and text inputs all focusable via keyboard input. So when you press "Tab" on a page containing an ion-toggle, Chromium will focus the <input type="checkbox"> inside the shadow root of your ion-toggle. This will cause the screen reader to read the aria-label on this input.

WebKit

WebKit considers text inputs focusable, but does not consider checkboxes, radios, and buttons focusable via keyboard input. So when you press "Tab" on a page containing an ion-toggle, nothing will happen because the <input type="checkbox"> does not get focused automatically. When you use VoiceOver in Safari on iOS and you tap the ion-toggle, VoiceOver is going to read the aria-label on the host <ion-toggle> since that is what you just selected. Because the inner <input type="checkbox"> is never focused, the label on that element is never read.

Potential Solution

Unfortunately, we cannot just remove the host aria-label and role attributes altogether as that would break accessibility in Safari on macOS and iOS. One idea I had was to detect if an app is running in a WebKit environment and add these attributes to the host but refrain from adding them if an app is not running in a WebKit environment.

I need to test this idea out of course, but this could be a potential path forward. Let me know if you have any questions. Thanks!