Open Bug 1510347 Opened 11 months ago Updated 9 months ago
Removing hidden focusable elements from accessibility tree breaks twitch
.tv, vanguard .com and probably other websites
This is a regression and a follow-up from bug 1349223. Steps: 1. Navigate to twitch.tv with NVDA screen reader 2. Tab to Log in button and activate the button 3. Tab through dialog What happens: Nothing is spoken as the user tabs Expected: Fields should be spoken Note: this used to be broken in Chrome, but we recently fixed it in by adding focusable objects back into the accessibility tree so that they can at least fire events. In any hidden subtree, we only expose the focusable objects. (We don't bother exposing all the hidden parents as well.) Platform specifics: On ATK, remove ATK_STATE_VISIBLE and add hidden:true object attribute For MSAA, use STATE_SYSTEM_INVISIBLE and hidden:true object attribute For Mac, *I think* what we're doing is not exposing the hidden object as a child of anything, but still allowing events to be fired on it. I believe getting the parent would give the first visible ancestor. For Android, there is a way to expose whether something is invisible or not Here is the changelist for Chrome, so you can see what we did: https://chromium-review.googlesource.com/c/chromium/src/+/1312675
Also, the user who reported the issue said, "I've discussed with twitch and it seems like they don't care. In fact they took months to even get back to my question regarding this last year." Doing whatever is possible to expose focus seems like a possible way to help users deal with broken content.
Thanks for filing. A few points: 1. Am I correct in thinking that strictly speaking, this does not comply with the ARIA spec? Part of the reason we ended up cutting aria-hidden from the tree after so many years was various complaints from authors and AT vendors that we weren't complying with the spec (despite our belief that we were doing the right thing), which caused friction because different implementations were doing different things. Now, Chrome implementing this new behaviour has reopened this conundrum somewhat. I respect the need to be pragmatic, but I think if we're going to make changes like this, particularly given the controversial history around aria-hidden, we should try to get it clarified in the spec for everyone's sake. 2. While this does make it possible for the user to tab through hidden subtrees, they still can't review the content surrounding the focusable element, nor can they navigate in any other way (e.g. screen reader browse modes or review cursors). This assumes, then, that users use the tab key as their primary means of navigation and it only helps those users. Users who don't use the tab key as the primary means of navigation might not ever be aware that this works in these situations. Yes, it helps work around an authoring error, but only via an inconsistent and potentially difficult-to-discover experience. 3. My understanding was that Google were strong advocates for specifically allowing a presentational descendant to get DOM focus, but having a11y focus hit the nearest ancestor. If I recall correctly, there were examples in Google web apps where it was necessary for some reason to have a hidden <input> element get the focus, but semantically, that wasn't relevant. Has that perspective now changed? It's certainly in conflict with what's being proposed here.
Summary: Removing hidden focusable elements from accessibility tree breaks twitch.tv on probably other websites → Removing hidden focusable elements from accessibility tree breaks twitch.tv, vanguard.com and probably other websites
This also occurs on vanguard.com, for example if you try to add a bank account in the bank information section of your profile. It's now somewhat accessible with Chrome Canary (didn't use to be), and no longer accessible with Firefox (used to be).
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.