johnfoliot
commented
3 years ago 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 "Identify Input Purpose" - 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 any browser that stores that specific piece of 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">This is not to be confused with:
<form lang="de">
<label for="36">Sprache</label>
<input type="text" name="36" id="36" autocomplete="language">
</form>
-- or --
<form lang="ru">
<label for="36">Язык</label>
<input type="text" name="36" id="36" autocomplete="language">
</form>...which is what I believe is your concern around language. (I'll also note that this is essentially the same issue/response to bidi content as well).
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 so that the User Agent can then accurately assign the appropriate icon (language.ico) to the related input - 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 - in the future - @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): 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: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete See also: https://support.mozilla.org/en-US/kb/control-whether-firefox-automatically-fills-forms
https://www.w3.org/TR/WCAG21/#input-purposes
Language identification is widely standardized on IETF BCP47 language tags. Use of descriptions ("English") or other standards (ISO639 part whatever by itself) is not recommended. Please refer to BCP47 here.