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

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? This is a  
minor behavioral difference for the view, not a semantic difference  
for the controller.

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

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

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. 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 range and 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?
>
>