Re: Questions arising from ARIA/HTML5 integration

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