Re: aria mappings

On Sep 22, 2009, at 7:45 PM, Jim Jewett wrote:

> On Tue, Sep 22, 2009 at 8:42 PM, Maciej Stachowiak <>  
> wrote:
>> On Sep 22, 2009, at 5:02 PM, Jim Jewett wrote:
>>> 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
>> In practice, I don't think the UIs for these will be useful to  
>> reflect to
>> assistive technology as if it were a spin button.
> I think datepicker would be much better, but that role doesn't seem to
> exist in aria.  And I have certainly used interfaces that required me
> to pick a date by hitting the little "arrow" glyph way too often.
> How would you recommend AT represent these input types?  As text
> fields with validity patterns?

I would recommend that implementations represent these controls to AT  
in a way that is suited to the concrete non-AT user interface they  
have chosen - which may be different for different implementations,  
and which may depend on what semantics AT can represent.

>> For many of these controls, there are multiple viable implementation
>> strategies for the exact UI. I don't think the spec should assume a
>> particular implementation in designating the accessibility behavior.
> Is the (aria-)role supposed to represent the physical implementation
> that happens to have been chosen, or the underlying semantics?

The underlying semantics of a color picker are not the semantics of a  
spinbutton -- they are the semantics of a color picker. But ARIA has  
no such role and assistive technologies do not always support the  
notion of a color picker directly. If role=spinbutton is supposed to  
imply that up and down arrow selection would work, then it should not  
be applied to a color picker. Choosing a color by using up and down  
arrows to cycle through all numeric color values would be a very bad  
way to do it.

In some cases, a UI for choosing from a selected set of values may  
have different semantics depending on the control used to implement  
it. For example, you pointed out that <select> and spinbuttons may  
both allow selection from a fixed set of values, but each is a  
appropriate in a different situation. In HTML, there are also <input  
type="range"> and radio button groups as possible ways to choose a  
number from a fixed set.

> Should the AT see the same underlying date field differently depending
> on which browser is being used (and how that browser vendor decided to
> style the chooser for sighted users)?

In my opinion, yes.

> (And are these questions that need to be formally asked of the pfwg?)

Feel free to ask, but I believe what I said is consistent with their  


Received on Wednesday, 23 September 2009 02:55:05 UTC