- From: John Foliot <john.foliot@deque.com>
- Date: Thu, 30 Nov 2017 09:18:11 -0600
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxzfzdeMqDcRNZwmg73M1TWcQjzXyK_RQD+4rn6_mKwMOw@mail.gmail.com>
Andrew, Well, yes, that's the idea. Struggling with the editorial prose to convey that however, so open to group input. We just need to be sure that we don't end up with a mindless application of the metadata to all form inputs that seek data such as Name, Address, email, etc. (Ref: ARIA Gone Wild scenarios). I suspect that between Understanding, and a few well written (and explained) Techniques, content authors will grok what we want going forward. JF On Thu, Nov 30, 2017 at 8:53 AM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote: > 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. > > > 1. 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: http://rawgit.com/w3c/wcag21/ > purpose_of_controls_changes2/guidelines/index.html#identify-purpose > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Fpurpose_of_controls_changes2%2Fguidelines%2Findex.html%23identify-purpose&data=02%7C01%7Cakirkpat%40adobe.com%7C0a969142de2643a9e24d08d537fffaa1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636476494921262784&sdata=r%2BuFRI8Z03ZRPLXeNH2zz2R75fPTwYIJQiNBI7oZKFI%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=http%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Fpurpose_of_controls_changes3%2Fguidelines%2Findex.html%23identify-purpose&data=02%7C01%7Cakirkpat%40adobe.com%7C0a969142de2643a9e24d08d537fffaa1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636476494921262784&sdata=SiNU6DB0%2BGOzMKzI%2Fl5ZnaNox%2BDWwsADKavjLz5Hs%2Bg%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=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7Cakirkpat%40adobe.com%7C0a969142de2643a9e24d08d537fffaa1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636476494921262784&sdata=zr%2B%2Bmv%2BP4aaZiT%2FHCieH7UmVruRj0VhveJg%2F%2BovCrys%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
Received on Thursday, 30 November 2017 15:18:38 UTC