Re: Using ARIA to override semantics

Indeed. My question is more general than ISSUE-129. I'm trying to
understand how ARIA works in general, and specifically when ARIA roles
and native element semantics conflict.

/ Jonas

On Fri, Mar 18, 2011 at 5:36 PM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> Hi Jonas
>
>  I would like to point out that this text:
>
> "The implicit ARIA semantics defined below must be recognized by
> implementations".
>
> is not something the proposal has added in or modified it is as the HTML5
> editor specced it, So you may want to file a bug on the html5 spec in this
> regard in regards to its vagueness.
>
> Also ARIA has been implemented in firefox and other browsers for a while
> now, as implemented ARIA roles always override native semantics. Has there
> been any practical impementation issues about this raised in the Mozilla
> Camp?
>
> regards
> Stevef
>
> On 18 March 2011 16:21, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> 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
>> >
>> >
>>
>
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar -
> www.paciellogroup.com/resources/wat-ie-about.html
>
>

Received on Saturday, 19 March 2011 01:53:59 UTC