Re: [STYLE GUIDE] Spinner revisited

Perhaps we could 'recommend' home and end for spinners that have known 
min and max? That would be handy for keyboard users, and shouldn't hurt 
anyone.

cheers,
David

David Poehlman wrote:
> If a keyboard user has motor issues, this is extremely difficult if there is 
> a wide range.
>
> ----- Original Message ----- 
> From: "James Nurthen" <james.nurthen@oracle.com>
> To: "David Poehlman" <david.poehlman@handsontechnologeyes.com>
> Cc: <wai-xtech@w3.org>; "Becky Gibson" <Becky_Gibson@notesdev.ibm.com>
> Sent: Thursday, July 10, 2008 4:46 PM
> Subject: Re: [STYLE GUIDE] Spinner revisited
>
>
>
> While I don't object strongly to the below, I'm not sure we need to
> create a keyboard shortcut for an object when there is no mouse
> equivalent - and the mouse user requires just as many mouse clicks as
> the keyboard user does keypresses to perform that functionality - as is
> the case here.
>
> If there is no way for a mouse user to get to the first/last element in
> the spinbox and this is a required function of the UI then it is my
> contention that a different UI element should be chosen - such as a
> slider which does provide this functionality.
>
> Regards,
> James
>
> David Poehlman wrote:
>   
>> I agree with the below.
>>
>> ----- Original Message ----- 
>> From: "Becky Gibson" <Becky_Gibson@notesdev.ibm.com>
>> To: <wai-xtech@w3.org>
>> Sent: Thursday, July 10, 2008 3:27 PM
>> Subject: Re: [STYLE GUIDE] Spinner revisited
>>
>>
>>
>> So, I am convinced that if you have an object that is marked with a role
>> of spinbox, the user would not be surprised (and hopefully pleased) if
>> pressing the home key sets the value to the minimum and pressing the end
>> key sets the value to the maximum. But, what if there is no min and/or no
>> max value specified? Should the home and/or end key be ignored or should
>> it function as normal and move the cursor. For consistency I think it
>> should be ignored.
>>
>> With regards to Earl's comment about the number of entries, I don't think
>> we should change the behavior based on the number of entries as that would
>> likely be confusing.
>>
>> -becky
>>
>>
>> Becky Gibson
>> Web Accessibility Architect
>>
>> IBM Emerging Internet Technologies
>> 5 Technology Park Drive
>> Westford, MA 01886
>> Voice: 978 399-6101; t/l 333-6101
>> Email: gibsonb@us.ibm.com
>> blog: WebA11y
>>
>>
>> wai-xtech-request@w3.org wrote on 07/09/2008 04:07:06 AM:
>>
>>     
>>> Hi;
>>>
>>> I'm back, sorry for the unavoidable absence - I was out.
>>>
>>> Perhaps home/end should move to first/last entry until you start editing
>>>       
>>>   the current entry [if it is an editable field] after that, home/end
>>> would take you to the beginning/end of the current entry.
>>>
>>> Spinners are meant to have short entries in them in my experience. I
>>> agree with Joseph, maybe it should be left/right [assumes horizontal
>>> orientation] should move you in the current entry and home/end, up/down,
>>>       
>>> page up/down should spin the spinner. [1] It would seem to me it is
>>> better to offer large decrement jumps to quickly change to higher/lower
>>> values than to restrict the user to using arrow keys.
>>>
>>> Having said this, Windows is a known paradigm and it's a lot less
>>> programming to just support up/down, left/right arrow keys... [2]
>>>
>>> [1] seems best to me if spinners might frequently contain many entries.
>>> [2] is probably best if spinners are typically meant contain few
>>> entries. Pulling a break number out of my wazoo, maybe 10 or less
>>> typically contained in a spinner favors [2] while regularly 10 or
>>> greater favors [1].
>>>
>>> Anyone know the max number of entries recommended to be contained in
>>> spinners?
>>>
>>> ej
>>>
>>>
>>>
>>>
>>>
>>> Joseph Scheuhammer wrote:
>>>       
>>>>> The spinner is an input field with associated up and down arrows ...
>>>>> home and end are currently used within an input field to move the
>>>>> caret to the beginning or end of the field.  Will this confuse
>>>>>           
>> people?
>>     
>>>> That's the key:  do users perceive this widget as a text input field
>>>>         
>> or
>>     
>>>> as a spinner (or, I suppose, as a composite thing called "spinner"
>>>>         
>> that
>>     
>>>> has a text field as one of its parts)?  What does an AT report to the
>>>> user given the @role 'spinbutton'?
>>>>
>>>> If it is perceived qua spinner and not at all as a text field, then, I
>>>>         
>>>> would think, users won't expect home and end to behave as cursor
>>>> navigation keystrokes.
>>>>
>>>> If it is perceived as a text input field and home/end are commonly
>>>>         
>> used
>>     
>>>> to move to the ends of the textbox, then the style guide is
>>>>         
>> problematic.
>>     
>>>> I don't know what users' mental model is for spinners.  My experience
>>>>         
>> is
>>     
>>>> that spinners are rarely used.  I found one in the Mac "Energy Saver"
>>>> system preferences "Schedule..." section, and another in "Date and
>>>> Time", where spinners are used to set time values.  None of home, end,
>>>>         
>>>> pageup, nor pagedown did anything.  Left/right cursor keys moved left
>>>> and right within the text box, up/down increased/decreased the value,
>>>> and other keystrokes allowed entering values directly.
>>>>
>>>> If the style guide is changed, then I suggest that keystrokes for
>>>> quickly attaining the min and max values of the spinner's range.
>>>>         
>> That's
>>     
>>>> the point of the home/end currently -- to navigate quickly to the ends
>>>>         
>>>> of the range.
>>>>
>>>>         
>>
>>
>>
>>
>>     
>
>
>
>
>

Received on Thursday, 10 July 2008 21:32:16 UTC