W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: Questions arising from ARIA/HTML5 integration

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Mon, 24 Aug 2009 13:35:10 +0100
Message-ID: <55687cf80908240535s494561adv6315ab2acda5bfea@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Ian Hickson <ian@hixie.ch>, public-pfwg-comments@w3.org, wai-xtech@w3.org, public-html@w3.org
hi henri,
>The conclusion I drew when developing the schema prototype was that these
have native semantics that needs to be exposed to AT by the browser without
>AT in between and that it doesn't make sense to set the role attribute in
these cases.
Can you explain a bit more what you mean here?

What i would suggest is that there is a place for the use of ARIA on native
elements where appropriate until such time that these elements are correctly
exposed by browsers through accessibility APIs.


2009/8/24 Henri Sivonen <hsivonen@iki.fi>

> On Aug 22, 2009, at 04:04, Ian Hickson wrote:
> What roles should I use for the following elements?
>>  <input type=date>
>>  <input type=time>
>>  <input type=datetime>
>>  <input type=datetime-local>
>>  <input type=month>
>>  <input type=week>
>>  <input type=color>
>>  <input type=file>
> The conclusion I drew when developing the schema prototype was that these
> have native semantics that needs to be exposed to AT by the browser without
> AT in between and that it doesn't make sense to set the role attribute in
> these cases.
> As far as I can tell, date, time, datetime, datetime-local, month and week
> are closest to ARIA spinbox plus the kind of datatype sensitivity that ARIA
> cannot express. Anyway, I think it's rather useless to define these in terms
> of spinbox. Rather, it seems that all the input types you mentioned need
> accessibility API exposure beyond what ARIA offers (possibly using a
> synthetic accessible subtree where the semantics don't have an exact match
> in the accessibility API).
>  <meter>
>>  <time>
>>  <keygen>
>>  <abbr>
>>  <ruby>/<rt>/<rp>
>>  <ins>/<del>
>>  <figure>/<legend>
>>  <video>
>>  <audio>
>>  <caption>
>>  <thead>/<tbody>/<tfoot>
> These should probably be considered to have strong native semantics that
> are not suitable for defining by reference to ARIA. Also, it seems
> inappropriate to override the native semantics using role.
>  <fieldset>/<legend>
> Looks similar to role=group to me.
>  <details>/<legend>
> Looks similar to role=region plus aria-expanded.
>  <iframe>/<embed>/<object>
>>  <dl>/<dt>/<dd>
> [...]
>> I'm assuming most elements, e.g. <p>, <em>, etc, should have no default
>> role, and should instead rely on styling. Is that right?
> <dl>/<dt>/<dd> should probably fall into the same bucket as <p> and <em>.
> <iframe> can be an embedded role=document or role=application. Do
> implementations allow document vs. application to be picked from the
> <iframe> element or from the <body> of the embedded element?
> I'm assuming elements that are display:none need no role as they are not
>> in the rendering. Is that right? If so, is "aria-hidden" redundant with
>> CSS?
> In implementations that have access to computed style, yes, AFAICT.
> How should I integrate HTML's "hidden" attribute (which causes
>> display:none to be implied) with "aria-hidden"?
> I seems to me that the host language-native @hidden obsoletes @aria-hidden.
> How should I expose <th> elements that have scope=rowgroup or
>> scope=colgroup?
> On a related note, I doubt the usefulness of the rowheader, columnheader
> and heading roles as values of the role attribute. HTML has native semantics
> for these, and HTML has had these native semantics for a long time and the
> corresponding elements are stylable so that authors have no real reason not
> to use the corresponding native elements. In the context of HTML, isn't the
> use of role=rowheader, role=columnheader and role=heading always contrary to
> the stated principles of ARIA?
> Should I make aria-haspopup="" be true when an element has a
>> contextmenu="" attribute, or is aria-haspopup="" only intended for
>> indicating the availability of non-native context menus?
> It would certainly be odd to use aria-haspopup for host language-native
> context menus.
> How should I integrate "aria-grabbed" with the drag and drop API?
> Surely aria-grabbed is for non-native d&d. Is it?
> Should I expose the multitude of labels in HTML (title="" everywhere,
>> <option label="">, etc) using "aria-label"?
> Isn't the point of aria-label that it's a title attribute that is hidden
> from non-AT users, so designers who object to tooltips don't need to object
> to aria-label?
> Is the premise of your questions that you are trying to define the
> accessibility API mappings of HTML5 by using ARIA as a definitional
> indirection layer? The draft doesn't say so clearly when it talks about
> native semantics.
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/

with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
Received on Monday, 24 August 2009 12:36:03 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:54 UTC