See also: IRC log
<trackbot> Date: 22 April 2010
<scribe> scribe: allanj
<jeanne> http://www.w3.org/2002/09/wbs/36791/20100420/results
<kford> Survey link http://www.w3.org/2002/09/wbs/36791/20100420/results
gl: discusses edits
ja: MH comment - seems all messages require keyboard input
kp: stating the obvious is always good.
kf: do we want to edit now.
<scribe> ACTION: kf to rework 5.1.1. comments from survey http://www.w3.org/2002/09/wbs/36791/20100420/results [recorded in http://www.w3.org/2010/04/22-ua-minutes.html#action01]
<trackbot> Created ACTION-375 - Rework 5.1.1. comments from survey http://www.w3.org/2002/09/wbs/36791/20100420/results [on Kelly Ford - due 2010-04-29].
s/Submisssino/Submission
gl: issues with the SC
2. I find the draft wording of the SC very problematic. For example:
a. What if there is no submit control and the other method is the only method (e.g. a hotkey or menu item to send)? What about technologies other than HTML where there is no dedicated Submit control?
b. Could giving the user the ability to require confirmation before submitting or canceling forms be an acceptable alternative to disabling the default method?
c. The intent paragraph seems to focus almost exclusively on use of the Enter key, but the SC itself is much broader than that; the intent paragraph should address the full scope of the SC in order to justify that breadth.
d. Why would this be specific to form submissions? Wouldn't the problem be equally bad for, say, cases where the Escape key dismisses a form and causes the user to lose all the data they'd entered? By analogy wouldn't they want the ability to require a specific control rather than responding to the keyboard input when the focus is on other controls?
e. If there is a submit form control, and the author associates that with a keystroke (e.g. using the accesskey= to associate a key combination with the submit control, using Javascript to cause the Esc key to activate it), pressing that keystroke will activate the control and submit the form regardless of where the focus was in the form. In that case, the implementation passes the SC as...
scribe: it's currently worded, despite clearly not meeting its intent.
f. If this applies only to forms, I can imagine it leading to debate over whether something is or is not a form as developers, authors, or purchasers/regulators try to force or avoid implementing this feature. We do not define forms or submission controls, and while they're clear in HTML, they may not be clear in other technologies (e.g. Canvas with AJAX).
kp: 'enter' key is much larger issue that other keys, eg 'esc'
gl: could rewrite to specifically about the enter key
kp: with speech you are saying 'enter' and 'touch' a lot to move the cursor or perform action. these are automatic reflex actions.
this is from UAAG10 5.5 Confirm form submission (P2) 1. Allow configuration to prompt the user to confirm (or cancel) any form submission.
gl: this is much better and more specific than what we have now.
technique: Configuration is preferred, but is not required if forms can only ever be submitted on explicit user request.
also in WCAG 2.0 GL 3.3 Input Assistance: Help users avoid and correct mistakes.
discussion of issue
kp: option of a bother box to
confirm submission, is useful
... but not the same thing as removing automatic form
submission
gl: the goal is good. need to
craft the wording so it says what we want it to.
... what if no submit control
... could say specifically for HTML execute only recognized
submit buttons
kp: how about being able to remap the submit button keystroke
kf: but 'eneter' is not just for
submit' hard to remap
... if focus is not on submit button then the form is not
submitted when user hits enter
... long form scenario, completed required items, just hit
enter the skip the other 5 form items, need user preference
<patrickhlauke> just joined
<patrickhlauke> managed to reshuffle
gl: ok with rewrite for specific form (submitbutton)
<patrickhlauke> sounds +1 from me
kp: +1
<patrickhlauke> suggested maybe "which keys trigger special/additional actions when entering text in a form" or something?
<patrickhlauke> so it's a bit more generic?
<patrickhlauke> 4.1.7 is a hit for "hotkey" in the document
<Greg> "The user has the ability to redefine the keyboard shortcut for submitting recognized forms."
pl: are there other situations where auto execution is a problem
gl: canceling is another one.
ph: suppose a browser says if user hits 'delete' twice then forms is canceled.
kp: 'enter' is an overloaded key
kf: is remapping the way to go.
<Greg> "The user has the ability to redefine the keyboard shortcuts specific for forms for recognized forms."
<Greg> (Ignore that, that was an error from hitting Enter instead of Del!)
<patrickhlauke> happy with it if we just want to keep it narrowly defined (forms/submission)
ja: suggests UAAG10 wording
<patrickhlauke> if other parts (remapping in general) would take care of other situations
ja: does UA know when user is in a form, and knows that 'enter' will submit a form
ph: yes
proposal: "The user has the ability to redefine the keyboard shortcuts specific for forms for recognized forms."
<Greg> I think Patrick asked if this was already covered. It *might* be covered by 4.1.12 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). (Level AA)
<patrickhlauke> happy that 4.1.12 covers more generic situations
<kford> The user has the ability to redefine keyboard shortcuts for automatic form submittal and cancellation.
<patrickhlauke> +1
+1
<Greg> I'm not sure about using the word "automatic" there.
<patrickhlauke> agree with greg: shortcut covers the rationale that kford used for adding "automatic"
gl: perhaps shortcut is better.
kf: delete 'automatic'
<kford> Take 2:
<kford> The user has the ability to redefine keyboard shortcuts for recognized form submittal and cancellation.
<patrickhlauke> "submittal and cancellation of recognised forms"
<patrickhlauke> +1
<patrickhlauke> "The user has the ability to redefine keyboard shortcuts for submittal and cancellation of recognised forms"
+1
"The user has the ability to redefine keyboard shortcuts for submitting and cancelling of recognised forms
<patrickhlauke> "The user has the ability to redefine keyboard shortcuts for submitting and cancellating recognised forms"
<patrickhlauke> oops
The user has the ability to redefine keyboard shortcuts for submitting and canceling recognized forms
<patrickhlauke> +1
<Greg> +1
<kford> +1 for making this the SC.
<scribe> ACTION: js add 5.2.1 "The user has the ability to redefine keyboard shortcuts for submitting and canceling recognized forms" replacing old version [recorded in http://www.w3.org/2010/04/22-ua-minutes.html#action02]
<trackbot> Created ACTION-376 - Add 5.2.1 "The user has the ability to redefine keyboard shortcuts for submitting and canceling recognized forms" replacing old version [on Jeanne Spellman - due 2010-04-29].
<scribe> ACTION: KP to redo IER for 5.2.1 form submission to reflect new SC [recorded in http://www.w3.org/2010/04/22-ua-minutes.html#action03]
<trackbot> Created ACTION-377 - Redo IER for 5.2.1 form submission to reflect new SC [on Kimberly Patch - due 2010-04-29].
discuss benchmark vs standard
User agents will provide documentation in a format that is accessible. If provided as Web content, it must conform to WCAG 2.0 Level "A" and if not provided as Web content, it must be in conformance to a published accessibility benchmark and identified in any conformance claim for the user agent. This benefits all users who utilize assistive technology or accessible formats.
<patrickhlauke> benchmark or standard or guidelines. i'd lean towards guideline, personally
+1 guideline
<Greg> replace "benchmark" with "standard or set of guidelines"?
<patrickhlauke> +1
<sharper> sh: +1
User agents will provide documentation in a format that is accessible. If provided as Web content, it must conform to WCAG 2.0 Level "A" and if not provided as Web content, it must be in conformance to a published accessibility standard or set of guidelines and identified in any conformance claim for the user agent. This benefits all users who utilize assistive technology or accessible formats.
<patrickhlauke> if i may copy/paste my question from the survey right here as well for discussion:
<patrickhlauke> I'm not certain if the wording for the non-Web content bit provides strange loopholes. What if a user agent provides its documentation purely as a braille manual? It's a published, recognised format...but will be of little to no use for deaf users, for instance.
<kford> +1
<Greg> replace "and identified" with "that is identified"
<patrickhlauke> (sorry currently eating, so don't want to burden the audio call with chewing noises)
<Greg> I agree with Patrck's observation that "accessibility standard" is too broad, but I'm not sure of better substitute
discussion of (b) accessible platform format: not Web content and conforms to a published accessibility benchmark that is identified in the conformance claim (e.g., when platform-specific documentation systems are used).
<patrickhlauke> limit to electronic (i.e. "documentation in electronic form") ?
JS: that could be video. how about 'electronic text'
kf: if I use a telephone only browser that has only an audio manual. how to I make largeprint out of the audio file
<Greg> I believe to be accessible, documentation has to be available as electronic text that can be reformatted, converted to Braille, etc.
kf: i can call into voice mail and have text message read to me. the system cannot provide it to me in any other format
<patrickhlauke> suggestion
<patrickhlauke> drop the distinction Web/non-web and go for
<patrickhlauke> "User agents will provide documentation in a format that is accessible in accordance with a published accessibility benchmark and identified in any conformance claim for the user agent. This benefits all users who utilize assistive technology or accessible formats."
<patrickhlauke> as a starting point
<patrickhlauke> and then use example of WCAG 2 for web-based documentation
kp: if you have a developer, they
may want the documentation in a different format
... if you have online help, make sure it complies with the
standard.
<jeanne> +1 to not using the term "benchmark" with accessibility guidelines. Benchmark has a different meaning to UA developers. I prefer "guidelines" myself.
gl: all documentation should be wcag2 conformant
<patrickhlauke> +1
kf: change SC and EIR a bit
<Greg> The product documentation is available in a format that conforms to WCAG 2.0 Level "A".
<patrickhlauke> should we then add, in an example, "if the type of documentation does not fall within the 'Web Content' remit of WCAG 2.0, it should nonetheless aim to follow WCAG 2.0's principles" or something to that effect?
<Greg> I don't think we need to say "At least one version of the documentation".
<patrickhlauke> happy to just keep it focused on WCAG 2.0 compliance of documentation
<Greg> 5.3.1 Accessible documentation: The product documentation is available in a format that conforms to WCAG 2.0 Level "A" (Level A)
+1
<sharper> +1
<patrickhlauke> just wondering if we need/want to cover edge cases of products without web content-able documentation
<kford> +1+1 to this.
<patrickhlauke> "if they don't want/can make their documentation available in an electronic form that can't work under WCAG 2.0, then they can't claim conformance for this part" +1
gl: webable vs electronic. needs to be wcag2 conformant,
<patrickhlauke> I would add "at least"
<patrickhlauke> i.e. at least WCAG 2.0 level A
<patrickhlauke> so if they can go to AA or AAA then great
<patrickhlauke> +1
5.3.1 Accessible documentation: The product documentation is available in a format that conforms to at least WCAG 2.0 Level "A"
<kford> +1
<patrickhlauke> level A (or higher) +1
<Greg> +1
<patrickhlauke> happy with either one ("at least WCAG..." or "level A (or higher)")
<kford> +1 to amending.
<scribe> ACTION: JS to add 5.3.1 "> 5.3.1 Accessible documentation: The product documentation is available in a format that conforms to WCAG 2.0 Level "A" or greater" [recorded in http://www.w3.org/2010/04/22-ua-minutes.html#action04]
<trackbot> Created ACTION-378 - Add 5.3.1 "> 5.3.1 Accessible documentation: The product documentation is available in a format that conforms to WCAG 2.0 Level "A" or greater" [on Jeanne Spellman - due 2010-04-29].
<scribe> ACTION: JA to rewrite IER for 5.3.1 to reflect new SC [recorded in http://www.w3.org/2010/04/22-ua-minutes.html#action05]
<trackbot> Created ACTION-379 - Rewrite IER for 5.3.1 to reflect new SC [on Jim Allan - due 2010-04-29].
<patrickhlauke> my recommended change for 5.3.2 purely minor editorial
discussion of Greg's - Just a thought: should we require the documentation to address accessibility features that a product lacks?
kf: so folks don't look for some function that does not exist
ph: accessibility features do not exclude users with their particular needs
kp: the developer has to do something
kf: as an individual I like it, but can't really see documentation saying this is what we don't do
<scribe> ACTION: gl to mashup all of 5.3.2 for next week [recorded in http://www.w3.org/2010/04/22-ua-minutes.html#action06]
<trackbot> Created ACTION-380 - Mashup all of 5.3.2 for next week [on Greg Lowney - due 2010-04-29].
kf: gives example of generated content that is not exposed in the DOM or Accessibility API. that should be documents, so the user doesn't try to look for how to access generated content.
ph: what are the boundaries. this
is pretty broad. what is the level of call out
... do we need to go through every html and css element to
document all the cases
... the document would get really long, and be out of date,
because technology changes. don't want conformance to be 1
line
kf: needs to be useful.
ph: testability of this sc is problematic.
it seems if developers write what they don't do, then they are including the uaag conformance statement in their documentation
rssagent, make minutes
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) FAILED: s/Submisssino/Submission/ Succeeded: s/Submissino/Submission/ Found Scribe: allanj Inferring ScribeNick: AllanJ Default Present: kford, Jim_Allan, Jeanne, +1.425.895.aaaa, Greg, +1.617.325.aabb, patrick, sharper Present: Kim Patrick Greg Kelly Simon Jeanne Jim Regrets: MarkH PatrickH Found Date: 22 Apr 2010 Guessing minutes URL: http://www.w3.org/2010/04/22-ua-minutes.html People with action items: gl ja js kf kp[End of scribe.perl diagnostic output]