- From: John Foliot <john.foliot@deque.com>
- Date: Fri, 12 Jan 2018 11:57:35 -0600
- To: David MacDonald <david100@sympatico.ca>
- Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, Marc Johlic <marc.johlic@gmail.com>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxxCqXiyAbyA2UBLwkujwV65CMmQyM7uLp_X7eJu2sap7Q@mail.gmail.com>
> Also, it seems like that HTML 5.2 list has some "meanings" that were not
in our list... do we want to widen the requirements for those additional
ones listed in the spec, but not on our culled down list.
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?
(Note to Alex Li: I double-checked yesterday, and both the WHAT WG version
and W3C version of these values are identical in every detail, so I would
propose pointing to the W3C version.)
JF
On Fri, Jan 12, 2018 at 11:39 AM, David MacDonald <david100@sympatico.ca>
wrote:
> I might have missed the discussion of changing "purpose" to "meaning". Can
> anyone bring me up to speed on the reason for that?
>
> Whichever is used... it might need a definition if its specific beyond a
> dictionary.
>
> Also, it seems like that HTML 5.2 list has some "meanings" that were not
> in our list... do we want to widen the requirements for those additional
> ones listed in the spec, but not on our culled down list.
>
> 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 12:28 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
>> Thanks Marc.
>>
>>
>>
>> Here’s a version with further edits:
>>
>> In content implemented using technologies with support for identifying
>> the expected meaning for form input data, the meaning can be
>> programmatically determined for each user interface component that accepts
>> user input corresponding to the user; inputs matching a meaning provided in
>> the HTML 5.2 Autofill field names
>> <https://www.w3.org/TR/html52/sec-forms.html#autofill-field> must expose
>> that meaning except if the technology being used does not support a
>> corresponding autofill meaning.
>>
>>
>>
>> What do people think?
>>
>>
>>
>> Thanks,
>>
>> AWK
>>
>>
>>
>> Andrew Kirkpatrick
>>
>> Group Product Manager, Accessibility
>>
>> Adobe
>>
>>
>>
>> akirkpat@adobe.com
>>
>> http://twitter.com/awkawk
>>
>>
>>
>> *From: *Marc Johlic <marc.johlic@gmail.com>
>> *Date: *Friday, January 12, 2018 at 12:03
>> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
>> *Subject: *Re: Possible wording for 1.3.4?
>>
>>
>>
>> I like the idea / premise and would +1 this replacing the wording in
>> 1.3.4 - and even keeping it at AA with this idea / premise / wording.
>>
>>
>>
>> I know we're out of time, but I would like to simplify the wording of the
>> SC if possible. Sorry - no ideas right off the top of my head.. I'll try
>> to come up with suggestions. It really just boils down to being as simple
>> as Leonie asked.. if your tech supports autofill, use it - but I know the
>> SC language needs to cover all of the bases. (It just took me a few read
>> throughs to "get it").
>>
>>
>>
>> Even if the wording stays as is, I would +1 this replacing current 1.3.4
>> wording - and leaving in as AA.
>>
>>
>>
>> -Marc Johlic
>>
>>
>>
>> On Fri, Jan 12, 2018 at 10:43 AM, Andrew Kirkpatrick <akirkpat@adobe.com>
>> wrote:
>>
>> This SC seems to be saying that when using HTML input fields to collect
>> user information, the input element needs to have the autocomplete
>> attribute set with a value corresponding to the expected information
>> (based on the tokens defined in HTML5.2). Is this right?
>>
>> That is right. Of course there isn’t a value needed for every input, just
>> the ones with the meaning that matches the list.
>>
>> The SC also applies to other technologies that support autofill. If a
>> technology other than HTML supports autofill and has some of the values
>> that HTML 5.2 supports, those values need to be supported when using that
>> technology also.
>>
>> AWK
>>
>>
>>
>> On 12/01/2018 14:47, Andrew Kirkpatrick wrote:
>> > OK, so here’s a new attempt at language for 1.3.4.
>> >
>> > This language is below. Several concerns are addressed:
>> >
>> > * Uses a small and already-established list of values, based on
>> the
>> > values in HTML5.2, but only imposes those values on other
>> > technologies if those technologies share the same values.
>> > * Well-established browser support for input autofill, and
>> provides a
>> > pathway for cognitive AT innovation.
>> > * Addresses a need established by the COGA group related to
>> difficulty
>> > filling out forms as well as providing the personalization
>> > enhancements development pathway.
>> > * WCAG doesn’t need to provide a specific list of inputs by
>> > referencing the HTML list, but that list is versioned with HTML
>> so
>> > the level of testability doesn’t change until we update the
>> > reference in WCAG 2.2 (or silver) to either an updated HTML or
>> > COGA/ARIA spec.
>> > * Specifically targeted to the user, so this isn’t for EVERY input
>> > control, just a handful in the HTML spec (~40) that relate to
>> common
>> > user information (name, address, phone, credit card).
>> >
>> > Title: Support Common Input Fields
>> >
>> > SC Text:
>> >
>> > In content implemented using technologies with support for
>> autofilling
>> > form inputs, the meaning of each user interface component that
>> accepts
>> > user input corresponding to the user can be programmatically
>> determined;
>> > inputs matching a meaning provided in 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%7C6fb521158e4c402
>> 2002908d559d1ba79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%
>> 7C0%7C636513679887347881&sdata=ToUIE6G%2FsKjrtn5JMEwM9h
>> Tps6iMOc6BtZwokR8IAzI%3D&reserved=0> must expose
>> > that meaning except if the technology being used does not support a
>> > corresponding autofill meaning.
>> >
>> > Note:
>> >
>> > The set of meanings for inputs is based on HTML 5.2. It is not
>> expected
>> > that every technology supports the same set, so content implemented
>> > using a technology that supports a subset of the HTML 5.2 autofill
>> > meanings is not required to provide support for meanings that are
>> not
>> > supported by that technology.
>> >
>> > Note:
>> >
>> > Some technologies are expected to provide a list of meanings that
>> is a
>> > superset of the HTML 5.2 set; authors are encouraged to implement
>> > support for additional meanings in their content in order to
>> provide a
>> > better experience for users.
>> >
>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Frawgit.com%2Fw3c%2Fwcag21%2F1.3.4_autofill%2Fguidelines
>> %2Findex.html%23identify-common-purpose&data=02%7C01%
>> 7Cakirkpat%40adobe.com%7C6fb521158e4c4022002908d559d1ba79%7C
>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63651367988734788
>> 1&sdata=VHpV4ttfM7I2%2FFKZW6SCulpl8NgMOw%2BtZ2%2BRHugkCtE%3D&reserved=0
>> >
>> > If you like it, or don’t like it, please speak up ASAP!
>> >
>> > Thanks,
>> >
>> > AWK
>> >
>> > Andrew Kirkpatrick
>> >
>> > Group Product Manager, Accessibility
>> >
>> > Adobe
>> >
>> > akirkpat@adobe.com
>> >
>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7Cakirkpat%
>> 40adobe.com%7C6fb521158e4c4022002908d559d1ba79%7Cfa7b1b5a7b3
>> 4438794aed2c178decee1%7C0%7C0%7C636513679887347881&sdata=LG6
>> X%2BPhGvkisWjEcmBqgBy%2FteFAEl9tq2izWdcwmbio%3D&reserved=0
>>
>> >
>>
>> --
>> @LeonieWatson @tink@toot.cafe tink.uk
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftink.uk&data=02%7C01%7Cakirkpat%40adobe.com%7C77857df5a72447614ae208d559de604e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636513733998117846&sdata=YtaWXq9SN2FjUMQYnIAGmvalPT6%2FHQxYEoBJO37shP0%3D&reserved=0>
>> carpe diem
>>
>>
>>
>
>
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
Received on Friday, 12 January 2018 17:57:59 UTC