- From: Marc Johlic <marc.johlic@gmail.com>
- Date: Fri, 12 Jan 2018 12:58:33 -0500
- To: "White, Jason J" <jjwhite@ets.org>
- Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CABpp2mJOObMPJydP3K1q_s4DEL9QYyJSZS7GAzB671MR-+R0pw@mail.gmail.com>
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 <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 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cjjwhite%40ets.org%7C99e76206120a43d0157708d559e214d4%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513749899118798&sdata=YIsK5eWlo1OU%2BXq%2BdOXr245xRPZEfIvd5o6LCBeCjL0%3D&reserved=0> 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 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7Cakirkpat%40adobe.com%7Ce6416acb90d34228707808d559e5143a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513762788513280&sdata=K2Pxk9EKsIqq42wTAblO1HC6NdU%2BKZZKiLCqWaUHMno%3D&reserved=0> > > > > *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%7Cfa7b1b5a7b34438794aed2c178de > cee1%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%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636513679887347881&sdata=LG6X%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 > > > > > ------------------------------ > > 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 17:58:56 UTC