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

Re: @purpose

From: Matthew Atkinson <matkinson@tpgi.com>
Date: Sat, 1 May 2021 15:17:41 +0000
To: John Foliot <john@foliot.ca>, public-personalization-tf <public-personalization-tf@w3.org>
Message-ID: <6E306692-FAC0-46E6-8A4D-BC6D2768E8D1@tpgi.com>
Hi all,

Just a quick follow-up on the question that JF and Charles raised about multiple space-separated values for @purpose. John mentioned the spec has some examples on this; I checked and thought it'd be a good idea to summarise things as I understand them here. [I'm still reading up on the research Sharon and others sent earlier in the week; thanks!]

The HTML spec describes the use of qualifiers with autocomplete values [0]. Here are three ways qualifiers can be given and used:

1. Some of the standard autofill values, like "tel", can be prefixed with "home", "work" (or some other things) to provide context (is it a home telephone number, a work telephone number or so on). The demo page I made shows an example of this; when it encounters multiple attributes, it injects a qualifier symbol before the "purpose" symbol to convey that scope to the purpose.

2. It looks like _all_ autofill purposes can be prefixed with either "billing" or "shipping" for similar reasons.

3. To provide further disambiguation (e.g. if there are two different shipping addresses in the same form) you can make a generalised prefix of the form "section-*" to differentiate groups of controls. This semi-custom value goes towards specifying the "autofill scope" [1] for the respective input. Each input control has an autofill scope, and the other two types of prefix mentioned above also contribute to it. I don't think it's intended that these "section-*" values be exposed directly in the UI. The example given involves a "red gift" and a "blue gift" being sent out, presumably with visual styling on the page that would make the demarcation clear. The values "section-red" and "section-blue" are included in the @autocomplete attributes for each control to differentiate between the sets of shipping addresses programmatically. (This is like setting @name on radiobuttons to provide programmatic grouping.)

It seems to me that at least the first two of the above cases could directly help all users (so would be in scope for us). The "section-*" prefixes may well hint at helpful info, but I think instead of being able to rely on the name given as part of the "section-*" values, which the HTML spec explicitly says is not to be taken to have any meaning, we would probably want to rely on the name given to the respective section/region of the page. It feels like we'd therefore be encouraging the use of named landmark regions to correspond to any structurally important and visually-indicated areas of the page, which is best practice, but out of scope for us.

Hope this helps, and would appreciate someone checking my interpretation of the spec.

Best regards,


Matthew

[0] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofilling-form-controls:-the-autocomplete-attribute

[1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill-scope

-- 
Matthew Tylee Atkinson
--
Senior Accessibility Engineer
TPG Interactive
https://www.tpgi.com

A Vispero Company
https://www.vispero.com

--
This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately.
Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.

´╗┐On 14/04/2021, 13:43, "Matthew Atkinson" <matkinson@tpgi.com> wrote:

    Hi John, Charles, all,

    On 12/04/2021, 21:09, "John Foliot" <john@foliot.ca> wrote:
    > The concerns:
    > 1. I thought our attribute could be used on more than just an input type of text - in fact, that is one of the primary benefits to me, as @autocomplete cannot be applied to <select>, <legend> (or an aria grouping for radio buttons or check-boxes), nor radio buttons or checkboxes. As such I believe we need to re-author or modify the opening paragraph to better explain that the @purpose attribute can be applied to *ANY* form input. (Open question: can it be applied to a div marked as content editable?)

    I think it'd be a good idea to make the @purpose attribute applicable to more form fields. In fact, I have been drafting an email over the past couple of days which I will send imminently that ties in with this and asks if we should consider going even further.

    > 2. The last paragraph - do we really anticipate a space separated collection of values for @purpose? Can anyone bring forth a use-case? (I can't), and so we may have to remove that final sentence (which also restates that there is no default value - so we need to tighten that text up anyway).

    I'm interested as to what everyone thinks about this. I can't think of a reason to have more than one purpose on a single input (or valid grouping) but I defer to your and others' experience.

    best regards,


    Matthew
    --
    Matthew Tylee Atkinson
    --
    Senior Accessibility Engineer
    TPG Interactive
    https://www.tpgi.com

    A Vispero Company
    https://www.vispero.com

    --
    This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately.
    Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.


Received on Saturday, 1 May 2021 15:17:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 1 May 2021 15:18:00 UTC