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

[editorial] Re: Minutes of UAWG 11 Sept Teleconference

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Mon, 15 Sep 2008 10:01:52 -0400
Message-Id: <6505D277-F4F8-4AF1-AC82-A09A30D0C8CF@IEEE.org>
Cc: User Agent Working Group <w3c-wai-ua@w3.org>
To: Jeanne Spellman <jeanne@w3.org>


On 15 Sep 2008, at 9:28 AM, Jeanne Spellman wrote:

> David,
>
> >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".

The problem is accuracy vs. ready comprehension.

When you move from one group to the next, you are leaving
behind all the tab stops or otherwise focusable items.
This is, when closely examined, a larger category than just
controls.  For accuracy, use 'focusable items' and lose 'controls.'
But you do use comprehension among the speed readers.  <sigh/>

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

So say from group to group and avoid the collision with correct
cardinality usage (between for two, among for more than two).

> 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 14:14:09 GMT

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