Re: Questions arising from ARIA/HTML5 integration

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/

Received on Monday, 24 August 2009 11:55:03 UTC