Re: [STYLE GUIDE] Spinner revisited

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 20:58:32 UTC