W3C

- DRAFT -

WAI UA

10 Apr 2008

Agenda

See also: IRC log

Attendees

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

Contents


 

 

<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

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

<AllanJ> ACTION: all to review http://www.w3.org/TR/2008/WD-UAAG20-20080312/#principle-AT-access for next week [recorded in http://www.w3.org/2008/04/10-ua-minutes.html#action03]

Summary of Action Items

[NEW] ACTION: all to review http://www.w3.org/TR/2008/WD-UAAG20-20080312/#principle-AT-access for next week [recorded in http://www.w3.org/2008/04/10-ua-minutes.html#action03]
[NEW] 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]
[NEW] ACTION: JB to Contact Apple about keyboard operability definitions [recorded in http://www.w3.org/2008/04/10-ua-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/04/10 19:15:25 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/JA/JB/
Succeeded: s/not look/not have looked/
Found Scribe: Jan
Inferring ScribeNick: Jan
Default Present: Cantor, Judy, Jan, AllanJ, Sean_Hayes, Sean
Present: Cantor Judy Jan AllanJ Sean_Hayes Sean
Regrets: Gregory_R. Kelly_F.
Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0026.html
Got date from IRC log name: 10 Apr 2008
Guessing minutes URL: http://www.w3.org/2008/04/10-ua-minutes.html
People with action items: all ja jb

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]