- From: Michael Gower <michael.gower@ca.ibm.com>
- Date: Fri, 12 Jan 2018 18:12:20 +0000
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: "White, Jason J" <jjwhite@ets.org>, Marc Johlic <marc.johlic@gmail.com>, WCAG <w3c-wai-gl@w3.org>
- Message-Id: <OF207EAB30.7AE5AA19-ON88258213.006346E2-88258213.0063F7E7@notes.na.collabserv.c>
If something gets deprecated in 5.2, my page based on 5.1 is going to
continue to use that deprecated element until such time as I update the
page. How is this different?
4.1.2 does not define a spec for name, role or value.
Michael Gower
IBM Accessibility
Research
1803 Douglas Street, Victoria, BC V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 * fax: (250) 220-8034
From: Andrew Kirkpatrick <akirkpat@adobe.com>
To: Marc Johlic <marc.johlic@gmail.com>, "White, Jason J"
<jjwhite@ets.org>
Cc: WCAG <w3c-wai-gl@w3.org>
Date: 2018-01-12 10:05 AM
Subject: Re: Possible wording for 1.3.4?
If not referenced in the SC, then the conformance can change.
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.
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:58
To: "White, Jason J" <jjwhite@ets.org>
Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
Subject: Re: Possible wording for 1.3.4?
I agree with Jason. I like having HTML 5.2 (or any standard) for a stake
in the ground, but I think we can get around having that in the actual SC
language as Jason describes.. We can reference it in the Understanding.
-Marc
On Fri, Jan 12, 2018 at 12:55 PM, White, Jason J <jjwhite@ets.org> wrote:
No, I think it’s testable in that it only applies to the field types
supported by the technology being used.
From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Friday, January 12, 2018 12:53 PM
To: White, Jason J <jjwhite@ets.org>; Marc Johlic <marc.johlic@gmail.com>;
WCAG <w3c-wai-gl@w3.org>
Subject: Re: Possible wording for 1.3.4?
Jason,
My concern is that without attaching a reference to a defined list this
becomes untestable.
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe
akirkpat@adobe.com
http://twitter.com/awkawk
From: "White, Jason J" <jjwhite@ets.org>
Date: Friday, January 12, 2018 at 12:51
To: Andrew Kirkpatrick <akirkpat@adobe.com>, Marc Johlic <
marc.johlic@gmail.com>, WCAG <w3c-wai-gl@w3.org>
Subject: RE: Possible wording for 1.3.4?
For content implemented using technologies that support specifying the
purpose of specific types of form input fields, the purpose of each such
field of a supported type can be programmatically determined.
From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Friday, January 12, 2018 12:29 PM
To: Marc Johlic <marc.johlic@gmail.com>; WCAG <w3c-wai-gl@w3.org>
Subject: Re: Possible wording for 1.3.4?
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 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%7C6fb521158e4c4022002908d559d1ba79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513679887347881&sdata=ToUIE6G%2FsKjrtn5JMEwM9hTps6iMOc6BtZwokR8IAzI%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513679887347881&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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513679887347881&sdata=LG6X%2BPhGvkisWjEcmBqgBy%2FteFAEl9tq2izWdcwmbio%3D&reserved=0
>
--
@LeonieWatson @tink@toot.cafe tink.uk carpe diem
This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and
delete it from your system. Any other use of this e-mail is prohibited.
Thank you for your compliance.
This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and
delete it from your system. Any other use of this e-mail is prohibited.
Thank you for your compliance.
Received on Friday, 12 January 2018 18:12:56 UTC