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.


David Poehlman wrote:
> I agree with the below.
> ----- Original Message ----- 
> From: "Becky Gibson" <>
> To: <>
> 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:
> blog: WebA11y
> 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 20:47:58 UTC