Current PFWG thinking on ARIA integration in host languages

I agreed in last week's HTML teleconference
<http://www.w3.org/2009/08/13-html-wg-minutes#item02> to provide some
written information about how PFWG currently thinks ARIA should be
integrated in host languages, in light of concerns that have been
expressed in public comments and in discussion on this list. Our current
thinking is refined by suggestions that have come in as public comments
to the ARIA Last Call Working Draft, which have formal tracking and
reporting requirements.

We have been cautious about sharing our proposed answers to comments
because they are still in flux, and we are not yet ready to engage in
broad public discussion, given the formal tracking and reporting
requirements we have for these comments. There is, however, an
interdependency between the ARIA and HTML specifications that makes it
important to be able to coordinate on the resolution to some issues. To
enable this coordination, I will summarize the current approach we're
thinking of. It is important to understand the caveat to this - this
does not represent a final nor even yet an official position of the
PFWG. This discussion will provide provide important input to the final
position, but other sources may as well, including public comments that
we have not yet processed. We expect to continue the coordination thread
on these issues so when we do have an official response, the content
shouldn't be a surprise.

The basic question is how user agents should handle situations in which
ARIA features conflict with host language features. This may because
there are host language elements that are non-nonsensical to reclassify
with ARIA roles, or because ARIA properties might be redundant with host
language properties and in fact conflict, leading to uncertainty as to
which one is correct. Some list discussions have focused on the comment
that objects to the position in the ARIA specification that a valid ARIA
role must not be treated as non-conforming in the host language.

We agree that some host language features should not, in theory, be
reclassified with ARIA roles. This is because it might be difficult to
define the processing model for such situations (<input type="checkbox"
role="radio" />) was presented as a frequent example, or because the
host language element is semantically similar to an ARIA role and should
be used for that purpose without reclassification. On the other hand,
ARIA was developed to bridge situations in which authors were
repurposing host language elements, and it needs to be possible to use
ARIA to provide the appropriate semantic. On the third hand, host
languages evolve and provide features that previously authors could only
achieve with repurposed elements. On the fourth hand, legacy content may
include ARIA repurposing of elements that would not be required in newer
content using the updated host language, so that would still need to be
supported even if it's no longer technically correct. We propose a set
of changes to the ARIA specification to balance these issues.

In the section on incorporating ARIA in host languages, we would add the
concept of "implicit ARIA semantics" - host language features that are
substantially the same as an ARIA feature. For example, HTML <input
type="checkbox" /> matches the ARIA role of "checkbox"; HTML 5 <article>
matches the ARIA role of "article"; the "checked" attribute (mostly)
matches the "aria-checked" state. Authors are instructed to use the host
language elements when available, not repurpose other elements with ARIA.

Because authors don't always do as they're told, we have to define what
happens when authors don't respect that rule. In the case of host
language features that have the implicit semantic of an ARIA state or
property, the host language feature wins. Authors should not be using
ARIA states and properties in these cases, and are assumed to have paid
more attention to updating the host language feature than the ARIA
feature. However, in the case of roles, the ARIA feature wins, even for
weird situations. This is because there are many use cases in which
authors need to repurpose elements with roles that we as specification
developers didn't necessarily account for. Since ARIA is intended to add
semantics particularly for these unusual situations, it is important
that ARIA roles be given precedence by the user agent.

Notwithstanding the above rule, we do agree that there are elements that
should not be repurposed with ARIA roles. Therefore we suggest that host
languages may define "strong native semantics", which are features that
should not be overridden with ARIA roles. Although the user agent still
needs to let the ARIA role override (to preserve the main use case for
ARIA), conformance checkers should raise an error or warning when ARIA
overrides a strong native semantic.

The documentation of implicit ARIA semantics and strong native semantics
is left open-ended. It would need to be in a normative document, but
which document is not defined. The HTML specification might include this
information, or the ARIA user agent information guide might do so.
Another possibility would be to create an "ARIA in HTML 5 Implementation
Guide" that would provide this information - a normative document that
could be published by the HTML WG, by the PFWG, or as a joint
publication. This is just an idea to suggest that there are options, not
any kind of commitment to any specific document.

One note about the processing of ARIA features - this mainly affects how
elements are exposed to accessibility APIs, and needs to be done in
accordance with the rules outlined above. Other aspects of user agent
processing are not constrained, because ARIA does not usually affect
styling or processing of elements. The author must separately do that in
addition to providing the ARIA information. Therefore, even in
situations where host language features are inappropriately overridden
with ARIA roles, the impact of this isn't all that great, except for
what is exposed to accessibility APIs.

It is our hope that this approach meets the needs that have been
expressed by the HTML Working Group for ARIA integration. Although there
are still situations in which we need ARIA to win, we provide a couple
mechanisms by which these can be defined as conformance errors even
though processing still follows the ARIA rules.

Michael

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>