Conditional role mapping of role=form element based on accessible name
Categories
(Core :: Disability Access APIs, enhancement)
Tracking
()
People
(Reporter: spectranaut, Unassigned)
References
(Blocks 1 open bug)
Details
Steps to reproduce:
In OSX, open an html file that includes an unnamed form element in Firefox, such as:
<div role="form">Form contents.</div>
Use the accessibility inspect tools to see the AXSubrole of the role=form element.
Actual results:
The element has a landmark AXSubrole
Expected results:
The element should have no AXSubrole
See the relevant changes in CORE-AAM here: https://github.com/w3c/core-aam/pull/97
|
Reporter | |
Comment 1•2 years ago
|
||
I only describe the bug for the OSX CORE-AAM mappings, but the others will have to be updated as well!
|
||
Comment 2•2 years ago
|
||
As a side note, Firefox already behaves like this for <form> without a name precisely to avoid the landmark cluttering described in https://github.com/w3c/core-aam/issues/11#issue-325089950, but we currently treat role="form" differently. I'm curious as to why this change is necessary for role="form", given that the problematic examples all covered issues with <form>, not role="form". Is it just consistency?
|
|
||
Updated•2 years ago
|
|
|
||
Comment 3•2 years ago
|
||
See also the discussion in https://github.com/w3c/core-aam/issues/100
Description
•