Re: Possible wording for 1.3.4?

​To your sidebar question (which i thought I addressed earlier):

In discussion yesterday, I had suggested adding this (somewhere - in the SC
or Understanding Document) that noted the following:

>From the HTML 5 Recommendation:
    "Some fields correspond to subparts of other fields; for example, a
credit card expiry date can be expressed as one field giving both the month
and year of expiry ("cc-exp"), or as two fields, one giving the month
("cc-exp-month") and one the year ("cc-exp-year"). In such cases, the names
of the broader fields cover multiple rows, in which the narrower fields are
defined.

     Generally, authors are encouraged to use the broader fields rather
than the narrower fields, as the narrower fields tend to expose Western
biases. For example, while it is common in some Western cultures to have a
given name and a family name, in that order (and thus often referred to as
a first name and a surname), many cultures put the family name first and
the given name second, and many others simply have one name (a mononym).
Having a single field is therefore more flexible."

NOTE: Should authors decide to use more specific input field (e.g. using
first name and family name inputs), authors are required to use the
equivalent and corresponding values found in the HTML 5 specification:
https://www.w3.org/TR/html52/sec-forms.html#sec-autofill


David, would that address your question?​

JF


On Fri, Jan 12, 2018 at 4:05 PM, David MacDonald <david100@sympatico.ca>
wrote:

