Modal dialog + bad authoring can break web accessibility (only empty document exposed)
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: jdiggs, Unassigned)
References
(Blocks 1 open bug)
Details
Steps to reproduce:
- Load https://netplan.io/ which should initially show a "Your tracker settings" dialog
- View the accessibility tree using a platform tool (e.g. Accerciser) or Firefox's "Inspect Accessibility properties"
Expected results: The dialog (at least) would be in the accessibility tree.
Actual results: The dialog is not in the accessibility tree. All that's there is a single empty document.
Impact: This page is totally inaccessible in Firefox. Orca cannot see any content. Pressing Tab within the dialog only causes the empty document to claim focus.
Note: This problem does not happen in Chrome.
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 1•3 years ago
|
||
I was trying to make a local test case, assuming it was related to the dialog itself. But couldn't reproduce it. Turns out the author put aria-hidden set to true on the body, which happens to contain the dialog too. Thanks authors!
|
||
Comment 2•3 years ago
|
||
Chrome exposes focusable aria-hidden elements, which is why this "works" in Chrome. While I understand the need to be pragmatic when it comes to repairing bad authoring, I have several concerns with Chrome's approach; see bug 1510347 comment 2. If we're going to do this, it really needs to be sorted out in the spec. There are several spec issues discussing mitigations for aria-hidden abuse, but there are still unaddressed concerns raised against all of them.
Description
•