Re: Purpose of Controls

At the opposite end of the spectrum of considerations on this list, is 
that there are terms here which are so obviously the de facto term for a 
control function that I'm really having problems seeing what the value is 
having all authors forced to code the purpose.

Can anyone think of a situationn where the button that forwards an email 
to someone else would be labelled as anything other than "forward"? It's a 
very specific term to a specific type of application. It just seems out of 
place to me compared to other more broadly used functions on this list 
which could have synonyms used in labels.

Even some more globally used functions like "print" have a similar 'hard' 
function name. Tough to think of use cases where the word "print" would 
not be the label. I'm assuming there's a concern that a string like "Print 
document" is a synonym so that may not be understood, so the purpose needs 
to be clarified?

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   Michael Gower/CanWest/IBM
To:     Andrew Kirkpatrick <akirkpat@adobe.com>
Cc:     John Foliot <john.foliot@deque.com>, WCAG <w3c-wai-gl@w3.org>
Date:   2017-11-30 07:20 AM
Subject:        Re: Purpose of Controls


Here's the scenario I'm worried about:
I'm filling out a complex form that gathers information on myself and my 
whole family. The form is divided into sections on me and on my spouse and 
on my offspring. So there are name fields all over the place, and those 
name fields my even be labelled the same (i.e., the section heading says 
"spouse" but the labels are the same on the inputs as on the ones for 
user). That would be crappy design, in my opinion, but I can see it 
happening.

In such a scenario -- or even in ones less dire -- I think we have to 
ensure that our purpose designations don't actually make that experience 
more confusing.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034




From:   Andrew Kirkpatrick <akirkpat@adobe.com>
To:     John Foliot <john.foliot@deque.com>
Cc:     WCAG <w3c-wai-gl@w3.org>
Date:   2017-11-30 06:56 AM
Subject:        Re: Purpose of Controls



John,
Could the final note be used as a note on the SC and not indicate that the 
user is directly part of each of the items?
 
So, for example, the name information that I encounter when filling out a 
form for a child or an employee would be marked up with name metadata and 
I could benefit from the metadata, but if I am using a form that requires 
that I enter information that includes my name and that of a family member 
only one should be used.
 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk

 
From: John Foliot <john.foliot@deque.com>
Date: Thursday, November 30, 2017 at 09:38
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Purpose of Controls
 
Hi Andrew,
 
To expand upon the concern about *User* information, I've taken a quick 
pass and come up with this (I have cherry-picked the inputs of concern, 
the following is not the full list under consideration):
 
* Name - Inputs used to handle information about a user’s name(s) (e.g. 
first name, family name, suffix, etc.)
 
* Professional Title - The user's Job title (e.g., "Software Engineer", 
"Senior Vice President", "Deputy Managing Director")
 
* Organization - Company name corresponding to the user's organization
 
* Address - Inputs used to handle information about the user's address 
information, organization, or location (e.g. street address, city, region, 
postal code, etc.)
 
* Country Code - The user's country abbreviation code
 
* Country Name - Full name of the user's country
 
* Credit Card - Inputs used to handle information about the user's credit 
card payments
 
* Name on Credit Card - Full name of the user as given on the payment 
instrument
 
* Language - The user's preferred language
 
* Birthdate - The user's birthday information
 
* Sex - The user's Gender identity
 
* Photo - Photograph, icon, or other image corresponding to the user
 
* Telephone Number - Inputs used to handle information about the user's 
telephone number(s)
 
* Email Address - The user's Email address
 
NOTE: For further clarity, input fields that collect identifying data 
should only be related to data associated to the end user. 
For example, on a form that collects multiple Names, Addresses, and Phone 
Numbers, content authors are only required to ensure that fields related 
to the actual user are addressed by this requirement.
 
Thoughts?
 
On Thu, Nov 30, 2017 at 8:31 AM, Andrew Kirkpatrick <akirkpat@adobe.com> 
wrote:
AGWGer’s,
Yesterday we spent a lot of time on Purpose of Controls and we need to 
minimize the time spent on this SC because while it is important it isn’t 
the only important SC.
 
After the meeting a lot of work went into this SC, and we have an 
implemented version (two, actually) for people to review and think about.
 
Things that have changed:
1.      All listed items have definitions.
2.      The lists are moved from an appendix to a section of the document, 
and are to be regarded as normative.
3.      The term “user interface components” is used more consistently 
throughout the SC and additional section. 
a.      The SC is retitled “Identify Purpose” as the previous “purpose of 
controls” mixes the User interface Component and “control” language and 
this seems clearer.
4.      Within the lists, a few item groupings are collapsed into a single 
top-level item. Name, Address, and Telephone are examples of this. So if 
you build a form you need to make sure that the appropriate address field 
purposes are conveyed, and this helps with internationalization as well as 
to accommodate for different design decisions (e.g. one form uses “Full 
Street Address” and another has “address 1, “address 2”, etc – both need 
the purpose to be properly conveyed).
 
One item to think about:
A comment was raised at TPAC and since then as well that for the input 
control purposes we need to focus on the user’s information. So, instead 
of name inputs controls being about anyone, they are about the user 
directly. The concern is that if autofill attributes are used to satisfy 
this that a form with name fields for many people (e.g. HR system, booking 
a flight for a family) that there will be a lot of inaccurate information 
potentially automatically added to the form.
 
If we agree that this is a problem, then we will need to adjust a handful 
of other input purposes (e.g. address, email, etc.).
 
So, here’s the latest draft:
With “AT RISK” items from yesterday: 
http://rawgit.com/w3c/wcag21/purpose_of_controls_changes2/guidelines/index.html#identify-purpose

Without “AT RISK” items from yesterday: 
http://rawgit.com/w3c/wcag21/purpose_of_controls_changes3/guidelines/index.html#identify-purpose

 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk



 
-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
 
Advancing the mission of digital accessibility and inclusion