- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 22 Apr 2010 13:44:12 -0500
- To: "'WAI-UA list'" <w3c-wai-ua@w3.org>
From: http://www.w3.org/2010/04/22-ua-minutes.html
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
22 Apr 2010
See also: IRC log http://www.w3.org/2010/04/22-ua-irc
Attendees
Present
Kim, Patrick, Greg, Kelly, Simon, Jeanne, Jim
Regrets
MarkH
Chair
KellyFord, JimAllan
Scribe
allanj
Contents
* Topics
1. open action items http://www.w3.org/WAI/UA/tracker/actions/open
2. Survey http://www.w3.org/2002/09/wbs/36791/20100420/
3. 5.1.1
4. 5.2.1 Form Submission
5. 5.3.1 accessible format
6. 5.3.2 Document Accessibility Features
* Summary of Action Items
<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
open action items http://www.w3.org/WAI/UA/tracker/actions/open
Survey http://www.w3.org/2002/09/wbs/36791/20100420/
5.1.1
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].
5.2.1 Form Submission
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].
5.3.1 accessible format
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].
5.3.2 Document Accessibility Features
<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
Summary of Action Items
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]
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]
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]
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]
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]
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]
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 22 April 2010 19:17:25 UTC