See also: IRC log
scribe Simon Harper
<scribe> scribe: Simon Harper
<scribe> ScribeNick: sharper
JB: Meetings to continue through July and August 2008
JB: Results available at http://www.w3.org/2002/09/wbs/36791/UAWG20080723/results
... How close to Heartbeat 1
... Towards end of August 2008
<Judy> ACTION: jb check on the pending question about timing of next publication vs timing of charter review for rechartering obligation [recorded in http://www.w3.org/2008/07/24-ua-minutes.html#action01]
JA: W3C Process - WG must put a
new working draft out every 3 months to make sure the group is
still working - means not working in the dark
... first Draft at CSUN in March 2008
JB: Plan for the end of August for the next draft.
RESOLUTION: Group aims for the end of August to publish next draft.
JA: Did everyone see http://www.tsbvi.edu/technology/uawg/thrashing.htm
JS: Listed principles and success criteria, went through and refined them and assigned a level now a much more focused list. Final results then split into levels. Then we have a list of everything removed (and more).
JA: Some of the removed ones (say 3rd) - have target destinations (just a feeling) - no specific place to drop it in.
JS: Concerned these may be lost.
<scribe> ACTION: JA: Place these possible lost items into the 'correct' locations. [recorded in http://www.w3.org/2008/07/24-ua-minutes.html#action02]
JB: Any of the items flagged with 'SHOULD' need to be in a new list / location.
Moving through Guideline 4.1 Ensure full keyboard access
JA: Sequential keyboard commands (tab, arrow, etc.) can be used to navigate between every UI operable control and interactive element in the rendered content. Level A
NOTE: These follow conventions, see 1.1
JA: Like hitting alt and then arrow keys to move through
JB: Maybe good as a test of these to read it out and see if there are any questions - may miss understanding, if concentrating on interpretation.
AC: Question - did we agree keyboard commands was a code-word / short hand for interaction by keyboard.
JS: I think so - do you have concerns.
AC: possible - lets wait - may
need a small change later.
... Doesn't see tab etc as a command as opposed to a keypress
KF: OK to replace terminology
ALL: Good change.
JB UI better than chrome but what is 'UI operable control and interactive element'
JA: Phrase-ology to indicate they must be operable - no tabbing through greyed out items on a menu.
AC: Windows menus now - can navigate to a greyed out item - is a good thing as the menu isn't growing and shortening in length. Maintains consistent behaviour - suggest 'every control' - not operable control
JB: Very different things
JA: Need to keep software and
... Lets agree on AC point and remove operable - objects?
KF: Default behaviour for inactive controls can't tab to them always - menus you can - dialogues you can't.
JB: Is one way to look at this - this is a level A requirement - identify it as every operable control - at this level, does that help?
KF: Akin to the philosophy used on Tuesday. Add a second one for AA to remove the operable - also want to follow OS conventions - Advocate leaving it as is, if we want to tab to all make this a level 2 option?
AC: struggling with this...
<AllanJ> SH: say: unless overridden by operating system convetion
KF: Gives an out, by adding confusion.
JA: OK for changes including AC changes wording just 'Key presses'
<AllanJ> Key presses (tab, arrow, etc.) can be used to navigate between every UI operable control, and interactive element in the rendered content.
<jeanne> Key presses (tab, arrow, etc.) can be used to navigate between every UI operable control, and between every interactive element in the rendered content.
JB: Objections... None.
Caret browse and select can be used to navigate between characters in rendered text content (incremental - character, word, line, element, all).
AC: What is it? Allows keyboard navigation to all content that you a browsing.
A Possible Definition:
The term caret is used in graphical user interface terminology where it means a text insertion point indicator, frequently represented by a blinking vertical bar. In this context, it may be used interchangeably with the word cursor, although the latter term is often reserved for a mouse pointer.
JS: Any text in the rendered context...
AC refinement - break into 2: navigation and select?
<jeanne> Any text in the rendered content can be navigated and/or selected using the keyboard.
AC: Any text or picture:
JS: Any element? Object?
JA: Some elements could be a problem - re flash
<jeanne> Text in the rendered content can be navigated and/or selected using the keyboard.
KF: That is not beyond user agents control.
JB: does this gives us the meaning we think it does
AC: need some generic phrase to capture this
<AllanJ> SH: don't we really mean CUT/PASTE
<AllanJ> SH: replace TEXT with RENDERED CONTENT
<AllanJ> JS: text is too important., Rendered content does't mean character, etc.
<AllanJ> SH: put the parenthetical back in (incremental ...)
<jeanne> Rendered content (character, word, line, image, element, all) can be navigated and/or selected using the keyboard.
<jeanne> Rendered content (e.g.character, word, line, paragraph, image, element, all) can be navigated and/or selected using the keyboard.
KF: Too complicated, paragraph selection is above and beyond - what you want is to select as implemented in the OS - see 1.1
JA: Do we really need to say this on everyone?
<jeanne> Rendered content (e.g.character, word, line, paragraph, image, element, all) can be navigated and/or selected using the keyboard. See 1.1
JB: should it be see guideline 1.1 or a full phrase re OS conventions?
KF: none - let's not repeat
... should say at the beginning (in one spot) which?
<jeanne> Rendered content (e.g.character, word, line, paragraph, image, element, all) can be navigated and/or selected using the keyboard consistent with operating system conventions.
<jeanne> Rendered content (e.g.character, word, line, paragraph, image, element, all) can be navigated and/or selected using the keyboard (consistent with operating system conventions).
JB: Tend to want to move on right now -
<jeanne> Rendered content (e.g. by character, word, line, paragraph, image, element, all) can be navigated and/or selected using the keyboard (consistent with operating system conventions).
<scribe> ACTION: KFord Clarify - Rendered content (e.g. by character, word, line, paragraph, image, element, all) can be navigated and/or selected using the keyboard (consistent with operating system conventions). [recorded in http://www.w3.org/2008/07/24-ua-minutes.html#action03]
No keyboard trap. The user agent provides at least one hot key to restore keyboard focus to a known location.
AC: known location - ambiguous - if long page, if only way to restore focus is (alt+D) could be a problem.
JB: Other provisions are sentences to introduce the point - should be consistent - frame the checkpoint - shorthand to the group - not suitable for general.
JA: remove No keyboard trap is OK?
JB: Still not right?
JA: Any developers will understand keyboard trap?
... Do we need to get this down to letter perfect level?
... checking inadvertant interpretations - not letter perfect
JA: Issue Kelly?
JB: looks sloppy compared to others
JA: Anyone does not know?
<jeanne> The user agent provides at least one keyboard command to restore keyboard focus to a default location.
JA: Escape is critical
<jeanne> The user agent provides at least one prominent keyboard command (e.g. escape key) to move keyboard focus to a default location.
JB: not obscure hot key - what about escape?
<scribe> ACTION: Allanj Clarify- The user agent provides at least one prominent keyboard command (e.g. escape key) to move keyboard focus to a default location. [recorded in http://www.w3.org/2008/07/24-ua-minutes.html#action04]
KF: don't want to see escape key - not appropriate
Direct keyboard commands can be used to activate the following important functions
JA: the List is already mentioned
... this just says you have to have a keyboard control for the list (defined elsewhere)
JB: Maybe forgo the list, thoughts?
AC: should we use keyboard presses as opposed to commands
JA: term needed for browser control
JS: would like to get away from sequential and direct
AC: key-presses would get you the entire list - except maybe volume control?
<jeanne> Key press can be used to activate the following important functions (list) Level A
AC: lets go to 5 and return to 4 at the end of the telecon
User has the option to configure the keyboard processing order (UI, extensions, recognized content (Access key, AT), unrecognized content)
JB: all in () could be
interpreted differently by different people - can we
... is it intended to be a flat list?
... should start on 4 next week
... thrash wording next week as opposed to section review?
... Regarding (Remove - should be in...) items
JB: address A.4 A.5 and AA.1 next week
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Simon Harper Found ScribeNick: sharper WARNING: No "Topic:" lines found. Default Present: Jeanne, Judy, Jim_Allan, kelly, Cantor, Simon Present: James_Allan Simon_Harper Jeanne_Spellman Kelly Ford Judy Brewer Alan Cantor Regrets: Mark_Hakkinen Gregory_Rosmaita Jan Richards Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0046.html Got date from IRC log name: 24 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/24-ua-minutes.html People with action items: allanj ja jb kford WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]