Sorry for the delay, I had to reconstruct the minutes from the IRC
logs. All errors are mine.
Minutes
IRC Log
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.
Text of Minutes
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
* Topics
1. F2F
2. Action Items
3. JAN wording for 4.10 and 4.11
4. 4.12
* Summary of Action Items
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]