Re: Possible wording for 1.3.4?

Yes I think it would... :)

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.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 5:32 PM, John Foliot <john.foliot@deque.com> wrote:

> ​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
>