Re: Current PFWG thinking on ARIA integration in host languages

Sorry this reply took a couple weeks, it was a while before we could get
the necessary group discussion. This reply is just to indicate our
current thinking, but we haven't worked out the details yet. I have
travel coming up and probably will be slow to respond to any follow-ups
as we need to take the time to work out the language for the spec.

Anne van Kesteren wrote:
> On Tue, 18 Aug 2009 18:53:54 +0200, Michael Cooper <cooper@w3.org> wrote:
>> 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.
>
> So in case a role is specified (and wins) I assume states and
> properties also "win" but they may not if the role is not specified?
>
> E.g. in order to report to AT that
>
>   <input type=checkbox checked aria-checked=false>
>
> is in fact not checked I would have to do
>
>   <input type=checkbox role=checkbox checked aria-checked=false>
>
> Is that correct?
You raised a good question that got us started looking at a few
potential inconsistencies in how roles and ARIA states and properties
interact with host language semantics. We think we have a direction for
addressing this but don't have anything written up yet. I don't feel
able to summarize it right now but hope to have more information in a
couple weeks.
>
>
>> 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.
>
> Would it be possible to list some of these use cases?
One example (though possibly overcome by events in context of the answer
to your next question) is a radio button that would have the
"menuitemradio" role. The view is that the radio button is the closest
host language element and therefore the best one to use, yet it needs
the override.
>
>
> Could you perhaps explain why the approach in
>
>   http://hsivonen.iki.fi/aria-html5-bis/
>
> e.g. having strong and weak semantics was not workable? I am
> personally in favor of that approach as it makes things align more
> closely with the native semantics of HTML elements.
When we discussed host language integration at a meeting several weeks
ago, we came to the conclusion that role always needed to take
precedence over host language semantics. However, various discussions
since then have led us back to the understanding that some elements
should not be overridden. We are planning to add to our host language
integration approach the ability for host languages to define strong
native semantics that cannot be overridden with roles. We believe this
will end up similar to the proposal that Henri made.

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/>