W3C

User Agent Weekly Teleconference

11 Sept 2008

Agenda

See also: IRC log

Attendees

Present
Jeanne, Jan, KFord, Judy
Regrets
Jim_Allan, Judy_Brewer, Simon_Harper, Alan_Cantor
Chair
Jeanne
Scribe
Kford, jeanne

Contents


Note: Due to error, these minutes were prepared manually from the IRC log. Best effort was made to style the minutes correctly. Contact Jeanne Spellman for correction of significant errors.

F2F

JS asked that everyone please register. Right now only 2 people are registered and 5 people have requested to be observers

Action items

jeanne created a new editors draft

<jeanne> http://www.w3.org/WAI/UA/2008/WD-UAAG20-20080909/WD-UAAG20-20080909.html

JR: concerned that 4.1.8 "single keystroke" -- the concept of modifier key has been dropped.

Jeanne: Do you see anything else that was missed? Tried to be careful in review of minutes.

Jan: 4.1.5 discovery of keyboard commands, that stilll mixes together what's standard ctrl+s

... with something that's not standard i.e. some ability to see on the screen what will take an access key i.e. on a web page.

Jeanne: Looking to see origin of text.

<jeanne> http://www.w3.org/2008/08/28-ua-minutes.html#item03

Jeanne: Think this came from minutes of 8/28, item 3.

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0125.html

Jan: Now remember discussing this. Will still need more attention in a document that calls attention to this aspects.

Topic: JAN wording for 4.10 and 4.11

Jan: Used to say that the user could override anything. This is a lot to ask of the user, many web sites, any accesskeys, too much for the user.

Jan: Reads proposed text.

Jan: The idea is that the browser in options have provide all the keys were available as access keys.

Jan: Would let user specify those they like/don't like.

Jan: User agent would remap on the fly for user preferences.

Jan: Our discovery options would remind the user of this remapping.

KFord: discussion of an example.

KFord:sample use case -- a user only wants to use the left side of the keyboard. When the user goes to web page X, which uses alt-J. The browser would remap it automatically to another one, defaulting to some key in the group of left.

... this would put more burden on the user for discovery.

JR: First the user would use the discovery method of 1.5 to find the keys and then select what they would want to map it to.

KF: Prefer to make it predictable without any discovery. I think JR wants to make it flexible because we have discovery.

JR: If "H" is being used and "Q" is open, then map to "Q".

JR: I agree that it is better to make it predictable.

KF: Do we want to design it to that level, or just say that it needs be there and put the strategy for accomplishing that in the techniques.

JS: Also very important to speech users.

JR: Certain keys like "m" and "n" would be important to avoid because of the possibility of confusion.

<Jan> The user has the option to establish preferred keybindings that the user agent will use to override *recognized* author-supplied keybindings.

Jeanne: Is there a reason we need to separate author-supplied from user interface?

Jan: The user agent's UI knows what it needs to do. Web pages are all over the map.

Jan: an author might use the full alphabet with no need for mapping.

Jeanne: So are you saying that if a user wants to use just the left side of the keybaord they shouldn't be able to remap the UA commands.?

<Jan> JR: In the UA UI case, user has the semantics...in the content case they don't

Discussion around why separating frame from content. Group thinking we don't need to separate.

Jan: Preferred keystrokes is kind of for the web.

Jan: If the author has used the full alphabet, tough luck.

KFord, No tough luck, the things would just cycle between in this case.

JR: If multiple things were mapped to the same keybinding, they would cycle through as long as it was wasn't activating the function.

JS: This is covered under separation of selection and navigation

JR: But you don't want Ctrl-S to have to press enter to save, you just want to save on Ctrl-S.

JS: Accesskeys can be written with javascript to execute on focus. Accesskeys can be assigned to a button which would fire on selection.

KF: This would take care of 90% of the problems.

JR: reads 4.1.4 - Separation of selection and activation.

... there is some danger of things being washed together -- being focused on the chrome and forgetting that it also applies to accesskeys. As long as it is covered in Techniques it is ok.

KF: As far as Techniques go, this is a very complex thing. This adds an extra layer of complexity that the user agent has to provide. How would the user agent know when the author is using javascript to specify the keys.

JR: That's why we say *recognized* keystrokes.

