Re: Unsupported Autofill values and Common Purpose

Hi David,

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

I have now successfully shown support for roughly 50% of the values
<> in
the browsers via native support (the original 18 number was when I did not
have an SSL certificate, which I do now:, 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 <> - 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 <>, 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 -

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).


On Mon, Feb 19, 2018 at 9:42 AM, David MacDonald <>

> 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
> <>
> GitHub <>
> <>
> *  Adapting the web to all users*
> *            Including those with disabilities*
> If you are not the intended recipient, please review our privacy policy
> <>

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.

Advancing the mission of digital accessibility and inclusion

Received on Monday, 19 February 2018 16:07:36 UTC