Re: [STYLE GUIDE] Spinner revisited

David,
This is my point exactly... If there is a wide range then this control 
is difficult for everyone hence a different control should probably be 
selected.
There is already a standard keyboard shortcut available for this control 
(which is deleting the value and typing the desired value). I'm not sure 
I see the desirability in adding more shortcuts which are difficult to 
discover and perhaps conflict with other keyboard shortcuts already 
defined on the same page (at a higher level - for instance Home/End are 
already defined for an Accordion in the style guide) or by AT.
regards,
James

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:31:40 UTC