Re: Purpose of Controls

Hi Brooks,

>
​
I think we really want to present a highly refined, curated list of control
categories (chunking terms) in the Purpose of Controls SC normative
language, instead of the list of specific control names we currently have.


​While I agree that the chunking exercise is/was useful for better
understanding the context of the enumerated control types, I would object
strenuously if we ditched the actual list of applicable controls outright,
as that list is and will be critical for measuring success.

Content authors, especially early on, will want to know - specifically -
which controls are covered, and a hand-wavy "all that apply" will make
testing a nightmare.  Additionally, we need to ensure (as part of the Exit
Criteria process)​, that we have metadata terms for all of the controls on
our list in at least one ontology (I've been focusing on schema.org, but
the Personalization semantics would be another, and the SC is left open for
additional metadata schemas).

The broader, list-free requirement is actual *SC 1.3.5 Contextual
Information*:


*In content implemented using markup languages, contextual information for
controls, symbols, and regions can be programmatically determined using a
publicly available vocabulary.*


JF*​*

On Thu, Nov 30, 2017 at 10:07 AM, <Brooks.Newton@thomsonreuters.com> wrote:

> Mike,
>
>
>
> I agree with your observations regarding problems with the control types
> list.  Thus, the reason why I brought up my objection to using a filtered
> version of the survey results on yesterday’s call as a basis for moving
> forward with normative text.  I think we really want to present a highly
> refined, curated list of control categories (chunking terms) in the Purpose
> of Controls SC normative language, instead of the list of specific control
> names we currently have. These categories need to be added to the normative
> list by a process that assesses their beneficial impact to users who this
> SC is intended to serve.   I’m not sure there is time to do that work,
> given the deadlines we face.
>
>
>
> Brooks
>
>
>
> *From:* Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
> *Sent:* Thursday, November 30, 2017 9:48 AM
> *To:* Michael Gower
> *Cc:* John Foliot; WCAG
>
> *Subject:* Re: Purpose of Controls
>
>
>
> Mike,
>
> Part of the benefit is the ability for a tool to recognize the button
> purpose and add an icon or replace the text with an image. Of course, if
> that tool also looked at the button labels and responded to labels like
> “print” and “home” then the same result could be reached.
>
>
>
> I do think that “reply”, “forward”, and “print” are very commonly if not
> universally used in English-language sites, but am not sure if this is such
> a major issue. We could and may wind up removing some of these due to
> implementation results or comments on the draft.
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
>
>
> *From: *Michael Gower <michael.gower@ca.ibm.com>
> *Date: *Thursday, November 30, 2017 at 10:39
> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>
> *Cc: *John Foliot <john.foliot@deque.com>, WCAG <w3c-wai-gl@w3.org>
> *Subject: *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
> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g>
>  V8T 5C3
> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g>
> 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
> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g>
>  V8T 5C3
> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C8c6b9477aca04c4dc6f608d538087eef-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636476531503026083-26sdata-3Dns8oTz-252BWb80JoJisMFtyeA5re387UECbtWYWEHNNP1k-253D-26reserved-3D0&d=DwMGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=khFpI9UpZzRfnwg4gQOdJ0T9CcPLeX_BkMLezQ0B49E&s=yWqZH5CxNk7tiPrEtlT9AJX6UaPmhVwnsGA5wU1-NrE&e=>
>
>
>
> *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
>    <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Frawgit.com-252Fw3c-252Fwcag21-252Fpurpose-5Fof-5Fcontrols-5Fchanges2-252Fguidelines-252Findex.html-2523identify-2Dpurpose-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C0a969142de2643a9e24d08d537fffaa1-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636476494921262784-26sdata-3Dr-252BuFRI8Z03ZRPLXeNH2zz2R75fPTwYIJQiNBI7oZKFI-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DglgV84Vn-MJZDintvHCtsHI1k-gy3b9V__dHBXk_nMM%26s%3DQggGMWISuFJhonWex2td1T17wbvERSY3jro1WvmLEaU%26e%3D&data=02%7C01%7Cakirkpat%40adobe.com%7C8c6b9477aca04c4dc6f608d538087eef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636476531503026083&sdata=gSQCwkCOxjEMkna8tBsP%2FNw%2FHqIq15PC0pLtWoumiFo%3D&reserved=0>
>    - Without “AT RISK” items from yesterday: http://rawgit.com/w3c/wcag21/
>    purpose_of_controls_changes3/guidelines/index.html#identify-purpose
>    <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Frawgit.com-252Fw3c-252Fwcag21-252Fpurpose-5Fof-5Fcontrols-5Fchanges3-252Fguidelines-252Findex.html-2523identify-2Dpurpose-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C0a969142de2643a9e24d08d537fffaa1-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636476494921262784-26sdata-3DSiNU6DB0-252BGOzMKzI-252Fl5ZnaNox-252BDWwsADKavjLz5Hs-252Bg-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DglgV84Vn-MJZDintvHCtsHI1k-gy3b9V__dHBXk_nMM%26s%3DU_y90s9cxfHeW5i9dUlbzjQ3QaytMf4sLIPAirbMoNg%26e%3D&data=02%7C01%7Cakirkpat%40adobe.com%7C8c6b9477aca04c4dc6f608d538087eef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636476531503026083&sdata=QM2Oc%2B0c8wviE%2Flb0ZK5TwAJ%2BvvjBzHyU1U7jzRw2NI%3D&reserved=0>
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C0a969142de2643a9e24d08d537fffaa1-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636476494921262784-26sdata-3Dzr-252B-252Bmv-252BP4aaZiT-252FHCieH7UmVruRj0VhveJg-252F-252BovCrys-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DglgV84Vn-MJZDintvHCtsHI1k-gy3b9V__dHBXk_nMM%26s%3DE9v6EcDL5IP_pvT1rv7jw3ctqBYqPe2eRn-dvk7SAH4%26e%3D&data=02%7C01%7Cakirkpat%40adobe.com%7C8c6b9477aca04c4dc6f608d538087eef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636476531503026083&sdata=UMhZb7sZACd8nfl0K3%2FIAEK9AbMq76Er4BFR05rZq0k%3D&reserved=0>
>
>
>
>
>
> --
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com
>
>
>
> Advancing the mission of digital accessibility and inclusion
>
>
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion