- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 1 Sep 2009 17:54:29 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: wai-xtech@w3.org, public-html@w3.org
- Message-ID: <55687cf80909010954v598dffa2ub56ddea30669afbb@mail.gmail.com>
clarification for <input type=time> <input type=datetime> <input type=datetime-local> as implemented in Opera these should all have a role of ROLE_SYSTEM_SPINBUTTON in MSAA with an accessible description that provides info about the format. regards stevef 2009/9/1 Steven Faulkner <faulkner.steve@gmail.com> > clarification for <keygen> > > the roles and properties it could be mapped to depends upon how its UI is > presented in the browser. > > regards > stevef > > 2009/9/1 Steven Faulkner <faulkner.steve@gmail.com> > > note: removed public-pfwg-comments@w3.org as this is meant for last call >> comments on the wai aria spec. >> >> hi Ian, >> >> i have taken a stab at answering some of your questions. >> >> 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> >> >> these all appear as text boxes with a button/keystroke associated to open >> a dialog no? >> >> they will all need to be mapped to the platform accessibility APIs by the >> browser. >> if i was attempting to emulate the semantics of the input type="date" >> using ARIA I would use role="textbox" with aria-haspopup="true" >> >> <meter> >> <time> >> <keygen> >> <abbr> >> <ruby>/<rt>/<rp> >> <ins>/<del> >> <video> >> <audio> >> <iframe> >> <thead>/<tbody>/<tfoot> >> none, as far as I can tell , could not find accessibility API mappings for >> any of these >> >> * note, did not do an exhaustive search. >> >> <dl>/<dt>/<dd> >> may be mapped to accessibility API as a list >> >> <figure>/<legend> >> figure may be mapped as a grouping role and legend would be the accessible >> name >> >> <caption> >> >> is mapped to platform API as the accessible name of a table >> >> >> <details>/<legend> >> having not seen an implementaion its disfficult to say >> >> >I'm assuming most elements, e.g. <p>, <em>, etc, should have no default >> >role, and should instead rely on styling. Is that right? >> i would say so. >> >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? >> >> i don't understand why you would want to do this, it is my understanding >> that ARIA is not meant to be used to map the default >> roles/states/preoperties of native controls onto platform accessibility >> APIs, but perhaps it could be used in cases where the accessibility APIs do >> not have the roles/states and properties defined in ARIA (example is the >> MSAA does not have a header as in H1 role.) >> >> >Does the presence of <thead>, <tbody>, and <tfoot> between elements with >> >role=row and role=gridcell have an effect on the ARIA conformance of a >> >document, given that it means the element with role=gridcell is not a >> >child of the element with role=row? If so, how should I address this >> >issue? >> the <thead>, <tbody>, and <tfoot> do not appear to have any meaning in >> MSAA and are not included in the accessible tree, so i would say that there >> presence has no effect. >> >> >Should I expose the multitude of labels in HTML (title="" everywhere, >> ><option label="">, etc) using "aria-label"? >> title attribute content is already exposed through accessibility APIs as >> the accessible name, so don't see why it is needed? >> the label on an option is exposed as the accessible name for the option. >> >> I haven't answred quite a few of the questions, will look at them further. >> >> >> regards >> stevef >> >> >> 2009/8/22 Ian Hickson <ian@hixie.ch> >> >> >>> 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> >>> <meter> >>> <time> >>> <keygen> >>> <dl>/<dt>/<dd> >>> <abbr> >>> <ruby>/<rt>/<rp> >>> <ins>/<del> >>> <figure>/<legend> >>> <iframe>/<embed>/<object> >>> <video> >>> <audio> >>> <caption> >>> <thead>/<tbody>/<tfoot> >>> <fieldset>/<legend> >>> <details>/<legend> >>> >>> I'm assuming most elements, e.g. <p>, <em>, etc, should have no default >>> role, and should instead rely on styling. Is that right? >>> >>> 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? How should I integrate HTML's "hidden" attribute (which causes >>> display:none to be implied) with "aria-hidden"? >>> >>> What should I do regarding aria-owns/radiogroup for <input type=radio>? >>> >>> How should I expose <th> elements that have scope=rowgroup or >>> scope=colgroup? >>> >>> How should I expose colspan="" and rowspan="" on table cells? >>> >>> 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? >>> >>> For an <input type=number>, which I presume should have role=spinbutton, >>> I >>> have a situation in which the value (for aria-valuenow) might not be >>> known. However, it appears there is a conflict between the rules for >>> role=spinbutton (which require an aria-valuenow) and the rules for >>> aria-valuenow (which say it should be omitted in this case). What value >>> should I give the aria-valuenow property in this case? >>> >>> How should I integrate "aria-autocomplete" with the various >>> autocompletion >>> mechanisms in HTML5, specifically list="" on <input>, autocomplete="" on >>> <form> and various controls, and UA-specific behaviour on all editable >>> controls? >>> >>> Does the presence of <thead>, <tbody>, and <tfoot> between elements with >>> role=row and role=gridcell have an effect on the ARIA conformance of a >>> document, given that it means the element with role=gridcell is not a >>> child of the element with role=row? If so, how should I address this >>> issue? >>> >>> How should I integrate "aria-grabbed" with the drag and drop API? >>> >>> Should the drag and drop API's dropEffect attribute affect the >>> "aria-dropeffect" state? If so, how? >>> >>> Should I expose the multitude of labels in HTML (title="" everywhere, >>> <option label="">, etc) using "aria-label"? >>> >>> How should I make "aria-labelledby" refer to elements that have no IDs, >>> as >>> in the following case?: >>> >>> <label>Name: <input name=fn></label> >>> >>> It seems that in this case I need to imply an "aria-labelledby" on the >>> <input> to point to the <label> but I don't see how to do it since >>> there's >>> no ID on the <label>. >>> >>> How should I expose the placeholder="" attribute on <input>? Should I map >>> it to "aria-label"? What if there is a placeholder and an explicit >>> <label>; should I give both? >>> >>> -- >>> Ian Hickson U+1047E )\._.,--....,'``. fL >>> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >>> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >>> >>> >> >> >> -- >> 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 >> > > > > -- > 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 > -- 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 Tuesday, 1 September 2009 16:55:12 UTC