Re: Visual keyboard accessibility indicators (was Re: User Agent Teleconference for February 28 2008 (new time 2pm Eastern))

Hi,

My comments are in-line with Jim's below:

Jim Allan wrote:
> Jims comments 
> <jim></jim>
> 
> Jan wrote: 
> As per my action item from today's call, here's what I see as the main 
> pieces. I've also split them up since they may lend themselves to 
> different priorities:
> 
> NOTE: Keyboard shortcut probably needs a definition that excludes 
> keyboard controls for sequential navigation (arrow keys, ENTER, TAB, etc.)
> 
> (1) Visual Keyboard Shortcut Indicator ("Chrome"): Provide a user 
> setting in which currently visible user interface "chrome" components 
> visually indicated their keyboard shortcuts, IF ANY (e.g., with 
> accesskey letters underlined).
> <jim>example should also include modifier key plus letter for items in a
> menu. My wording could use some work. I am trying to include not just the
> top level user interface items (accesskey underlined) but the items in the
> menus (Save Ctrl+S).
> Also have a concern about 'accesskey'. It may be confused with the HTML
> @accesskey. Suggest 'shortcut key' in place of 'accesskey'
> Nit: 'indicated' should be 'indicate'
> </jim>

JR: I should have said "Access key" which is the proper term 
(http://www.usabilityfirst.com/glossary/term_526.txl), which we should 
define. I purposefully left out modifier+key (e.g. Ctrl+S) because if 
the File menu is closed how will this be indicated?


> (2) Ensure Keyboard Shortcuts: Any user interface "chrome" component 
> that can receive *user interface focus* using the keyboard has a 
> keyboard shortcut, unless the *operating environment* prevents this.
> <jim>I like this. This provides for quick access to menu items. So, if I
> need to open an email archive, I can hit 'ALT+F, A' rather than 'ALT+F and
> multiple down arrows. 
> I think we still need something about common actions that have shortcut keys
> but are 2 submenu levels down (sort of like deep linking to a menu command).
> For example, in Firefox changing text sizes is one submenu off of the 'view'
> menu, but 'increase' and 'decrease' font size each have a shortcut key
> combination (CTRL+ and CTRL-). My concern is that 'common actions' is hard
> to define and may be too prescriptive.). 
> </jim>

JR: 4.1.8 is where we would put "common" things requiring accelerator 
keys. I meant for (2) to apply to currently visible things in each state 
of the system...not that there be ctrl+ combinations for everything at 
every level. I also see (2) as a lower priority.


> (3) Visual Keyboard Shortcut Indicator (Content Display): Provide a user 
> setting in which any *recognized* keyboard shortcuts for currently 
> visible content are visually indicated (e.g., with overlays).
> <jim>what is an 'overlay'? 
> </jim>

JR: I was thinking about something the User Agent draws that hovers over 
the rendered page. The reason for this is that in HTML accesskeys are 
independent of any text label...so you can't just render an underline 
under a letter in the label (in fact there may be no label).


> (4) Programmatically Available Keyboard Shortcuts ("Chrome" and Content 
> Display): If a keyboard shortcut exists for a component, then it is 
> available programmatically.
> 
> (5) Document Keyboard Shortcuts ("Chrome"): Any *warping keyboard 
> shortcuts* (shortcuts to destinations requiring multiple mouse clicks) 
> are listed in the documentation. Note: Separate lists are permitted for 
> the "base" user agent, each extension and each plug-in.
> <jim>Think this should be all keyboard shortcuts (those with modifier keys)
> should be listed in the documentation. 

JR: That's what I meant. The term "warping keyboard shortcuts" was my 
(perhaps confusing) attempt to distinguish keystrokes that activate 
things I can see on the screen from keystrokes for things I can't see 
(e.g. a "File>Save" menu item when the "File" menu is closed).


> (6) Content Focus Keyboard Commands (Content Display): Users may request 
> a list of all keyboard commands that are currently available and are 
> "recognized" to move the content focus.
> 
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Thursday, 6 March 2008 16:31:54 UTC