Re: Unsupported Autofill values and Common Purpose

Hi David,

The answer is #3.  I think we need to step back from the fatalistic
scenarios.

I have now successfully shown support for roughly 50% of the values
<https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research> in
the browsers via native support (the original 18 number was when I did not
have an SSL certificate, which I do now:
https://john.foliot.ca/demos/autofill.html), and I've found (Friday) at
least one stand-alone application that supports *ALL* of the values today,
with I hope a second one in the wings.

Given that we only need two independent instances of support, and I can
point to one already (that is both platform and browser agnostic on the
desktop - LastPass <https://www.lastpass.com/> - although for Android you
need to use the bundled browser with the LastPass app, which I still need
to test for a11y, and I haven't done any testing on the Apple platforms).

I have also spoken with Chaals McCathie Nevile, one of the co-chairs
of WebPlatforms
WG <https://www.w3.org/2015/10/webplatform-charter.html>, discussing the
discrepancy between the spec and actual support in the browsers. While that
WG *might* revisit the list and prune it, there is also a complex
discussion around the W3C version of HTML 5 versus the WHAT WG version, and
so I am less sure that the values that lack support in the browser today -
BUT DO HAVE SUPPORT IN OTHER HELPER APPS - will disappear.

The point being, we now seem to have some robust support, even if not full
native support in the browsers. I am continuing to document and test this
week, but as it stands today, I don't think we have anything to worry about
(even though I first raised this concern a week+ ago).

JF



On Mon, Feb 19, 2018 at 9:42 AM, David MacDonald <david@can-adapt.com>
wrote:

> Hi All
>
> I think we are in a very difficult position. It appears many of the HTML
> 5.2 autofill tokens are not supported by browsers (and there are currently
> no plugins that work) Furthermore, some of them might disappear from the
> next version of HTML. One reason we decided to reference this list of over
> 50 tokens instead of the shorter list that we had internally was because we
> believed they wouldn't have gotten into the HTML 5 spec without support.
> Apparently, this was a mistaken assumption because only about 18 out of
> over 50 are supported.
>
> So now we are in a position where we may be requiring authors for the next
> several years to implement tokens that have no support that might disappear
> in the next version of HTML. There is currently a new COGA sec being
> developed by Lisa and Richard that uses these values (referenced in last
> week's minutes). We've also been told by the COGA team that the existing
> success criterion has lost 95% of its existing intention.
>
> As I see it we have several choices before us:
>
> 1. Remove the success criterion for 2.1 and wait until the next version of
> WCAG where technology is more stable things settle down. Maybe at that
> point the new specification being developed by Lisa and Richard will be
> stable and there will be AT to support it.
> 2. Go back to an internal list which is short and only includes the
> supported values such as first name, last name etc. this may send us back
> to another round of CR. Or perhaps we've got it in time... I don't know.
> 3. press forward and to face the music
>
> My Preference would be #2.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> 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>
>



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

Advancing the mission of digital accessibility and inclusion