W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2008

Draft Minutes: User Agent Teleconference for 10 April 2008

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 10 Apr 2008 14:22:42 -0500
To: "'WAI-UA list'" <w3c-wai-ua@w3.org>
Message-ID: <007301c89b40$3f898b10$be9ca130$@edu>

Minutes: http://www.w3.org/2008/04/10-ua-minutes.html
IRC log: http://www.w3.org/2008/04/10-ua-irc 

Action Items: 
ACTION: JB to Contact Apple about keyboard operability definitions [1]
	recorded in http://www.w3.org/2008/04/10-ua-irc#T18-21-31 
	
ACTION: JA to Review JR's definition of "Ensure Keyboard Shortcuts" and will
add in something about static/dynamic [2]
	recorded in http://www.w3.org/2008/04/10-ua-irc#T19-00-47 
	
ACTION: all to review
http://www.w3.org/TR/2008/WD-UAAG20-20080312/#principle-AT-access  for next
week [3]
	recorded in http://www.w3.org/2008/04/10-ua-irc#T19-14-03 

as usual, any corrections, comments, misattributions or gaps in the minutes
should be logged by replying-to this post on list...

Text of Minutes: 
Agenda

Attendees

Present
    Cantor, Judy, Jan, AllanJ, Sean_Hayes, Sean
Regrets
    Gregory_R., Kelly_F.
Chair
    Jim Allan
Scribe
    Jan

Contents

    * Topics
         1. 1. Continue Keyboard Access discussion
         2. b. JR and JA attempts at requirements that include visual
indicators:
    * Summary of Action Items

<scribe> Scribe: Jan

JB: Who was on call last week?

JR: Sean Hayes
Kelly Ford
Alan Cantor
Jan Richards

Gregory Rosmaita
1. Continue Keyboard Access discussion

<AllanJ> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0004.html


JA: So can we put these in our glossary?

JB: Yes if vetted

JR: Some terms used in 4.1 discussion

JA: Reads
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0004.html

SH: Sounded ok though accelerator keys may not be quite right

JB: Also I have contacted a person at Apple and ther may be interest in
bringing someone in who works with keyboarding issues.
... Are these defintions sufficiently cross-platform?

SH: I think terms may change slightly but general concepts ok

JA: So like "also called..."

SH: But I don't think plle uses keyboard in any fundamental way

JR: I was trying to think of broad range including cell phones with few keys
... Think examples are maybe Windows specific

AC: WIndows specific

JB: OK i will send this pointer to them
... Might be premature to add to document yet

JA: OK

JB: It is important to be mapping out the differences between these terms
... For instance sequential concept is important to me
... Many people seem to think its no problem to have many many arrowing
actions to operate a menu etc

AC: So two issues...1. how much is too much, 2nd is visibility issue - what
things look like when they ahve focus
... Becoming increasingly an issue what things look like...
... It is my critique of this doc that there is no visual...

