See also: IRC log
<trackbot> Date: 02 July 2009
<KFord> http://www.w3.org/2002/09/wbs/36791/20090602/
KF: JS sent out updated Editors' Draft http://www.w3.org/WAI/UA/2009/ED-UAAG20-20090625/
JS: I am waiting for approvals on annoucements and status and to get on the publishing schedule.
http://www.w3.org/2002/09/wbs/36791/20090602/
http://www.w3.org/2002/09/wbs/36791/20090602/results -- RESULTS
<KFord> http://www.w3.org/WAI/UA/tracker/actions/open
JS: I am looking at Greg's comments on 4.1.9 : #55, and #70-#74. http://lists.w3.org/Archives/Public/public-uaag2-comments/2009Apr/0000.html
<scribe> ACTION: GL to update the 10 June comments and submit a proposal for new 4.1.9 [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action01]
<trackbot> Created ACTION-202 - Update the 10 June comments and submit a proposal for new 4.1.9 [on Greg Lowney - due 2009-07-09].
GL: First the group has to decide the answers to five questions, and that will determine what will be in the proposal.
http://www.w3.org/2002/09/wbs/36791/20090602/results#xq2
KP: This is a significant issue with speech input, where the focus can be lost to another window and the user can be typing or inputting in another window that is not realized.
KF: We have a SC about no keyboard trap, but this is just the opposite. We have an SC that shows the location of the focus.
<scribe> ACTION: KP to analyze the document to see if there is an SC that addresses the issue of focus being ripped away. [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action02]
<trackbot> Created ACTION-203 - Analyze the document to see if there is an SC that addresses the issue of focus being ripped away. [on Kimberly Patch - due 2009-07-09].
<scribe> ACTION: KP to draft a proposal for numbering links for speech input. [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action03]
<trackbot> Created ACTION-204 - Draft a proposal for numbering links for speech input. [on Kimberly Patch - due 2009-07-09].
GL: I am still not sure what the user interface that we are envisioning for this item.
KF: People don't want mouse-only actions, and the way it is written up as event handlers.
GL: This is written up as APIs so the AT can provide access to event handlers.
KF: But that locks out the keyboard only users who are not using AT.
GL: This is a standard answer for
software developers, but for web content, the browser should
provide a mechanism to repair any event handler written by a
web developer that is not keyboard accessible.
... The user agent could have a mode where all items that have
input associated with them.
KF: By hitting a key, I would be able to step through every action. Is it needed? Sometimes, yet.
GL: The user agent has to provide keyboard access to any object that has some kind of input.
KF: We are in agreement that we need this concept, but in terms of the technical "how you do this" this is where the technical points that GL is raising belong.
GL: Does any user agent actually
do it? If not, I would change it from level A to something
higher.
... do we want all existing user agents to fail to reach level
A?
... or do we want to put a note saying that it will be level A
in a future version?
<Greg> In fact, if no UA do it, I recommend making it lower priority now and marking it as scheduled to be upgraded to A in the next version of the standard. (I call that a "Future Requirement", as opposed to "Requirement" or "Recommendation".)
KF: We need to do a reality check on the entire document to see if it can be implemented.
<Greg> Concerned about the term “alerted”, which is undefined. I assumed it means something automatic, such as what, a menu popping up? A transient message box popping up and disappearing? Change in menu items that aren’t visible unless one activates the menu?
KF: Are we willing to accept the proposal and put it in the document as is, or does the proposal itself need more work?
<Greg> Perhaps something like "The user can use the keyboard to determine the list of input device event handlers associated with any rendered content element and activate any of those event handlers"
GL: the user can determine the
list of user event handlers associated with any rendered
element and determine and activate any of those event
handlers.
... the user tabs to an item, brings up a context menu that
includes a list of options that would include actions and you
would be able to step through the actions.
<Greg> It seems to me unfortunate that we have to divide a single piece of functionality into two success criteria scattered in different sections. After all, there's no benefit to being able to enumerate the input event handlers for an item if you don't also have the ability to trigger them.
JS: Put them all into 4.1.X because they make sense together.
GL: 3.13 is more resticted to links, so it doesn't belong there either.
<Greg> It seems like the proposed 3.13.x (perceive event handlers) does not belong under 3.13 (provide link information) because it applies to much more than just links. Or, alternatively, we could change 3.13 to apply to more than just links, and I think that would make sense, since things other than links are interactive and almost all of the things in 3.13 could probably apply to them. Maybe?
http://www.w3.org/WAI/UA/2009/ED-UAAG20-20090625/#principle-operable
JS: We have a whole guideline 4.2
about event handlers. This does not belong in 4.2 at all.
... I propose taking Jan's wording of 3.13.X "3.13.X Perceive
Event Handlers: The user has the option to be alerted to
any input device event handlers (including those for pointing devices,
voice, etc.) that are associated with the current content focus (Level A).
Use it instead of the existing 4.2.2
KF: In some scenarios, people do not want to step through the entire process, mouse down, mouse up, etc. They want to activate it at once.
Perceive Event Handlers: The user has the option to be alerted to
any input device event handlers (including those for pointing devices,
voice, etc.) that are associated with the current content focus (Level A).
Perceive Event Handers: The user can determine any input device event handlers (including those for pointing devices, voice, etc) that are associated with the current content focus.
Perceive Event Handers: The user can determine visually and programmatically any input device event handlers (including those for pointing devices, voice, etc) that are associated with the current content focus.
GL: Programmatically doesn't belong in 4.
<Greg> Programmatic access is and should remain covered under Principle 2 (Facilitate programmatic access).
JS: But I don't want visual indication to be overlooked for the keyboard users who are dependent on sight. But we can't have visual without programmatically.
4.2.2 Perceive Event Handers: The user can determine any input device event handlers (including those for pointing devices, voice, etc) that are associated with the current content focus.
<Greg> I think that's fine.
KF: I think we should leave out the modalities : visual, audio.
RESOLUTION: Replace existing 4.2.2 with new text: 4.2.2 Perceive Event Handers: The user can determine any input device event handlers (including those for pointing devices, voice, etc) that are associated with the current content focus.
<Greg> Even though it doesn't explicitly say the user has to be able to do this with the keyboard, that's covered by the general keyboard access requirements.
<scribe> ACTION: JS to update document with new text for 4.2.2 [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action04]
<trackbot> Created ACTION-205 - Update document with new text for 4.2.2 [on Jeanne Spellman - due 2009-07-09].
4.2.3 Operate Event Handlers: The user can activate, via the keyboard,
any input device event handlers (including those for pointing devices,
voice, etc.) that are associated with the current content focus. The user can step through the events or execute them at once. (Level A).
4.2.3 Operate Event Handlers: The user can activate, via the keyboard, any input device event handlers (including those for pointing devices, voice, etc.) that are associated with the current content focus. The user can step through the events or execute them at once. (Level A).
<Greg> I think perhaps what we're trying to do is have 4.2.1 activate them, 4.2.2 determine them, and 4.2.3 activate them as logical groups e.g. a shortcut to do mouse click that triggers mouse down followed by mouse up.
JS: Let's change the order so that we Determine them, activate them, and activate as logical groups.
<Greg> Yes, and it makes sense to order them 1. determine 2. activate 3. logical groupings.
<scribe> ACTION: JS to change numbering of 4.2 to change the order to: 1. determine 2. activate 3. logical groupings. [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action05]
<trackbot> Created ACTION-206 - Change numbering of 4.2 to change the order to: 1. determine 2. activate 3. logical groupings. [on Jeanne Spellman - due 2009-07-09].
<Greg> 4.2.3 "high level input sequences" made up of low-level input events (e.g. mouse click made up of mouse down followed by mouse up, or mouse drag made up of mouse down, mouse move to destination, mouse up).
GL: the user can trigger/activate/perform logical groupings of event sequences.
<Greg> "logical sequences" makes more sense "logical groupings" because in all cases the order is vital.
the user can trigger/activate/perform logical sequences of event handlers (e.g. mouse click made up of mouse down followed by mouse up, or mouse drag made up of mouse down, mouse move to destination, mouse up).
<Greg> "The user can activate logical sequences of input handler events as a shortcut for triggering the individual events separately."
4.2.3 Event Sequences: The user can activate combined sequences of events handlers (e.g. mouse click made up of mouse down followed by mouse up, or mouse drag made up of mouse down, mouse move to destination, mouse up).
<Greg> "Activate input event sequences"
4.2.3 Event Sequences: The user can activate combined sequences of events (e.g. mouse click made up of mouse down followed by mouse up, or mouse drag made up of mouse down, mouse move to destination, mouse up).
<scribe> ACTION: SH to write a new proposal for 4.2.3 for next week's survey. [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action06]
<trackbot> Sorry, amibiguous username (more than one match) - SH
<trackbot> Try using a different identifier, such as family name or username (eg. sharper, shayes)
<scribe> ACTION: sharper to write a new proposal for 4.2.3 for next week's survey. [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action07]
<trackbot> Created ACTION-207 - Write a new proposal for 4.2.3 for next week's survey. [on Simon Harper - due 2009-07-09].
http://lists.w3.org/Archives/Public/w3c-wai-ua/2009AprJun/0067.html
Results: http://www.w3.org/2002/09/wbs/36791/20090602/results#xq3
<Greg> It seems like 4.1.5 has some overlap with Kim's proposal to number links, display the numbers, and provide keyboard shortcuts for them.
KF: User shortcuts are not easily discoverable for both the browser frame and for the web content. Why are they split apart.
GL: I don't know that any user
agent complies and it is too vague.
... there is ambiguity in "direct keyboard command". I was
splitting it up so that it could be given different priorities.
I thought the web content should be AA, because no browser does
it today
KF: This is a great candidate for that reality check
RESOLUTION: Update
document with new text: 4.1.5 (Proposed Revision) Present
Direct Commands in Rendered Content: The user has the option to
have any recognized direct commands (e.g. accesskey) in
rendered content be presented with their associated elements
(e.g. "[Ctrl+t]" displayed after a link whose accesskey value
is "t", or an audio browser reading the value or label of a
form control followed by "accesskey control plus t"). (Level
A)
... Update the document with new SC: 4.1.x (Proposed Addition)
Present Direct Commands in User Interface: The user has the
option to have any direct commands (e.g. keyboard shortcuts) in
the user agent user interface be presented with their
associated user interface controls (e.g. "Ctrl+S" displayed on
the "Save" menu item and toolbar button). (Level
AA)
<scribe> ACTION: JS to update document with new SC: 4.1.x (Proposed Addition) Present Direct Commands in User Interface: The user has the option to have any direct commands (e.g. keyboard shortcuts) in the user agent user interface be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA) [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action08]
<trackbot> Created ACTION-208 - Update document with new SC: 4.1.x (Proposed Addition) Present Direct Commands in User Interface: The user has the option to have any direct commands (e.g. keyboard shortcuts) in the user agent user interface be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA) [on Jeanne Spellman - due 2009-07-09].
<scribe> ACTION: JS to update document new text for 4.1.5: 4.1.5 (Proposed Revision) Present Direct Commands in Rendered Content: The user has the option to have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (e.g. "[Ctrl+t]" displayed after a link whose accesskey value is "t", or an audio browser reading the value or label of a form control followed by "accesskey control plus t"). (Level A) [recorded in http://www.w3.org/2009/07/02-ua-minutes.html#action09]
<trackbot> Created ACTION-209 - Update document new text for 4.1.5: 4.1.5 (Proposed Revision) Present Direct Commands in Rendered Content: The user has the option to have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (e.g. "[Ctrl+t]" displayed after a link whose accesskey value is "t", or an audio browser reading the value or label of a form control followed by "accesskey control plus t"). (Level A) [on Jea
KF: Since Greg needs guidance from the group in clarifying what we want to achieve with the guidelines.
GL: I can't submit draft wording until I understand what the group wants the guideline to mean.
KF: We will include Simon's issues from the email of 4 June
AND Greg's questions on 4.1.9
KF: We will talk about workflow at the next meeting and what deadlines should be.
<scribe> chair: Kelly_Ford
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) No ScribeNick specified. Guessing ScribeNick: jeanne Inferring Scribes: jeanne Default Present: jeanne, kford, Greg, Kim, sharper Present: jeanne kford Greg Kim sharper Kelly Jeanne Simon Regrets: Jan Henny Jim David Found Date: 02 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/02-ua-minutes.html People with action items: gl js kp sh sharper[End of scribe.perl diagnostic output]