Re: Purpose of Controls

It was removed as a result of the WG discussion before thanksgiving and wasn’t in the survey as a result.

Your description for is “change the mode or functionality” – which I and others on the group didn’t understand. I do not recommend that you hold up approval over this one.


Andrew Kirkpatrick
Group Product Manager, Accessibility

From: "" <>
Date: Thursday, November 30, 2017 at 10:22
To: Andrew Kirkpatrick <>
Cc: John Foliot <>, WCAG <>
Subject: Re: Purpose of Controls

I did not remember mode getting removed. It is an important one
All the best

Lisa Seeman

LinkedIn<>, Twitter<>

---- On Thu, 30 Nov 2017 16:53:11 +0200 Andrew Kirkpatrick<> wrote ----
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.


Andrew Kirkpatrick
Group Product Manager, Accessibility

From: John Foliot <<>>
Date: Thursday, November 30, 2017 at 09:38
To: Andrew Kirkpatrick <<>>
Cc: WCAG <<>>
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.


On Thu, Nov 30, 2017 at 8:31 AM, Andrew Kirkpatrick <<>> wrote:
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.

     *   The SC is retitled “Identify Purpose” as the previous “purpose of controls” mixes the User interface Component and “control” language and this seems clearer.

  1.  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:

  *   Without “AT RISK” items from yesterday:


Andrew Kirkpatrick
Group Product Manager, Accessibility

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.<>

Advancing the mission of digital accessibility and inclusion

Received on Thursday, 30 November 2017 15:41:11 UTC