W3C

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

24 Jul 2014

See also: IRC log

Attendees

Present
Jeanne, Kim_Patch, Jan, Greg_Lowney, Jim_Allan
Regrets
Kelly
Chair
Jim
Scribe
allanj

Contents


<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]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-07-24 18:49:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: allanj
Inferring ScribeNick: allanj
Default Present: Jeanne, Kim_Patch, Jan, Greg_Lowney, Jim_Allan
Present: Jeanne Kim_Patch Jan Greg_Lowney Jim_Allan
Regrets: Kelly
Found Date: 24 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/24-ua-minutes.html
People with action items: add jeanne jr kim more

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]