My Action Item

Hi there,
I was actioned to look at creating rationale for each of the 4.1  
(sub) checkpoints. It is my firm belief that if we cannot support a  
checkpoint with a rationale for following it, then it should not be a  
checkpoint. Further, I would also like to suggest that we back up  
each rational (where possible) with a citation from the scientific  
literature (exemplar 4.1.1) - this may also mean that there are  
proposed techniques within that literature which we can leverage into  
the techniques document.

4.1.1 Keyboard Operation:

Some users do not have the ability to control mouse movements or have  
fine control over cursor positioning. Indeed, many users only have  
the option of a boolean selection switch. If keyboard (or simulated  
keyboard - via a scanning keyboard, say) control is not available  
then access may not be possible [1]. This is also the case with  
regard to keyboard timing and the length of delay required for  
execution of the keypress [2].

[1] Trewin, S. and Pain, H. A model of keyboard configuration  
requirements. Behaviour and Information Technology Special Issue on  
Assistive Technologies for People with Disabilities. 18, 1, (1999)  
27--35.

[2] S. Trewin. Automating accessibility: the dynamic keyboard. In  
Assets ’04: Proceedings of the 6th
international ACM SIGACCESS conference on Computers and  
accessibility, pages 71–78, New York,
NY, USA, 2004. ACM.



4.1.2 Documentation of Precedence of Keystroke Processing:

Clear documentation prevents the invocation of functions by mistake.  
If multiple functionality has the same Keystroke, and the order of  
precedence of those keystrokes are not known, the resultant action  
may not be either desired or expected. In this case the user may  
become disoriented; this is particularly the case for older users and  
visually disabled users where magnification technology may mean that  
functions are invoked by mistake and are executed off the viewable area.



4.1.3 No Keyboard Trap:

The common way to move away from an interface component, or group of  
components, is to mouse over a different screen area and click. If  
the user cannot operate a mouse (see 4.1.1) then a consistent  
keyboard solution is required.



4.1.4 Separate Activation:

The interface often presents its options in stages (progressive  
disclosure) on the assumption that a user will move through stages of  
interaction using a pointing device; such as a mouse. However, with  
reference to 4.1.1, the user must be able to move through the  
interface by using the keyboard. This means that movement and  
selection must be separated to prevent unintended invocation of the  
functionality when moving the interface focus with the keyboard.



4.1.5 Available Keyboard Shortcuts:

If keyboard shortcuts are not disclosed, both through the interface  
and to any assistive technology (define), the user will not be able  
to use the functionality supported by 4.1.1 in any consistent way.



4.1.6 Standard Text Area Conventions:

Maintaining platform interface consistency of both presentation and  
control means that the cognitive load on a user is much reduced as  
different interaction paradigms are not needed for different  
applications.





4.1.7 User Interface Navigation:

***COMMENT*** This seems like it could be amalgamated with 4.1.6



4.1.8 Ensure Keyboard Shortcuts:

Supports 4.1.1 by enabling direct keyboard access to interface  
components within the currently focused group.



4.1.9 Precedence of Keystroke Processing:

***COMMENT*** It seems we should look at this and 4.1.2 together - if  
we define a precedence why do we then need to make sure the  
precedence is documented unless 4.1.2 is A conformance and 4.1.9 is AA?



4.1.10 User Override of Keyboard Shortcuts:

***COMMENT*** Not sure on this one. I would say it could be seen as  
4.1.2 AAA conformance just as I suggest 4.1.9 is 4.1.2 AA conformance?



4.1.11 Intergroup Navigation:

***COMMENT*** Is this not a lot like 4.1.3 in regard to navigation  
and selection, seems that these two could be amalgamated into  
something like 4.1.x Interface Navigation

4.1.12 Group Navigation:

***COMMENT*** See 4.1.11

===

Seems to me that we could think of Keyboard Operation as: (1)  
Navigation; (2) Selection; (3) Direct-Access; and (4) Exposure &  
Documentation.

===

I'm on vacation next week with sporadic email access.








Cheers
Si.

====
Simon Harper
University of Manchester (UK)

Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
My Site: http://hcw.cs.manchester.ac.uk/people/harper/
My Diary (iCal): http://hcw.cs.manchester.ac.uk/diaries/SimonHarper.ics


+----------------------[ NEW &  
INTERESTING ]--------------------------------------+
   ASSETS 2008                . 13-15 Oct 2008 . http:// 
www.sigaccess.org/assets08
+----------------------------------------------------------------------- 
----------+

Received on Friday, 4 July 2008 15:21:58 UTC