- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 18 Aug 2009 20:42:53 +0200
- To: "Michael Cooper" <cooper@w3.org>, "HTML WG" <public-html@w3.org>
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? > 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 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. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 18 August 2009 18:43:43 UTC