Re: @purpose="language"

See also:
https://support.mozilla.org/en-US/kb/control-whether-firefox-automatically-fills-forms

JF

On Mon, Mar 15, 2021 at 11:44 AM John Foliot <john.foliot@deque.com> wrote:

> 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
> http://john.foliot.ca/demos/autofill.php
>
> 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"
> autocomplete="language">
>
>
> 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:
> https://www.w3.org/TR/html-bidi/).
>
> 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:
> https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete
>
> Thanks.
>
> JF
>
> --
> *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"
>
>
>
>

-- 
*​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"