Jeanne working on proposal to combine 4.10 and 4.11

<jeanne> 4.1.10 Specify preferred keystrokes: The user can override any keyboard shortcut binding for the user agent user interface except for conventional bindings for the operating environment (e.g., for access to help) and the user can override override *recognized* author supplied keybindings (i.e. access key).

Jan: I think it is ok.

More word editing.

KFord: Generally like.

<jeanne> 4.1.10 Specify preferred keystrokes: The user can override any keyboard shortcut including *recognized* author supplied shortcuts (e.g accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g., for access to help).

KFord: discussion around alt+d.

JR: Then in this case, the alt+d would be mapped to alt+k if the user needed to only use the right side of the keyboard,

KFord: when does a key rise to the level of an operatng system convention.

KF: Where do you draw the line between the operating environment and the browser?

KFord: We do not need to answer this today but need to.

KFord: At some point.

JS: So if someone can't use the left side of keyboard, should they be able to map F1 to F12?

KF: That would be done by the OS, not the browser.

KF: It's a question to put out to the community, we need to ask "Is the OS exception really needed?"

JR: It will be in the email that goes out and the announcements to the community.

JS: It also goes in the Status section.

KF: Maybe we can leave some of these a little open and get community feedback.

KFord: leave in stuff about conventions but call it out in review of document.

<jeanne> RESOLUTION: Propose the wording above for the 4.1.10 with a note to call it out in review of the document.

ACTION: Jeanne to put new 4.10 draft for proposal out at next meeting.

<jeanne> 4.1.10 Specify preferred keystrokes: The user can override any keyboard shortcut including *recognized* author supplied shortcuts (e.g accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g., for access to help).

More discussion about if we need the OS convention item here.

Jan: Used example of F1.

JBrewer: Related experience of OS failing when travelling out of the country. Used a different language and shortcut keys all changed.

More discussion.

JBrewer: seems like a good area to get community feedback on.

<jeanne> previous draft http://www.tsbvi.edu/technology/uawg/status41.htm

<jeanne> 4.1.11 Intergroup Navigation: If logical groups of focusable controls (e.g., toolbars, dialogs, labeled groups, panels) are present, the user can use the keyboard to navigate to a focusable control in the next and previous groups.

Jeanne: Add an ETC to the example.

JBrewer: Is logical groups going to make sense.

<jeanne> 4.1.11 Intergroup Navigation: If groups of focusable controls (e.g., toolbars, dialogs, labeled groups, panels) are present, the user can use the keyboard to navigate to a focusable control in the next and previous groups.

<jeanne> 4.1.11 Intergroup Navigation: Allow the user to navigate between groups of focusable controls (e.g., toolbars, dialogs, labeled groups, panels, etc.)

KF: Needs "sequentially". The minimum bar is to be able to get to all the controls.

More discussion of text. JAN had good proposal.

JS: This is the AAA. We have already covered sequentially.

ACTION: Jeanne to bring text to group for review next meeting.

<jeanne> 4.1.11 Intergroup Navigation: Allow the user to navigate between groups of focusable controls (e.g., toolbars, dialogs, panels, etc.)

4.1.12

<jeanne> 4.1.12 Group Navigation: If logical groups of focusable controls are present, the user can use the keyboard to navigate to the first, last, next and previous controls in the current group.

Jan: Idea is that if you have a group of controls you can cycle around in the group.

Jeanne: Can these be combined?

<jeanne> 4.1.11 Intergroup Navigation: Allow the user to navigate between and within groups of focusable controls (e.g., toolbars, dialogs, panels, etc.)

ACTION: Jeanne to combine 4.11 and 4.12 into a single item for group. Emphasize moving between and among groups of focusable controls.

Discussion of document format around highlighting.

ACTION: Jeanne to investigate ways to make document have less neon colors.

 

Summary of Action Items

[NEW] ACTION: Jeanne to put new 4.10 draft for proposal out at next meeting.

[NEW] ACTION: Jeanne to bring text to group for review next meeting.

[NEW] ACTION: Jeanne to combine 4.11 and 4.12 into a single item for group. Emphasize moving between and among groups of focusable controls.

[NEW] ACTION: Jeanne to investigate ways to make document have less neon colors.
 
[End of minutes]