W3C home > Mailing lists > Public > public-personalization-tf@w3.org > March 2021


From: John Foliot <john.foliot@deque.com>
Date: Mon, 15 Mar 2021 11:44:09 -0400
Message-ID: <CAKdCpxyY8WoDROFGmf1S2-E1CxmZXzzN_fczCOcQM+uNRPdYHw@mail.gmail.com>
To: public-personalization-tf <public-personalization-tf@w3.org>
Hello all,

Respectfully, I believe there is still significant confusion over this
particular attribute. I'd like to attempt to set the record straight.

Our @purpose attribute is an extension of the work initially done
with @autocomplete, which today is really the only viable way of meeting
WCAG 2.1's SC 1.3.5 "Purpose of Input" - up to and including the fact that
the *ONLY* approved values for the attribute @purpose is the list of terms
we have published, of which Language is one such term.

As part of testing the @autocomplete function for advancing WCAG 2.1's SC
1.3.5, I built out a series of test pages with a single form which includes
*EACH* attribute value. The first test page (of a series) can be found at

If you have previously stored any data on your browser, the expected
user-behavior is that as you start to type in your First name, the browser
will offer to "autocomplete" the rest of the form with all the data it has
*about you* stored in the lookup list.

Go ahead, try it (and you'll likely see that the form input for language
will remain blank, because currently I am unaware of a *browser* that
stores that data - if you use a password manager, it *MAY* have stored the
response value you wish to use).

As you can also see, the Valid W3C Usage of autocomplete="language" has
been rendered on the form:

<label for="36">Language</label> <input type="text" name="36" id="36"

From my testing, I do not recall any *browser* natively supporting this
particular attribute VALUE, although a couple of Password managers did (I
vaguely recall LastPass doing the best job there).

If you visit that page as a user, you can input *ANY* language you want
into that text input, however for a user agent to "know" what value to use
when pre-populating that information, it needs to be stored elsewhere on
the user-agent: either in the browser, or in a helper application (like
LastPass). Our attribute provides the first part of "the lookup", but
unless the response has been stored, the input will remain blank when the
browser/user-agent attempts to autofill the form.

As Lisa noted, we hope and expect that tagging an input with a
machine-readable value can also be used for other accommodations (like
providing an icon in lieu of a text label), however for a machine to
replace that text with an icon, it needs to know which icon to use for
which input - and the input that collects language (usage, preference) will
need to be specified (language.ico) - but the icon is to indicate that
the *form
input WANTS to know your language preference*, and NOT to determine or
otherwise modify or change the on-screen text: *THOSE* functions are
determined elsewhere using either the @lang attribute (on the page, the
form, or inline) and/or bidirectional text (see:

It is also important to note that this 'language information' is NOT stored
on OS installation (unlike other language directives) as it is actually not
related to language at all (as it relates to on-screen text, or screen
reader support): instead, today, it is simply half of a collection of
voluntarily stored values on the user's machine (as are all the other
possible values for @autocomplete, or @purpose). As noted, LastPass (when I
last tested it) had the most robust support for 'autofilling' form inputs,
where users can add all the required data they wish, up to and including
custom terms and responses (values): Autofill Credit Cards, Forms, and
Passwords with LastPass <https://www.lastpass.com/autofill>

The fact that browser support today is poor (for @autocomplete) is
concerning, however one of the reasons for developing @purpose was to try
and offset some of that lack of support, as well as to expand the types of
inputs that can take the @purpose attribute (@autocomplete cannot be used
on radio buttons or checkboxes). However the overarching goal was to
provide a contextual hint to the input, so that the machine can step in and
- by using machine-readable values - 'do something' to/with the input
element. This attribute and single value are not intended to have any
impact on the actual page (outside of providing a hint to that text input).

Please see also:



*John Foliot* | Principal Accessibility Specialist

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"
Received on Monday, 15 March 2021 15:45:00 UTC

This archive was generated by hypermail 2.4.0 : Monday, 15 March 2021 15:45:01 UTC