See also: IRC log
<trackbot> Date: 09 July 2009
<KFord> A
<KFord> Scribing link.
<KFord> http://www.w3.org/WAI/UA/scribing.html
<KFord> Scribe: Greg
Zakim take up item 1
<KFord> Group giving intros and Welcoming David from Apple.
Kelly introduces David Tseng of Apple.
Introductions all around.
Jeanne says we're waiting for appropriate approvals, hope to publish on July 14 or 16; until new web master is on board only publishing two days a week.
Kelly notes we're hoping to recruit new reviewers.
Kelly intends to change all open action items to have dates in the future, to be more realistic. We should also review them to see if any are done, etc.
There were no objections.
<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0008.html
Greg suggests that we should probably use the verb "activate" rather than "click" for actions carried out with the keyboard.
Many UA provide more than one mouse-input action associated with a clickable element, such as right-clicking to bring up a context menu that includes commands such as "open link in new tab", or "save link location", or "properties". It seems that ideally the UA would provide one keyboard shortcut for activating an element by its number, and another to move the focus to the element so they...
scribe: could carry out other operations such as displaying its context menu.
Mouse actions one could do to an element include click, right-click, hover, and initiate drag. The first two seem to be the most important.
Kim points out that if navigation is the only shortcut, and one has to do a second action to activate it, that doubles the input required for the most common cases.
Kelly suggests two parts, ability to activate any element more efficiently than having to use sequential navigation to it.
Kim suggests the input has two parts, identifying the element and then the action one wants to do with it.
Greg suggests we have a glossary entry discussing direct vs. sequential/logical vs. directional navigation, and what we're trying to say with this SC is that the user should have the option to use direct navigation techniques to move the focus to any element that takes input.
In techniques we could suggest that the UA optimize for the most common case of navigating to and immediately activating the element.
Kim discusses the Firefox example that adds link numbering, and allowing the user to display the numbers, type the number and a key to do something with the specified link.
Discussion of advantages of building this into every UA rather than only having it available via some assistive technology.
Kelly suggests something along the lines of "Direct Selection: The user can move the focus to any actionable elements (in the rendered content and/or UA UI?) using a direct navigation command.
Does a current SC already require that the user have the option to have direct keyboard navigation shortcuts displayed?
Kelly does not think there is a requirement that the UA add access keys, and he thinks the new proposed SC would be different than access keys etc.
If we don't want to rely on existing SC, then the new SC would d need to say the user has the ability to have UA assign and display direct keyboard navigation shortcuts for all elements that take input.
Kelly suggests we need three things: assign, display, and let user activate.
<KFord> Existing keyboard display item is as follows:
<KFord> 4.1.5 Discovery of Keyboard Commands: User has the option to have any *recognized* direct keyboard commands displayed with their associated controls. (Level
<KFord> A)
<KFord> 4.1.5 Discovery of Keyboard Commands: User has the option to have any *recognized* direct keyboard commands displayed with their associated controls. (Level 1.
"The user can have the user agent assign, display, and implement direct navigation keyboard shortcuts for all elements that take input."
Kim notes that we want to make sure that the wording does not limit it to key combinations, but includes key sequences such as those implemented by the Firefox extension.
Kelly notes that Kim's emailed proposal is a good technique but it needs a more general SC.
David notes that Kim had additional point that the user can request showing numberings for only certain categories of elements (e.g. links and/or images).
Kim suggests that showing/hiding by groups has proved useful in the Firefox extension.
David notes need to clarify that it's by control type rather than by grouping (i.e. arrangement).
Greg suggests things like hiding/showing by category is good for technique but too detailed for the SC.
Re priority of Kim's sub-items such as customization of the labels, Greg suggests we may not want to go into too much detail because ability to customize *thing* should be general and required for almost everything (e.g. how links are visually distinguished).
Kim worries that because the user agent is overlaying information it may not be covered by existing SC's about customization.
Kelly agrees it is different than normal rendered content.
It sounds like we're adding a third general category of elements: (a) user agent user interface elements, (b) elements of rendered content, and now (c) elements the user agent overlays onto or adds to rendered content.
A tooltip that appears when you hover the mouse over an element, which type is that?
Kim notes a difference that one is modal and the other coexists with the rendered content.
Kelly suggests that Kim continue working on this, and specifically think about differing priorities for separate portions.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/July 16 or 17/July 14 or 16/ Succeeded: s/rrsagent make minutes// Found Scribe: Greg Inferring ScribeNick: Greg Default Present: +1.408.996.aaaa, kford, Jeanne, +1.617.325.aabb, +1.425.895.aacc Present: KFord Jeanne David Kim Greg Regrets: Jimk_Mark Simon Henny Jan Found Date: 09 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/09-ua-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]