Re: Using ARIA to override semantics

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