W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: Using ARIA to override semantics

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 18 Mar 2011 18:42:52 -0500
To: Jonas Sicking <jonas@sicking.cc>
Cc: HTML WG <public-html@w3.org>, public-html-request@w3.org, "W3C WAI Protocols & Formats" <w3c-wai-pf@w3.org>
Message-ID: <OFFC198946.F1DED4A3-ON86257857.008090F7-86257857.008244D9@us.ibm.com>

Rich Schwerdtfeger
CTO Accessibility Software Group

public-html-request@w3.org wrote on 03/18/2011 05:21:38 PM:

> From: Jonas Sicking <jonas@sicking.cc>
> To: HTML WG <public-html@w3.org>, "W3C WAI Protocols & Formats"
> <w3c-wai-pf@w3.org>
> Date: 03/18/2011 05:24 PM
> Subject: Using ARIA to override semantics
> Sent by: public-html-request@w3.org
> 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?


You seem to be manufacturing some things that do not exist. The ARIA
Implementation guide states how ARIA is used to support platform
accessibility APIs. It does not specify any of the concerns that you raise.

1. I have never seen an API getElementsByRole nor have I seen such a
proposal. We should not deprecate getElementByTagName. ARIA should not be
needed if tags are used without modification due to the use of JavaScript
and CSS. In a model view controller architecture, as applied to a node, the
author changes the functionality of the element by modifying the
controller. This happens whether you use ARIA or not.

2. ARIA is not meant to change a tag name. A fundamental concept you appear
to be overlooking is that the author has used JavaScript to repurpose
existing HTML elements. ARIA simply conveys the accessibility semantics
intended by the author that are conveyed to an assistive technology. This
is clearly defined in the ARIA User Agent Implementation Guide. It Does not
provide any directive to the user agent as to how it should process HTML at
ALL. Rather, the author used JavaScript to enhance the functionality of the
page which is allowed as script is allowed on the page.
3. ARIA overrides the host language semantics defined by the tags conveyed
to assistive technologies to convey the authors intent.
4. ARIA does not impact HTML conformance checkers other than ARIA can only
applied to HTML elements were it is allowed. The chairs reached consensus
on this.
5. Accessibility test tools will test for the validity of how ARIA is
applied based on the ARIA specification and the HTML elements it is allowed
on per the HTML 5 spec.

> 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.
> / Jonas
Received on Friday, 18 March 2011 23:43:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:10 UTC