- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 24 Jul 2014 14:01:13 -0500
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <CA+=z1Wmkj3JCpfwYjN2Cfre_-7BgmfBbnpGTWETUSk40mqvN9g@mail.gmail.com>
http://www.w3.org/2014/07/24-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference 24 Jul 2014
See also: IRC log - http://www.w3.org/2014/07/24-ua-irc
<http://www.w3.org/2014/07/24-ua-irc>
Attendees
PresentJeanne, Kim_Patch, Jan, Greg_Lowney, Jim_AllanRegretsKellyChairJim
Scribeallanj
Contents
- Topics <http://www.w3.org/2014/07/24-ua-minutes.html#agenda>
1. CA03 GL3.1 <http://www.w3.org/2014/07/24-ua-minutes.html#item01>
2. CAO4 autofill forms
<http://www.w3.org/2014/07/24-ua-minutes.html#item02>
3. CA05 GL3.3 <http://www.w3.org/2014/07/24-ua-minutes.html#item03>
- Summary of Action Items
<http://www.w3.org/2014/07/24-ua-minutes.html#ActionSummary>
------------------------------
<trackbot> Date: 24 July 2014
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0025.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0024.html
<scribe> scribe: allanj
CA03 GL3.1
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0027.html
*RESOLUTION: remove GL 3.1*
... mark CA01, 02, 03 and OP05 as closed reference
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0027.html
CAO4 autofill forms
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0024.html
Related to GL3.2
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0024.html
close action-1000
<trackbot> Closed action-1000.
action-999
<trackbot> action-999 -- Jan Richards to Start a draft sc re: saving
certain form inputs -- due 2014-07-24 -- OPEN
<trackbot> http://www.w3.org/WAI/UA/tracker/actions/999
3.2.X Form Auto-Fill: The user can have textual (and numeric) form field
values stored and auto-filled for at least the following: (Level AA)
- user's name
- user's email address
- user's phone number
Intent of Success Criterion 3.2.X:
Users with various disabilities benefit from auto-fill functionality,
including people who type slowly and people who have difficulty with
letter/number order.
Examples for Success Criterion 3.2.X:
- Michael is dyslexic and frequently spells words incorrectly, including
his name and email address. Auto-fill reduces the number of fields he must
fill out in on-line forms.
Related Resources for Success Criterion 3.2.X:
- None
jr: low bar, no privacy problems
<Greg> Do we need to add wording limiting it to *recognized* fields of
those types?
gl: intent could include a memory issues
jr: level?
ja: +1 AA
<Greg> "Users with various disabilities benefit from auto-fill
functionality, including people who type slowly, people who have difficulty
with letter/number order or short-term memory."
js: ok on desktop browsers, not sure about mobile
gl: what about webbased browser, doesn't know who you are from session to
session, does it need to save info between sessions
<Greg> Would a web-based browser, which doesn't know who the user is, have
to save and auto-fill these values for the duration of one session?
<Jan> http://www.computerhope.com/issues/ch001377.htm
jr: applicability note - if the platform does not save between sessions
then exampt
... will check if this is an edge case for webbased browsers
<Jan> http://www.w3.org/TR/2013/WD-UAAG20-20131107/#sc_271
jr: we have allow persistent a11y settings...what if they don't do that?
... is this a fail on platform?
gl: do we have a list of web-based browsers
<Greg> A web-based browser that kept no user-specific info could allow the
user to save preference settings on their local machine, and load them in
future sessions.
jr: could leverage base browser.
js: don't want this required for a11y on a pubic machine
<Jan> s\pubic\public
gl: privacy should be over arching on all systems
<Greg> The privacy and public machines issue applies to all of 2.7
(Configure and store preference settings) as well.
gl: library, low vision scenario,
<Greg> Right now 2.7.1 does not include an exception for public settings.
jr: perhaps note goes on 2.7.1. User agents are allowed to have public
access modes that do not save setting, etc.
gl: expection path for privacy...and system security
<Greg> Somewhere we may need to acknowledge and accommodate system
administrators' need to lock down some settings.
<jeanne> *ACTION:* jeanne to add a normative note to 2.7.1 to say that user
agents may have a public access setting that turns this off. Maybe it
should be a global applicability note. also see Jan's proposal for SC 3.2
[recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action01]
<trackbot> Created ACTION-1001 - Add a normative note to 2.7.1 to say that
user agents may have a public access setting that turns this off. maybe it
should be a global applicability note. also see jan's proposal for sc 3.2
[on Jeanne F Spellman - due 2014-07-31].
<jeanne> *ACTION:* Jeanne to add Jan's proposal for adding an SC for
retention of form auto-fill 3.2.X
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0024.html
[recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action02]
<trackbot> Created ACTION-1002 - Add jan's proposal for adding an sc for
retention of form auto-fill 3.2.x
http://lists.w3.org/archives/public/w3c-wai-ua/2014julsep/0024.html [on
Jeanne F Spellman - due 2014-07-31].
jr: huge privacy issues related saving form data for completing form later.
it should be a WCAG issue. for the content to save a partially filled out
form.
<Greg> Per Jeanne's example, perhaps if we require auto-fill we should
require the UA let the user edit or delete the saved information.
gl: perhaps we need sc to edit the autofill information
kp: that is a user control issue
jr: saving form data is a computer control issue.
gl: autofill remembers data between sessions. developers need to know this
<Greg> In the Intent we could clarify that it's agnostic in many
implementation details, such as whether the UA remembers values filled in
vs. letting the user configure auto-fill values.
<Jan> *ACTION:* JR add more to the 3.2.X SC's intent to call out that it
could be auto-detected or user entered and could be editable. [recorded in
http://www.w3.org/2014/07/24-ua-minutes.html#action03]
<trackbot> Created ACTION-1003 - Add more to the 3.2.x sc's intent to call
out that it could be auto-detected or user entered and could be editable.
[on Jan Richards - due 2014-07-31].
proposed resolution CA04: created new SC for autofill, however, saving
partially filled forms is fraught with privacy issues, and seems to be more
of a WCAG issue and delt with by the author
*RESOLUTION: CA04 created new SC3.2.x*
gl: seems we are through out because of edge case of public machine
js: no, its an author/content issue...
gl: a UA could save form information. may not work in banking, or dynamic
forms, but work in 90% of the cases
<jeanne> 3.2.2 Back Button: The user can reverse recognized navigation
between web addresses (e.g. standard "back button" functionality). (Level
AA)
<Greg> Re saving unsubmitted form data, I'm leery of saying we're rejecting
it because of privacy issues. On single-user systems providing an option to
save these values is not a privacy concern. The problem with multi-page
forms and custom controls are for WCAG, but for simple, single-page forms,
using standard form controls, the UA could certainly provide the auto-save
and restore values. It...
<Greg> ...would fail on dynamic pages and other edge cases, but in 95% of
cases it would be valuable. However, only in the fairly small set of cases
where the user does leave and return, or the browser crashes, in the middle
of the process, or when the form needs to be repeated periodically.
<Greg> But because it's late in the process I won't fight for adding a new
SC.
ja: CA-TF use case - filling a form, need information , takes a while to
find retrieve information, return to form and it has timed out. want some
kind of saving feature
<Greg> Jeanne suggests expanding 3.2.2 (Back Button) to include restoring
the state of the page. Do we already have *something* about restoring
state, e.g. scroll location and selection?
<Greg> If we did have an SC about restoring state, we can clarify in the
Intent or a note that we intentionally leave the scope vague, as in the UA
can choose how long it wants to save state information for a page, or how
many it will cache, and also acknowledge that there will be cases where the
UA can't recognize the "same page" due to dynamic content, etc.
kp: if I had a snapshot of a page, then could go back
... auto save, would be great if UA did auto save when writing text
1.8.10 Provide Viewport History: For user agents that implement a history
mechanism for top-level viewports (e.g. "back" button), the user can return
to any state in the viewport history that is allowed by the content,
including a restored point of regard, input focus and selection. (Level AA)
gl: autofill works on a url, not a save session
<Greg> Auto-fill typically works based on URLs, rather than only for things
in the History, whereas as Jan points out point of regard is only restored
from History.
jr: if you hit back you are returned to previous state POV etc. if retype
the URL then top of page
... anyone want to write a proposal for autosave
kp: I will write a proposal for autosave in form fields
<Jan> http://www.w3.org/TR/WCAG20/#time-limits-server-timeout
<jeanne> *ACTION:* jeanne to renumber Principle 3 to accommodate the
removal of 3.1 [recorded in
http://www.w3.org/2014/07/24-ua-minutes.html#action04]
<trackbot> Created ACTION-1004 - Renumber principle 3 to accommodate the
removal of 3.1 [on Jeanne F Spellman - due 2014-07-31].
CA05 GL3.3
<jeanne> *ACTION:* jeanne to renumber 3.2 since 3.2.5 is level A. [recorded
in http://www.w3.org/2014/07/24-ua-minutes.html#action05]
<trackbot> Created ACTION-1005 - Renumber 3.2 since 3.2.5 is level a. [on
Jeanne F Spellman - due 2014-07-31].
<scribe> *ACTION:* kim to write a proposal for autosave on pages with forms
[recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action06]
<trackbot> Created ACTION-1006 - to write a proposal for autosave on pages
with forms [on Kimberly Patch - due 2014-07-31].
Guideline 3.3 - Document the user agent user interface including
accessibility features
ja: comments seems to be content oriented
comment: Help icon should be available to every screen that takes the user
directly to relevant "how to use these features" or instructions
<Greg> It seems like their first suggestion is that every UA dialog box
have a help button/link indicated with a question mark or the word "help".
gl: they want a 'help' button on every component
<Greg> I assume they're talking not about basic UI conventions like how to
use buttons or menus, but about help on the particular functionality
provided by the dialog box (e.g. the Downloads window would have a help
icon the user can click to get to the Help pages relevant to that window).
<Greg> I understand that they want to avoid making users go through a huge
help system looking for topics relevant to their current task; instead,
they want task-relevant help to be available directly from where the user
is pursuing the task.
<Greg> This is actually very useful for a lot of users, with and without
disabilities (particularly cognitive, but not limited to that).
<Greg> But, it really gets us into forcing specific UI design decisions
onto the UA, which might not always fit with their UI design goals or
paradigms.
see 3.3.2, perhaps not just a11y info but actual UA functionality is part
of a11y info that should be provided to the user
<Greg> At least, that's how I interpret their first two paragraphs.
<Greg> I don't think we want to require every UA to provide
context-specific help, as useful as it is, although I suppose we could
recommend it (e.g. AA or AAA).
<Greg> Currently we don't require *any* documentation, other than about
accessibility features, much less making it context-sensitive.
jr: what about mobile browsers
... ATAG has something on this
<Jan> http://www.w3.org/TR/ATAG20/#gl_a42
A.4.2.2 Document All Features:
For each authoring tool feature, at least one of the following is true:
(Level AA)
(a) Described in the Documentation: Use of the feature is explained in the
authoring tool's documentation; or
(b) Described in the Interface: Use of the feature is explained in the
authoring tool user interface; or
(c) Platform Service: The feature is a service provided by an underlying
platform; or
(d) Not Used by Authors: The feature is not used directly by authors (e.g.
passing information to a platform accessibility service).
<Greg> UAAG20 3.3.2 Describe Accessibility Features is exactly like ATAG
4.2.1 Describe Accessibility Features.
UAAG 20 does not have equivalent to ATAG 4.2.2
gl: could use ATAG 4.2.2 not at level A
<Greg> The question is, do we want to add a new SC, at level AA or AAA,
that is based on 3.3.2 but about providing help on all functionality, not
just accessibility features.
proposal:
<Greg> If we did, then we could consider also adopting the first proposal
from CA05, which is to recommend help be context-sensitive (e.g. a help
button from individual UA UI windows and dialog boxes).
<Greg> Again that would not be Level A.
3.3.x Document All Features:
For each user agent feature, at least one of the following is true: (Level
AA)
(a) Described in the Documentation: Use of the feature is explained in the
user agent's documentation; or
(b) Described in the Interface: Use of the feature is explained in the user
agent's user interface; or
(c) Platform Service: The feature is a service provided by an underlying
platform; or
(d) Not Used by Users: The feature is not used directly by users (e.g.
passing information to a platform accessibility service).
<Greg> If we add an SC for general help, we should consider modifying the
structure used by 3.3.2 to also accommodate things which follow platform
conventions (e.g. don't need to describe what a Play button does).
ja: how do we do that?
rrsagent: make minutes
<Greg> I'm a little nervous about an SC requiring help cover every single
little check box and radio button, even when their function is
self-evident. I've seen Help where they just list all the controls with
descriptions that just parrot back their names.
<Greg> But, how do you measure whether the function of something is
self-evident?
<Greg> Still, if ATAG adopted it, I guess we can as well.
<Greg> Perhaps change "(c) Platform Service: The feature is a service
provided by an underlying platform" to also include UA UI features that
copy or emulate the UI of an equivalent platform feature. For example, if
the UA provides a File Open dialog box that uses custom controls but looks
and feels exactly like the standard File Open dialog box provided by the
OS, they probably don't need to...
<Greg> ...document it any more than they would if they simply used the
OS-provided version.
<Greg> If the UA doesn't have to document the OS-provided dialog box, it
shouldn't have to document one that is identical, but just happens to be
implemented separately.
<Greg> Jim: we want to encourage them to use standard dialog boxes, as
they're more accessible, so making them document custom-implemented ones is
reasonable.
<jeanne> *ACTION:* jeanne to add 3.3.x as stated above [recorded in
http://www.w3.org/2014/07/24-ua-minutes.html#action07]
<trackbot> Created ACTION-1007 - Add 3.3.x as stated above [on Jeanne F
Spellman - due 2014-07-31].
*RESOLUTION: add 3.3.x Document All Features:*
For each user agent feature, at least one of the following is true: (Level
AA)
(a) Described in the Documentation: Use of the feature is explained in the
user agent's documentation; or
(b) Described in the Interface: Use of the feature is explained in the user
agent's user interface; or
(c) Platform Service: The feature is a service provided by an underlying
platform; or
(d) Not Used by Users: The feature is not used directly by users (e.g.
passing information to a platform accessibility service).
*RESOLUTION: Close CA05, created new SC 3.2.y*
Summary of Action Items *[NEW]* *ACTION:* jeanne to add 3.3.x as stated
above [recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action07]
*[NEW]* *ACTION:* jeanne to add a normative note to 2.7.1 to say that user
agents may have a public access setting that turns this off. Maybe it
should be a global applicability note. also see Jan's proposal for SC 3.2
[recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action01]
*[NEW]* *ACTION:* Jeanne to add Jan's proposal for adding an SC for
retention of form auto-fill 3.2.X
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0024.html
[recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action02]
*[NEW]* *ACTION:* jeanne to renumber 3.2 since 3.2.5 is level A. [recorded
in http://www.w3.org/2014/07/24-ua-minutes.html#action05]
*[NEW]* *ACTION:* jeanne to renumber Principle 3 to accommodate the removal
of 3.1 [recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action04]
*[NEW]* *ACTION:* JR add more to the 3.2.X SC's intent to call out that it
could be auto-detected or user entered and could be editable. [recorded in
http://www.w3.org/2014/07/24-ua-minutes.html#action03]
*[NEW]* *ACTION:* kim to write a proposal for autosave on pages with forms
[recorded in http://www.w3.org/2014/07/24-ua-minutes.html#action06]
[End of minutes]
--
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, 24 July 2014 19:01:40 UTC