- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 24 Aug 2009 13:35:10 +0100
- 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
- Message-ID: <55687cf80908240535s494561adv6315ab2acda5bfea@mail.gmail.com>
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:00 UTC