Re: Should ARIA ranges have value formatting defined? Also, spinbutton should be removed.

The difference (at least on Win32) appears to be that in a spinbox you can 
also directly enter the value with the keyboard, as in "2009" in a 
spinbutton for year.

I think the suggestion to support value formats so that the value can be 
set by the AT is interesting, and we indeed used to have something like 
that with aria-datatype. This ultimately became very complicated and IIRC, 
we dropped it for reconsideration in a later spec.

For now the aria-valuenow can only be set numerically, although for output 
purposes the value can be exposed via aria-valuetext in any format.

If the author really needs a user to be able to set the value of something 
using a text label, at the moment they will need to use a combobox 
instead. I think this is an alright tradeoff for the complexity involved 
and where we are with the spec.

- Aaron



From:
James Craig <jcraig@apple.com>
To:
WAI XTech <wai-xtech@w3.org>
Date:
12/08/2008 08:01 AM
Subject:
Should ARIA ranges have value formatting defined? Also, spinbutton should 
be removed.




slider is defined as, "A user input where the user selects a value from 
within a given range." The value of aria-valuenow is a decimal, defined as 
"a real number, represented as a decimal." Furthermore, the user interface 
hints in the spec imply that the value will always be set by the web 
application (when the user presses the arrow keys), and that the value 
should never be set by the user agent or assistive technology. From the 
perspective of a screen reader user, what's the functional difference 
between a slider and a spinbutton if they both have 1, 2, and 3 as 
potential values? None, as far as I can tell. Finally, the resulting 
functionally identical to that of a listbox; the only difference is 
semantics.

listbox is defined as, "A widget that allows the user to select one or 
more items from a list of choices." Similarly, spinbutton, a type of 
range, is defined as, "A form of range that expects a user to select from 
amongst discrete choices." Therefore, the only semantic difference in ARIA 
seems to be that a range is just a listbox whose choices are in some form 
of numerical order. 

I understand the semantic benefit of alerting the use to the fact that a 
range is ordered selections, but since the user cannot set an arbitrary 
value on any ARIA range widget, I propose both of the following changes. 
They are related, so I am listing them together, but they are not 
interdependent, so each proposal should be considered separately.

1. Remove the spinbutton role, because the functionality and semantics are 
already covered by slider and listbox.

2. Allow the the aria-valuenow property of range widgets to be set 
directly by the user agent or assistive technology. This will allow range 
widgets to be more in line with the behavior of desktop range widgets, but 
would require a value format property (and potentially an increment 
value).

For example, if the range were to increment a currency amount from 0 to 
100 US dollars, the value formation could be defined as "$###.##" with an 
aria-valuemin="0" and aria-valuemax="100", and if the range were to 
represent a date from December 10, 2008 through January 5, 2009, the value 
format could be "yyyy-mm-dd" with an aria-valuemin="2008-12-10" and 
aria-valuemax="2009-01-05". There may also need to some hint of increment 
value if it cannot be determined from the value format or other range 
data.

Thoughts? Comments?