Re: aria mappings

hi jim,
I am working from the premise that defining aria mappings to native html
elements, is an aid to deciding what roles, states and properties are
appropriate to be used on any given element, for HTML5 document conformance.

I think from the standpoint of the spec it is presumed that for example
"input type=color" has a native accessibility API implementation. This
implementation may well vary across browsers

browser X implements color as a dropdown list of options, this would be
mapped on windows to an MSAA ROLE_SYSTEM_LIST

browser y implements color as a button which when pressed opens a  windows
color dialog (
http://msdn.microsoft.com/en-us/library/system.windows.forms.colordialog.aspx
).
in this case input type=color would be mapped to MSAA as a
ROLE_SYSTEM_PUSHBUTTON with associated properties such as HASPOPUP and a
default accessible_name value of 'color picker' the windows color dialog
itself will have roles provided for each of the controls in the dialog.


For the purposes of ARIA mapping,  depending on the implementation the input
type=color may be a role='listbox' or a role='button' or some other role. In
the first case the ARIA role correctly describes the complete input
type='color' in the second case the ARIA role only describes that part of
the interface of provided via HTML, being the button.

So coming back to the question of what is a useful mapping for input
typer=color? due to the multitude of forms that a color control could take,
there is no one ARIA role that maps onto it, so saying in the mapping that
it has no ARIA role is correct.

but this does not really help us to decide what if any ARIA roles make sense
to be allowed on input type=color, which i think is the purpose of the
mapping.

What i think it comes to, is the question, is there any possible reason why
a developer would want to take an input type=color (for example) and modify
how the user percieves it and interacts with it? if so is there an ARIA role
that could be used to describe that perception and interaction? if not then
for the purposes of document conformance in HTML5 no roles should be allowed
on input type=color.


regards
stevef


2009/9/23 Jim Jewett <jimjjewett@gmail.com>

> Aria mappings have been tricky enough that I'm sending it here for
> review instead of just posting a bug.
>
> input type=color and input type= (datetime, date, month, week, time,
> datetime-local) are defined with no role.
>
> I think that these should have role=spinbutton
>
> According to http://www.w3.org/TR/wai-aria/#spinbutton
>
> A form of range that expects a user to select from amongst discrete
> choices.
>
> A spinbutton typically allows the user to select from the given range
> through the use of an up and down button on the keyboard. Visibly, the
> current value is incremented or decremented until a maximum or minimum
> value is reached. This functionality SHOULD be accomplished
> programmatically through the use of up and down arrows on the
> keyboard.
>
> Although a spinbutton is similar in appearance to many presentations
> of select, it is advisable to use spinbutton when working with known
> ranges (especially in the case of large ranges) as opposed to distinct
> options. For example, a spinbutton representing a range from 1 to
> 1,000,000 would provide much better performance than a select widget
> representing the same values.
>
> -jJ
>
>


-- 
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