Re: Using ARIA to override semantics

Jonas,

For HTML 4: http://www.w3.org/wai/pf/aria-implementation  For ARIA 1.0 and
HTML 4.x all ARIA roles can override anything. We have added some
restrictions in HTML 5 based on the change proposals from Steve which now
also includes the chairs decisions.

For HTML 5: We have defined host language semantics in section 3.2.6 in
terms of ARIA. Where it has host language semantics you can see how it maps
to platform accessibility API here:
http://dev.w3.org/html5/html-api-map/overview.html#

Section 3.2.6 states what roles are allowed to overrided the default host
language semantics. When that happens the new role is assumed and you can
refer to the role mapping in the link supplied above.

Hope this helps.

Rich


Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Jonas Sicking <jonas@sicking.cc>
To:	Steve Faulkner <faulkner.steve@gmail.com>
Cc:	Sam Ruby <rubys@intertwingly.net>, HTML WG
            <public-html@w3.org>, "W3C WAI Protocols & Formats"
            <w3c-wai-pf@w3.org>
Date:	03/18/2011 08:55 PM
Subject:	Re: Using ARIA to override semantics
Sent by:	public-html-request@w3.org



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