Re: Questions arising from ARIA/HTML5 integration

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.

regards
stevef


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 -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Monday, 24 August 2009 12:36:03 UTC