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

Re: Minutes of UAWG 11 Sept Teleconference

From: David Poehlman <poehlman1@comcast.net>
Date: Mon, 15 Sep 2008 09:41:39 -0400
Message-ID: <B6339726AD494429A94FFF19D014A598@HANDS>
To: "Jeanne Spellman" <jeanne@w3.org>, "User Agent Working Group" <w3c-wai-ua@w3.org>

I don't think that among and between are interchangeable, among implies a 
certain amount of direct selection rather than sequential selection.

----- Original Message ----- 
From: "Jeanne Spellman" <jeanne@w3.org>
To: "User Agent Working Group" <w3c-wai-ua@w3.org>
Sent: Monday, September 15, 2008 9:28 AM
Subject: Re: Minutes of UAWG 11 Sept Teleconference


David,


  1.. >Question:
  >What is focusable and why is it set apart?

  Excellent point.  I think it is an artifact of earlier wording.  I don't 
think any meaning is lost in removing "focusable".


  2.. among vs. between:  I think that "between" makes it more clear that we 
expect to be able to move from one group to another.


jeanne



David Poehlman wrote:
recasting:

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

My proposal:

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

Question:
What is focusable and why is it set apart?

----- Original Message ----- 
From: "Jeanne Spellman" <jeanne@w3.org>
To: "User Agent Working Group" <w3c-wai-ua@w3.org>
Sent: Friday, September 12, 2008 10:23 AM
Subject: Minutes of UAWG 11 Sept Teleconference


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]
Received on Monday, 15 September 2008 13:42:21 GMT

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