Re: Using ARIA to override semantics

The only implementation requirements I see in that link is:

"The implicit ARIA semantics defined below must be recognized by
implementations".

However it doesn't appear to define what "recognize" entails. If the
answer is that ARIA semantics should be recognized to the same extent
as "native semantics" for various elements then that leads to the
whole set of followup questions that I posed in the original email.
Including the questions about if we should add APIs that better expose
semantics as well as deprecated APIs that expose semantics but doesn't
take ARIA into account.

So I'm not saying that it is unclear what edits the WG decision is
calling for. What I'm trying to understand is how those edits affect
me as an implementer as well as someone interacting with web authors.
This is why I started a separate thread rather than continuing the
thread on the WG decision.

Hope that helps.

/ Jonas


On Fri, Mar 18, 2011 at 4:05 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> On 03/18/2011 06:21 PM, Jonas Sicking wrote:
>>
>> Hi All,
>>
>> This is an email I've been meaning to write for a while, and with the
>> recent decision by the chairs on ISSUE-129 it's become more urgent.
>>
>> Now that ARIA is allowed to override the built-in semantics of various
>> elements in HTML, how does this affect implementation requirements?
>> One concern that I have is that it seems fairly undefined what the
>> implementation requirements are for markup like
>>
>> <a role=button href="...">
>>
>> For example, should the context menu for a link or for a button be
>> displayed if the brings up a context menu (for example by
>> right-clicking the element). What about if the user presses "enter"
>> when the<input>  element is focused in markup like:
>>
>> <form><input><a role=button onclick="..." href="...">submit</a></form>
>>
>> If a real<button>  had been used in the above markup I think firefox
>> would activate that button (if we don't please file a bug). What about
>> if the browser has a feature to display all links on a page. Should a
>> <a role=button href="...">  be included in such a list?
>>
>> In short, there is a lot of non-AT related code in user agents that
>> act on the semantics of the various elements in a page. In Firefox we
>> generally act on the native semantics of elements by looking at their
>> names. Is it expected that we rewrite all such code to instead look at
>> the roles? Does this also apply to other HTML consumers other than
>> browsers?
>>
>> Additionally, how does this affect scripting libraries? Should they
>> stop looking at element names and instead look at their roles? Should
>> we then deprecate APIs like getElementsByTagName and instead introduce
>> something like getElementsByRole? Deprecate in this context would mean
>> adding a warning to the developer console any time the API is used, as
>> we've done in the past when attempting to remove API from the web
>> platform.
>>
>> Further, what is the effect on conformance checkers? A<button>  is
>> normally allowed to contain a<video>, but an<a>  is only sometimes
>> so. What should the conformance rules for<a role=button>  be?
>>
>> If the answer is "yes, you should look at roles rather than names",
>> has this been discussed with HTML implementors (browsers, conformance
>> checkers and otherwise), and/or script authors? It seems like a pretty
>> fundamental change to the way HTML, and markup languages in general,
>> works, and so I would think buy-in from the various stake holders
>> would be beneficial.
>
> Can you point out specific points where the following is unclear:
>
>  http://www.html5accessibility.com/tests/aria-changes.html
>
> As a concrete example, I see nothing in that set of changes that proposes a
> getElementsByRole API, nor anything that deprecates getElementsByTagName.
>
>> / Jonas
>
> - Sam Ruby
>
>

Received on Friday, 18 March 2011 23:22:21 UTC