ISSUE-466: Ambiguity over whether some roles should override native semantics
Inconsistencies in role overriding
Ambiguity over whether some roles should override native semantics
- State:
- CLOSED
- Product:
- ARIA 2.0
- Raised by:
- Matthew King
- Opened on:
- 2011-10-27
- Description:
- Some implementations include a concept of weak roles that do not override native semantics. This concept is not clearly defined.
See thread:
http://lists.w3.org/Archives/Member/w3c-wai-pf/2011OctDec/0090.html
and
http://lists.w3.org/Archives/Member/w3c-wai-pf/2011OctDec/0092.html - Related Actions Items:
- No related actions
- Related emails:
- No related emails
Related notes:
UAIG is ambiguous on what "not mapped" means. For ARIA 1.0, UAIG will clarify that not mapped means the UA may use the native role or override it. Need Authoring Practices Guide to caution authors against using certain ARIA roles (is it only landmarks?) on elements that have semantics (anything that is not a <div> ).
This needs to be addressed in ARIA 2.0.
Both the spec and UAIG contain these two statements:
Except for <a few cases outlined in later text>, user agents MUST always use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, rather than using the host language semantics.
When a WAI-ARIA role is provided, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes that are explicitly forbidden on the native element by the host language.
The requirement for user agents to use the WAI-ARIA role instead of the native role was only intended to apply in cases where there is a direct mapping to a role in the accessibility API. The requirement, however, is not clear in the WAI-ARIA spec and has been interpreted differently by implementers. The WAI-ARIA 1.0 UAIG will contain a clarification and an editorial note to explain this difference as follows. In addition, authors will be advised against using such WAI-ARIA roles on native elements that have their own semantics. This issue will be reassigned to ARIA 1.1 or ARIA 2.0 to be reconsidered.
<ARIA spec>
When a WAI-ARIA role is provided, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes that are explicitly forbidden on the native element by the host language.
</ARIA spec>
<UAIG>
When a WAI-ARIA role is provided <add>that has a corresponding role in the accessibility API</add>, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes that are explicitly forbidden on the native element by the host language.
</UAIG>
and the following sentence has been added to the end of the paragraph
"When a WAI-ARIA role is provided that does not have a corresponding role in the accessibility API, user agents may expose the native semantic in addition to the WAI-ARIA role."
The following editorial note has been included:
"Note that the above text differs slightly from the WAI-ARIA specification. The requirement for user agents to expose the WAI-ARIA role was intended to only apply in cases where there is a direct mapping to a corresponding role in the accessibility API. The wording of the requirement is not clear in the WAI-ARIA specification, however, and has been interpreted differently by implementers. The requirement has been clarified here and an additional statement added to indicate that user agents may expose native semantics if there is not a direct mapping to a role in the accessibility API. Because there are differing implementations, authors will be advised against adding such WAI-ARIA roles to native elements that have their own semantics in the WAI-ARIA Authoring Practices Guide."
Display change log