1510347 - Removing hidden focusable elements from accessibility tree breaks twitch.tv, vanguard.com and probably other websites

Status: NEW

(Core :: Disability Access APIs, defect, P3)

Description

[Aaron Leventhal]

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

Comment 1

[Aaron Leventhal]

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.

Comment 2

[James Teh [:Jamie]]

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.

Comment 3

[Aaron Leventhal]

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).

Comment 4

[alexander :surkov (:asurkov)]

(In reply to Aaron Leventhal from comment #3)

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).

I was so reluctant to take the cutting a tree approach, mainly because the focus should never be hidden/obscured. Keeping all focusable elements within aria-hidden tree accessible looks reasoanble with me. However it adds complexity for keeping accessible tree updated. It shouldn't make a huge problem for sure, we already do similar things for role="presentation" on HTML:table. However I also recall that the behavior doesn't comply with ARIA as Jamie noticed. Is there open ARIA issue?

Comment 6

[Joanmarie Diggs]

Also occurs on https://ubuntu.com/login, at least when the "Your tracker settings" dialog appears. The document claims 0 children and has no text.