Re: Question on techniques for Identify Common Purpose

Hi Jason,

> A test page that uses all of the HTML autocomplete tokens, together with
the availability of user agents or assistive technologies (including
browser extensions, as appropriate) that together support all of them.

I have created such a test page here:
http://john.foliot.ca/demos/autofill.html, although it is not 100% complete
(it only tests the named values, and not the 'grouping' or Details Token
values, but that's easy enough to address). My intent with that page was to
do as much testing as possible, and then bring back the results, and I
think that's what you are suggesting here. So +1 from me.

> Other Web pages that use a subset of the HTML autocomplete tokens (as
appropriate for the forms which they provide). They don’t need collectively
to implement all of the tokens, as this is achieved by the test page.

​I agree. I was seeking consensus from the larger group over whether this
is our collective agreement here as well. So far, it's you and me... who
else? <smile>​


> Demonstration that the user agents/AT combinations supporting the
autocomplete feature interoperate with the sample pages.

​So far, for the limited number of values that appear supported across
browsers, I can replicate the expected outcomes for 16 token values in
Firefox, Chrome, Vivaldi and Brave on the Windows platform (neither Edge
nor IE appear to support the autofill tokens based on my testing), and I
hope to have Mac testing completed this week (I do not have direct access
to a Mac machine here, but I have lots of colleagues who do).

​My greatest concern however seems to be addressed by your point #2: a
pragmatic​ acceptance that we're likely never going to find an actual form
in the wild that will use, nevermind support, all 53 token values (outside
of test pages and other instructional materials); the question then
becomes, what do we deem as acceptable versus incomplete support? And does
that even matter?

(As an aside, I've also reached out to Chaals regarding the Web Plat WG,
and asked about some of the token values that appear to be nothing more
than fantasy at this time, such as the token value of "nickname". His
initial response seems to suggest that the editors of HTML 5.4 might look
to prune that list if the browser support isn't there. This *might* also be
a potential problem going forward if we insist on a fixed list of token
values, as opposed to just saying "the current enumerated list in HTML 5
[the living spec]", but I've not thought about that more than just
mentioning it here...)

​JF​



On Tue, Feb 13, 2018 at 1:16 PM, White, Jason J <jjwhite@ets.org> wrote:

> As a further comment based on the discussion at the meeting, I can think
> of no reason why the following wouldn’t qualify as implementations
> collectively meeting the CR exit criteria:
>
>    - A test page that uses all of the HTML autocomplete tokens, together
>    with the availability of user agents or assistive technologies (including
>    browser extensions, as appropriate) that together support all of them.
>    - Other Web pages that use a subset of the HTML autocomplete tokens
>    (as appropriate for the forms which they provide). They don’t need
>    collectively to implement all of the tokens, as this is achieved by the
>    test page.
>    - Demonstration that the user agents/AT combinations supporting the
>    autocomplete feature interoperate with the sample pages.
>
>
>
> *From:* White, Jason J [mailto:jjwhite@ets.org]
> *Sent:* Tuesday, February 13, 2018 9:55 AM
> *To:* Jonathan Avila <jon.avila@levelaccess.com>; Joshue O Connor -
> InterAccess <josh@interaccess.ie>; WCAG <w3c-wai-gl@w3.org>
> *Cc:* John Foliot <john.foliot@deque.com>; lisa.seeman <
> lisa.seeman@zoho.com>
> *Subject:* RE: Question on techniques for Identify Common Purpose
>
>
>
>
>
>
>
> *From:* Jonathan Avila [mailto:jon.avila@levelaccess.com
> <jon.avila@levelaccess.com>]
> *Sent:* Tuesday, February 13, 2018 9:04 AM
>
> If the div is an input that uses contentEditable or some other type of
> input control like a birthday chooser, etc. that falls as input and has a
> mapped purpose in autocomplete values of 5.2 then it would need to define
> the purpose – but the autocomplete attribute would not be appropriate.  I’d
> imagine you would need to define the purpose programmatically via
> techniques related to schema.org – otherwise if it is not be input then
> it would not fall under this SC at level aA.
>
> *[Jason] However, techniques related to the use of metadata to specify
> purpose using vocabulary mapped to HTML5 autocomplete tokens are not
> accessibility-supported yet. The user won’t benefit, whereas they arguably
> will in some cases if the HTML autocomplete attribute is used on a standard
> form field. This may be enough to satisfy Candidate Recommendation exit
> criteria in connection with accessibility support, but it can hardly be
> regarded as a satisfactory situation either, as the benefit to the user (in
> so far as there is one) only accrues if HTML autocomplete is chosen as the
> implementation mechanism.*
>
>
> ------------------------------
>
> 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.
> ------------------------------
>



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

Advancing the mission of digital accessibility and inclusion