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

James Craig <jcraig@apple.com> wrote on 12/08/2008 10:13:34 AM:
> On Dec 8, 2008, at 12:36 AM, Aaron M Leventhal wrote:
> 
>> 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. 
> 
> What's the difference on a platform-agnostic equivalent? 
I don't have that many cross-platform apps that use it, but I just tried 
in Open Office and the spinbutton allows direct editing.

> This is a 
> minor behavioral difference for the view, not a semantic difference 
> for the controller.
>From what I understand, the roles we have today match up with what ATs 
describe to users today, and what users expect. It's a bit of a mix 
between the strict semantic view of what widgets are, and what users find 
useful to know. By hearing a role, a user knows what keys to press. This 
is why it's useful to know whether you are on a radio group vs. a combo 
box, there are different keys available. Yes they are both single 
selection lists. A similar reason exists for exposing slider vs. 
spinbutton. With a slider, a user would not expected to be able to type in 
the value.

>> 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. 
 
> I'll raise it as an issue for ARIA 2.0.
Good idea.

>> 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. 
> 
>> Type-ahead selection can also be achieved with listbox and combobox.
>> We can even add a note on slider that authors should support type-
>> ahead where possible if the user types an appropriate entry for 
>> valuenow or valuetext.
I don't think users would expect it, and therefore would be unlikely to 
try it. I doubt authors would take the time to do it, either, because it's 
not really expected for a slider.

> This works the same way with native HTML select/option lists, which 
> act as type of listbox, even if the values it contains are a range. The 
name 
> spinbutton is very unclear and implies more about style than it does
> about semantics or function. 
FWIW, I'm not sure why it's called a spinbutton; that is a bit strange. 
Sometimes I sometimes have heard it called a spinbox, which seems to fit 
better (sounds more like a textbox).

> If this role stays, perhaps it should 
> be named something more consistent with the rest of the class hierarchy, 
like 
> rangebox, rangelist, or rangelistbox, as it would inherit from both 
rangeand 
> listbox. 

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