- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 4 Sep 2009 12:21:03 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: wai-xtech@w3.org, public-html@w3.org
- Message-ID: <55687cf80909040421j719cdb89nbf53da89cf6b211@mail.gmail.com>
hi Ian, >My e-mail was intended to be taken as last call comments on the WAI ARIA >spec, for what it's worth. and it is my understanding that the questions have been recorded as last call comments, and will be answered in due course. I don't think the public-pfwg-comments@w3.org is intended for discussion threads on comments. You also sent it to public html and wai-xtech, I responded ot it on this basis. >><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? >No, their UI varies greatly. Then the mapping to the accessibility APIs would depend on the implementation. >Would that result in the optimum interface in an AT? the optimum interface would result from the correct mapping to the accessibility APIs for the controls that make up the interface and may include instructional content being provided using the appropriate properties. If the controls are implemented in the browser, but not hooked up to the accessibility APIs or instructional content is not provided or the accessibility APIs available do not provide features that ARIA does, and the browser supports ARIA, then the use of ARIA could provide the optiimum interface to AT. >> none, as far as I can tell , could not find accessibility API mappings for >> any of these >Is that a problem? note: there was a note in my repsonse saying i had not done an exhaustive search. Some of these do have mappings. for example having a look at the html 5 video element in Firefox has an MSAA role="grouping" could do with a name value of video. the play button has a role="push button and a name="play" or "pause" depending on whether its been pressed, there is a slider which has a role=slider and a name="3:02 of 9:56 elapsed" conveying info dependent on the slider position, there is a mute button role="push button and name="mute" or "unmute". there is also a role="slider" for volume that does not have an accessible name (should be name="volume"). the mapping to the accessibility APIs would depend on the implementation, if there is no appropriate mapping and this results in the elements not being understandable or usable by AT users then yes. for example , the canvas element currently has no mapping, and thus is not there for AT users. >Could you elaborate? What should I add to the table? How do we keep the >dts associated with their dds, or is that not necessary? What constitutes a correct association should be derivable from the html5 spec no? I merely suggested that it may be mapped as as a list as it is described as a list in the spec. the case may be that no mapping is provided by the browser to an accessibility API as there is none appropriate, this can result in AT pulling the info from the DOM and presenting it to the user as they see fit. (examples include h1-h6 and <abbr>). >> <figure>/<legend> >> figure may be mapped as a grouping role and legend would be the accessible >> name >What would I need to add to the tables in the spec to achieve this? >> <caption> >> is mapped to platform API as the accessible name of a table >How do I denote this in the spec? why do you want to denote it? are you planning to provide a mapping for every element and attribute in the spec to an accessibility API? > >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.) >Should I not have the default roles in the spec then? >I'm really not sure what the right thing is here. I was hoping that the >responses to my last call comments would answer these questions, so I'm >operating rather in the dark here. NOTE: I am responding and have responded as a member of the HTML WG to questions posted to the HTML WG. My understanding of the tables in the spec is to provide rules on what ARIA roles, properties and states can be used on what HTML elements. If there is a clear relationship between an element in the spec and associated ARIA role, example <input type="checkbox"> its would be expected that this control would always be mapped onto a checkbox role in accessibility APIs and ARIA has a role="checkbox" which maps on to the same roles in the accessibility APIs. in this case it is helpful to provide an indication of the relationship if it helps to explain why other ARIA roles should not be used on this element. >> 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. >So exactly what mappings should I put in the spec for these? As it has been pointed out by others it would appear that the implementation of the new controls may vary widely dependent on browser so the mapping would depend upon what the browser is. regards stevef 2009/9/4 Ian Hickson <ian@hixie.ch> > On Tue, 1 Sep 2009, Steven Faulkner wrote: > > > > note: removed public-pfwg-comments@w3.org as this is meant for last call > > comments on the wai aria spec. > > My e-mail was intended to be taken as last call comments on the WAI ARIA > spec, for what it's worth. > > > > 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? > > No, their UI varies greatly. > > > > 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" > > Would that result in the optimum interface in an AT? > > > > <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 > > Is that a problem? > > > > <dl>/<dt>/<dd> > > may be mapped to accessibility API as a list > > Could you elaborate? What should I add to the table? How do we keep the > dts associated with their dds, or is that not necessary? > > > > <figure>/<legend> > > figure may be mapped as a grouping role and legend would be the > accessible > > name > > What would I need to add to the tables in the spec to achieve this? > > > > <caption> > > > > is mapped to platform API as the accessible name of a table > > How do I denote this in the spec? > > > > >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.) > > Should I not have the default roles in the spec then? > > I'm really not sure what the right thing is here. I was hoping that the > responses to my last call comments would answer these questions, so I'm > operating rather in the dark here. > > >> 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. So exactly what mappings should I put in the spec for these? as it has been pointed out by others it would appear that the implementation may vary widely dependent on browser so the mapping would depend upon what the browser is. in this case i would suggest that a mapping in the spec is not helpful. regards stevef > > > >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. > > It would be good if the ARIA spec could be clarified to this 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? > > Ok. Not doing it is certainly a lot easier for me, I just wasn't sure > what was expected. > > > On Tue, 1 Sep 2009, Steven Faulkner wrote: > > > > clarification for <keygen> > > > > the roles and properties it could be mapped to depends upon how its UI > > is presented in the browser. > > On Tue, 1 Sep 2009, Steven Faulkner wrote: > > > > 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. > > So exactly what mappings should I put in the spec for these? > > -- > 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
Received on Friday, 4 September 2009 11:21:51 UTC