Re: Questions arising from ARIA/HTML5 integration

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