<scribe> ACTION: JB to Contact Apple about keyboard operability definitions
[recorded in http://www.w3.org/2008/04/10-ua-minutes.html#action01] 

b. JR and JA attempts at requirements that include visual indicators:

AC: speaking about visual indication of where the focus is
... Increasingly lost in Vista and other things
... Some windows always appear the same

<AllanJ> for reference:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0052.html  and
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0053.html 

AC: Similarly when using TAB or arrows same problem
... These essentially break the keyboard accessibility

<AllanJ> +q visual indicators in content

<AllanJ> JR: visual indicators of what you can press, vs focus indicators
(have a section on that)

JB: are when entering GUI^2 phase?

oops was JB

AC: Not getting more complex, just that keyboard access is getting harder
... I'm having lots of problems with keyboard nav in Vista

JA: Another focus issue is designers not wanting focus in content...
... Because firefox has finally implemented CSS focus selector
... But authors are turning it off because they don't like the look of it
... But would like to focus on chrome first

AC: What's your definition of Chrome?

JA: Chrome is the specific UI of the application - all the stuff not in the
content display.

AC: So its the stuff that contains the content?

SH: There are some overlap...icons in TABs...
... Not a clear line....

<AllanJ> SH: think of a picture, chrome is the frame, content is the picture

<AllanJ> JB: how widely is term used

JB: How widely used is "chrome"?

JR: Used in IBM

SH: And also in MNicrosoft
... Is nice to have short handle for this stuff

JA: We were calling it the appliction user interface

AC: As long as its clear

JB: But "appliction user interface" seems more clear to more people

JA: Back to visual indicator part
... In chrome
... What kind of indicators do we need where
... In order to use Direct commands
... Can get really complicated

JR: Some proposed text:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0008.html 
... 4.1.5

JA: Reads...

JB: First concern is that it doesn't include "sequential"....
... But "sequential" batches 2 things together

JA: How so?

JB: When I look at 4.1.5 and 4.1.6...both just target "Direct"...
... But "sequental" groups two things that need different tratement....
... TABbing is highly learnable and usable
... But arrowing is different
... First concern is not wording but scope

<AllanJ> JR: different ways of doing keyboard access, open menus - ALT

<AllanJ> ... could use arrows, may be tiring

<AllanJ> ... once in menus, could use letter command to jump to control, may
be a direct command

AC: Wanted to support ....
... Very important to minimize physical effort
... e.g. list of two hundred countries...
... Can press "S" but then press it 15 times....
... But sometimes quite type "Sw" to get to swaziland

JB: So "may" be a direct is the problem

<AllanJ> JR: talking about indicators of things that are there. if there is
a direct access method it should be shown.

JB: JR is assuming maybe there are some

JR: I completely agree

JB: Maybe we add something further up in list
... Perhaps it goes in 4.1.1

AC: Wonder if we can be prescriptive on numvber of keystrokes per task?

http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0052.html 

(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.

AC: Some people give up after 3.

JB: That's why I think thresholds are difficult....
... Typical studies may not look at these
... May not have looked at specific hand disabilities

AC: But maybe could be liberal with number
... Then 8 rules out 15 for ex.

JA: Question for Sean...
... Is prescribing number of keystrokes overly prescriptive
... Then maybe JR was getting at another type of definition
... Menu items need hotkeys are indicated
... If we can say that it may solve Judy's question

AC: Can it also be expressed as number per hierarchy

SH: Uncomfortable with a particular number
... I'm also concerned about the very dynamic nature of today;s interfaces
... And what is a step etc.

JB: Jim you were saying if each step down had an indicator allowing you to
get down

Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0052.html 

<Jan> (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.

<AllanJ> JR: last clause because of mobile devices.

SH: Not going to work
... OK for static things
... So couldn't be an abosulte rule

AC: And so it may not need to be a key you know....
... e.g. Page up looping around to last ....
... Persons knowledge of tool is really important...techs for using controls
need to be well known and documented and consistently documented

JA: Wanted to get back to dynamic options...
... Couldn't letters be dynamically assigned on the fly

SH: may or may not be possible...we tend not to do that if we can't put on
the same keys each time...
... Does not allow "muscle memory",...

JA: Some lanugage other than "static menus" and "dynamic menus" ?

SH: Yes tried to come up with something for TEITAC...will sendd

AC: When options are dynamic and it's not possible to assign keys there
might be other ways ...
... Like alphabetical or using arrow keys to go up down level etc

JB: Understand role of muscle memory

JA: OK please send items to the list

<scribe> ACTION: JA to Review JR's definition of "Ensure Keyboard Shortcuts"
and will add in something about static/dynamic [recorded in
http://www.w3.org/2008/04/10-ua-minutes.html#action02] 

JA: Next week
... Need to review ARIA doc and User Agent guidelines

JB: Regrets from me next week
... Charter discussion needed
... Not sure the TEITAC things will help

SH: I know exactly the msg I'm thinking of

JA: I want this keyboard stuff to continue on list
... My concern is that ARIA stuff might go 2 wks
... THere is some keyboard stuff in WAI ARIA ...

Jim Allan, Webmaster & Statewide Technical Support Specialist
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 10 April 2008 19:26:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:56 GMT