AXSubrole for many ARIA roles should be <nil>, not AXUnknown
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: nlapre, Unassigned)
Details
For many ARIA roles, Firefox exposes the AX subrole AXUnknown (see NSAccessibilityUnknownSubrole) when the ARIA spec calls for <nil>. For instance, consider the generic ARIA role (though there are many others). See also this comment on another issue, which reads:
For many (all?) of the roles in the Core-AAM for which the AXSubrole is specified as "<nil>", Firefox exposes AXUknown. Safari and Chrome expose no subrole. Not sure how much that matters functionally, but it's leading to official test failures. <insert shrug here>
For what it's worth, I think these official test failures are confined to the "manual" web platform tests, though I imagine it will eventually be on an official dashboard somewhere.
After a brief discussion with :morgan about it, I understand that we may do some special "unknown" subrole handling here, which is probably worth considering.
|
||
Comment 1•1 year ago
|
||
This is a good idea as long as it doesn't affect VoiceOver. Sometimes the AAM spec and the de-facto implementation diverge. But if they are in harmony in this case, and I assume so because Safari and Chrome expose nil, than go for it.
Description
•