Change Proposal: Add role attribute and enhance ARIA lexical processing guidance

Summary

Complete section 3.2.7 WAI-ARIA to provide complete language support by introducing appropriate attributes and their definitions.

Rationale

Lexical processing requirements for ARIA role, state, and property attributes are vague in HTML. While they are defined in other places, authors must know to follow a series of links to find all the requirements. This proposal provides more explicit references to additional processing requirements.

This change proposal provides the data needed to address Issue 199: Define complete processing requirements for ARIA attributes.

Details

Clarify the existing ARIA section

People seemed to be misreading the relationship of the parts of the section so this editorial change should help to distinguish them better. Add the following structure to 3.2.7 WAI-ARIA to accommodate the remaining additions.

1. Before the paragraph beginning "The following table defines the strong native semantics..." add a header "Strong Native Semantics".
2. Before the paragraph beginning "Some HTML elements have native semantics that can be overridden" add a header "Implicit ARIA Semantics".

Define ARIA attributes[1]

ARIA Role Attribute

Add a new section to 3.2.7 WAI-ARIA before the header "Strong Native Semantics" proposed above. The new section header is "ARIA Role Attribute" with the following content:

Every HTML element may have an ARIA role attribute specified. This is an ARIA Role attribute as defined by the Accessible Rich Internet Applications (WAI-ARIA) specification Section 5.4 Definition of Roles.

The attribute, if specified, must have a value that is a set of space-separated tokens representing the various WAI-ARIA roles that the element belongs to.

[Implementer only section] The WAI-ARIA role that an HTML element has assigned to it is the first non-abstract role found in the list of values generated when the role attribute is split on spaces.

State and Property Attributes

Add a new section to 3.2.7 WAI-ARIA before the header "Strong Native Semantics" proposed above and after the section "Role Attribute" proposed above. The new section header is "State and Property Attributes". The section should have the following content (known to need wording enhancement to improve readability; expectation is the implementing editor will wordsmith and check with the group before finally committing to the spec):

Every HTML element may have ARIA state and property attributes specified. These attributes are defined by the Accessible Rich Internet Applications (WAI-ARIA) specification in Section 6.6, Definitions of States and Properties (all aria-* attributes).

These attributes, if specified, must have a value that is the ARIA value type in the "Value" field of the definition for the state or property, mapped to the appropriate HTML value type according to Section 10.2 Mapping WAI-ARIA Value types to languages using the HTML 5 mapping.

ARIA State and Property attributes can be used on any element. They are not always meaningful, however, and in such cases user agents might not perform any processing aside from including them in the DOM. State and property attributes are processed according to the requirements of the sections [Strong Native Semantics] and [Implicit ARIA semantics], the WAI-ARIA User Agent Implementation Guide [ARIA-IMPLEMENTATION], and the Accessible Rich Internet Applications 1.0 [ARIA] specification.

Impact

Positive Effects

• Provides an explicit hook for ARIA in HTML 5.
• Allows forwards compatibility of ARIA roles by not disallowing unrecognized values.

Negative Effects

• Does not explicitly permit custom roles, but does not define consequences for using them aside from noting that such roles could later be defined by ARIA.

Conformance Classes Changes

This change proposal should have the effect only of clarifying lexical processing for ARIA without introducing conformance changes. It is possible conformance checkers with incorrect processing due to earlier ambiguity would need to be updated.

Risks

Implementers must use several specifications to arrive at a complete implementation model for ARIA in HTML 5. This increases the risk that implementations will be incomplete or erroneous.

References

This change proposal was originally drafted by Michael Cooper, and reflects an attempt to harmonize with Ted O'Connor's counter proposal according to discussion of this and Ian Hickson's critique in the 3 May 2012 HTML WG Face to Face discussion of the topic.