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.

Andi Snow-Weaver, 7 Dec 2011, 15:48:29

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.

Andi Snow-Weaver, 13 Dec 2011, 15:55:37

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


Andi Snow-Weaver, 15 Dec 2011, 00:56:19

Display change log ATOM feed


James Nurthen <w3c@nurthen.com>, Valerie Young <spectranaut@igalia.com>, Chairs, Daniel Montalvo <dmontalvo@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 466.html,v 1.1 2023/05/22 16:31:57 carcone Exp $