- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 24 Aug 2009 14:54:14 +0300
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-pfwg-comments@w3.org, wai-xtech@w3.org, public-html@w3.org
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:05 UTC