- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 15 Mar 2021 11:44:09 -0400
- To: public-personalization-tf <public-personalization-tf@w3.org>
- Message-ID: <CAKdCpxyY8WoDROFGmf1S2-E1CxmZXzzN_fczCOcQM+uNRPdYHw@mail.gmail.com>
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"
Received on Monday, 15 March 2021 15:45:00 UTC