> To riff off of Alex and Andrew, how about something like this?
>
> In content implemented using technologies with support for identifying
> the <a>meaning</a> for form input data, for each input field about the
> user that has a purpose that maps to any of the HTML 5.2 Autofill field
> names
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=XRbdqxqP8ZK6sblYsmHoYOwbcLFZuiEs6zZ07udO%2Br4%3D&reserved=0>
> , the meaning of the input field can be programmatically determined.
>
> ​Note: The "meaning" is ​a description of a field name found in the table HTML
> 5.2 table of Autofill field names
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=XRbdqxqP8ZK6sblYsmHoYOwbcLFZuiEs6zZ07udO%2Br4%3D&reserved=0>
>
> I would also be ok substituting, as was done in an earlier draft,
> "autofill" instead of "identifying the expected meaning for form input
> data" which is pretty hard to understand.
>
> As a sidebar. The HTML list is more granular with several "meanings" for
> each of our "purposes" in a number of categories. That means that these
> additional autofill attributes will be required when that the corresponding
> form field is present on a page. I'm OK with that but thought we should
> have them documented on the list.
>
> "honorific-prefix"
> "given-name"
> "additional-name"
> "family-name"
> "honorific-suffix"
> "nickname"
> "username"
> "new-password"
> "current-password"
> "address-line1"
> "address-line2"
> "address-line3"
> "address-level4"
> "address-level3"
> "address-level2"
> "address-level1"
> "cc-given-name"
> "cc-additional-name"
> "cc-family-name"
> "impp"
> "tel-country-code"
> "tel-national"
> "tel-area-code"
> "tel-local"
> "tel-local-prefix"
> "tel-local-suffix"
>
>
>
>
>
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Fri, Jan 12, 2018 at 2:11 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
>> I like that version Alex. A few tweaks in line with John’s:
>>
>>
>>
>> In content implemented using technologies with support for autofilling
>> form inputs and an equivalent input field as any of the HTML 5.2
>> Autofill field names
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=XRbdqxqP8ZK6sblYsmHoYOwbcLFZuiEs6zZ07udO%2Br4%3D&reserved=0>
>> is used, the meaning of the equivalent input fields can be programmatically
>> determined.
>>
>>
>>
>> Changed:
>>
>> In content implemented using technologies with support for autofilling
>> form inputs, for each input field that has a purpose that maps to any of
>> the HTML 5.2 Autofill field names
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=XRbdqxqP8ZK6sblYsmHoYOwbcLFZuiEs6zZ07udO%2Br4%3D&reserved=0>
>> the meaning of the input field can be programmatically determined.
>>
>>
>>
>> Or, to step away from “autofill” a bit:
>>
>> In content implemented using technologies with support for identifying
>> the expected meaning for form input data, for each input field that has
>> a purpose that maps to any of the HTML 5.2 Autofill field names
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=XRbdqxqP8ZK6sblYsmHoYOwbcLFZuiEs6zZ07udO%2Br4%3D&reserved=0>
>> the meaning of the input field can be programmatically determined.
>>
>>
>>
>>
>>
>>
>>
>> Thanks,
>>
>> AWK
>>
>>
>>
>> Andrew Kirkpatrick
>>
>> Group Product Manager, Accessibility
>>
>> Adobe
>>
>>
>>
>> akirkpat@adobe.com
>>
>> http://twitter.com/awkawk
>>
>>
>>
>> *From: *Alex Li <alli@microsoft.com>
>> *Date: *Friday, January 12, 2018 at 13:54
>> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>, Alastair Campbell <
>> acampbell@nomensa.com>
>> *Cc: *WCAG <w3c-wai-gl@w3.org>
>> *Subject: *RE: Possible wording for 1.3.4?
>>
>>
>>
>> How about something like this?
>>
>>
>>
>> In content implemented using technologies with support for autofilling
>> form inputs and an equivalent input field as any of the HTML 5.2
>> Autofill field names
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=XRbdqxqP8ZK6sblYsmHoYOwbcLFZuiEs6zZ07udO%2Br4%3D&reserved=0>
>> is used, the meaning of the equivalent input fields can be programmatically
>> determined.
>>
>>
>>
>> *From:* Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
>> *Sent:* Friday, January 12, 2018 10:26 AM
>> *To:* Alastair Campbell <acampbell@nomensa.com>
>> *Cc:* WCAG <w3c-wai-gl@w3.org>
>> *Subject:* Re: Possible wording for 1.3.4?
>>
>>
>>
>> If a company creates a tool that allows people to create web content they
>> may be able to conform when the software is tested but that is a different
>> date then for the person who builds content with it.
>>
>>
>>
>> The suggestions are very much like 1.3.5:
>>
>> In content implemented using markup languages, the purpose of User
>> Interface Components
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Fmaster%2Fguidelines%2Findex.html%23dfn-user-interface-components&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=aShpbJxNlVln6eAEUJg6nk8lPkPB%2BjdXstjbGKIILp4%3D&reserved=0>,
>> icons, and regions
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Fmaster%2Fguidelines%2Findex.html%23dfn-regions&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=k1pms5bzqxOapQWfkpzlGPeYKyudC%2BaHJjvKCQaBxRI%3D&reserved=0> can
>> be programmatically determined.
>>
>> (http://rawgit.com/w3c/wcag21/master/guidelines/index.html#i
>> dentify-purpose
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Fmaster%2Fguidelines%2Findex.html%23identify-purpose&data=02%7C01%7Cakirkpat%40adobe.com%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=m3MxLxENUGRWUi7Zr%2Fvv2uJp9Lqg4Wk8gDkTvNR7T%2Bs%3D&reserved=0>
>> )
>>
>>
>>
>> in 1.3.4 we have tried to define a smaller, more testable set.
>>
>>
>>
>> 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%7Cca969dfd8a4a4e21f6e408d559ede8cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513800714094670&sdata=sYITmzrmcIzPXaBCJCP%2BsEUsnKXwY86bLKc48kfaISA%3D&reserved=0>
>>
>>
>>
>> *From: *Alastair Campbell <acampbell@nomensa.com>
>> *Date: *Friday, January 12, 2018 at 13:16
>> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>
>> *Cc: *WCAG <w3c-wai-gl@w3.org>
>> *Subject: *Re: Possible wording for 1.3.4?
>>
>>
>>
>> AWK:
>>
>> > If I use HTML in a “living standard” way today and include all of the
>> appropriate meanings/purposes that are defined, but then HTML adds
>> meanings, how will I be able to handle my conformance? I haven’t changed
>> the site, but the list changes. We can’t leave that open-ended.
>>
>>
>>
>> As per Michael’s email on the other thread: Conformance is at a
>> particular date, so it’s the standard at the time.
>>
>>
>>
>> This was one of the reasons that the W3C has tried to ‘version’ HTML
>> though, so your conformance could also reference a specific version, e.g:
>>
>> https://www.w3.org/TR/html52/sec-forms.html#autofill-field
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7C1a91d1adbbec4a5f136108d559e88c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513777735429494&sdata=KaptVuMMuXLmJ4IPdDuZTIRdkM9A6P0PPEjys0vUmiA%3D&reserved=0>
>>
>>
>>
>> -Alastair
>>
>
>


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

Advancing the mission of digital accessibility and inclusion