Re: Current PFWG thinking on ARIA integration in host languages

On Tue, 18 Aug 2009 18:53:54 +0200, Michael Cooper <> 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?

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

Could you perhaps explain why the approach in

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.

Kind regards,

Anne van Kesteren

Received on Tuesday, 18 August 2009 18:43:43 UTC