- From: Matthew Atkinson <matkinson@tpgi.com>
- Date: Mon, 19 Apr 2021 15:23:47 +0000
- To: "public-personalization-tf@w3.org" <public-personalization-tf@w3.org>
- CC: Charles LaPierre <charlesl@benetech.org>
Hi all,
Thanks again to everyone for your input so far. As discussed on the call today, here are links to the demo I've been working on. Input as to real-world scenarios, anything I've missed, and links to the minutes where the approaches were discussed would be greatly appreciated (I know Becky mentioned some dates for the minutes, so I'll be looking into those too).
Demo page: http://matatk.agrip.org.uk/personalization-semantics-explorations/demo.html
GitHub repo: https://github.com/matatk/personalization-semantics-explorations
Things I am actively looking into...
* Historical details (will check the wiki again, and look for the minutes; if you find any specific references that'd be great too).
* Real-world examples (needs as much input as we can find; as above).
* Investigating whether there are scenarios where it makes sense to have multiple attributes on the same element (raised by Lionel on the call).
* Investigating whether there are scenarios where we might have an implicit or explicit role of "button" but a valid reason to convey this as a destination (raised by Lisa on the call; relates to real-world examples I think).
* I am sure I can simplify my code a bit too.
I hope the demo is helpful as-is, but am keen to improve it to make it more so, and to learn from the group's other work and experience in this area.
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.
On 14/04/2021, 15:40, "Charles LaPierre" <charlesl@benetech.org> wrote:
CAUTION: This email originated outside Vispero. Do not click links, open attachments or forward unless you recognize the sender.
Holy epiphany Batman!
Wow, Mathew some radical ideas here, and something we definitely need to discuss as you made some great insights and by taking a step back you may be onto something. I think I like these ideas even the most radical of combining everything but I think we really need to see what implications that would mean if anything, but looking at the underlying roles of what you put it on might be the solution as you suggested.
Sure would simplify things and make it really easy for the developer which was Lisa's main issue initially. I think we were all struggling with the potential complexity of our proposal but if we can simplify this to 2 or 1 main attribute this would make getting into HTML 3x times easier. Going and asking for 1 term from WHAT-WG would be REALLY nice. But this also means massive rework of our spec, but maybe its worth it if we all agree and can't think of why we really need these separate.
Lisa or others can you think of why this couldn't work?
Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Imageshare Product Manager
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
On Apr 14, 2021, at 5:45 AM, Matthew Atkinson <matkinson@tpgi.com> wrote:
Hi all,
I've been wondering, based on recent discussions (and a caveat, noted below)...
1. Are @action and @destination similar enough that they should be combined?
2. Likewise but with @action, @destination _and_ @purpose?
3. Whether or not it's combined with others, should @purpose be expanded to more elements, including non-interactive content?
The starting points for this were Joanmarie's observations and Becky's message in issue #66 [0], notes in the draft spec and discussions we've had on-call [1]. I agree with JF and Charles' email about the applicability of @purpose to a range of form controls [2].
Caveat: as mentioned on the call, I'm aware that I'm new here, and am still researching the rationale as to the chosen attribute values, and the intended use of the attributes, and thus would particularly appreciate your thoughts. I also have not yet looked into the subsequent modules in detail. My main aim is to better understand the spec and expected implementations. I've tried to ask the questions first in the following sections, and then provide rationale and sometimes code samples afterwards. I have also included "Anticipated Frequently Asked Questions (FAQs)" at the end.
// 1. Considering combining @action and @destination
There are two questions I'd like to understand...
* Are anticipated UAs/Browser Extensions/Assistive Technologies (ATs) expected to use @action and @destination attributes differently? If so, can't they gather the link/button distinction from the underlying element's role?
* If users only need to be presented with info based on the _value_ of the attribute, and it doesn't make any difference which attribute was used, then why separate them?
Picking up the example we discussed on the call: sometimes the 'sign-in' form for a site may be a pop-up dialog on the current page, or a separate page. We note in the spec that an @action would normally be attached to a button, and @destination to a link. Depending on whether the log-in form is implemented as a dialog or a page, we could have either of the following code snippets.
<a href="/login.html" data-destination="sign-in">Log in</a>
<button data-action="sign-in">Log in</button>
But can't we already infer which is an action and which is a destination from the element (or role) used? Therefore couldn't we just have one attribute instead. For now I'll call it "facilitates" [this is not a name I am really proposing]. Our two code samples become...
<a href="/login.html" data-facilitates="sign-in">Log in</a>
<button data-facilitates="sign-in">Log in</button>
Would the developer/author be cognisant of the need to use the appropriate element? Well we actually know from practical experience that some people are _not_ aware of this need, but that's not a problem specific to our spec. However, given we know there's already a decision to be made between buttons and links, doesn't it complicate things further to layer another choice—of @action or @destination—on top? And if an author isn't in a position to make an appropriate choice at the element level, would this extra choice at the attribute level ultimately help the user? If the nature of the element and the attribute mismatched, which would we trust?
There's also the question of how this is going to be used: Joanmarie asked on issue #66 if the distinction was needed for our purposes. I don't know—still learning—though §3.2 does say:
A personalization agent or user agent may add additional familiar user interface features to help users understand the link and follow the right one easily.
Seeing the attributes as the same may seem odd, as we have far more actions than destinations, and there are only relatively few I've seen so far that appear to be both—but if there's no technical difference, should we be separating them? More on this later and in the 'anticipated FAQs' below.
// 2. Considering combining @action, @destination and @purpose
I know this sounds radical, but bear with me. (Also note the caveat from the start :-).)
Whilst the spec says @purpose is for text input fields (and I agree with JF and Charles that it seems this could usefully be broadened [2]), could it be even more widely useful? For example: if there's a contact telephone number in the banner of each page, that could be marked up as static text. But wouldn't it be helpful to be able to use @purpose there, to indicate it's the "tel" (in HTML-autocomplete-speak) for the organisation?
From reading the spec, I can't envisage a situation in which we would supply both an @action/@destination _and_ a @purpose, so: do we actually have one combined @purpose attribute that could take any of the current @action, @destination or @purpose values?
(In fact in the above example, the phone number may've been marked up as a link. We already have a @destination value of "phone" but that seems to be the same thing really as the "tel" @purpose value, which is also a standardised autocomplete value. This made me realise that we have some overlap with the autocomplete values, so we have an opportunity to consolidate and become "more standard" if you will :-).)
Anyway, back to the combined @action/@destination/@purpose attribute. If the author set this broadened @purpose attribute on an element...
* with a role of 'link' then it's signifying a destination;
* with a role of 'button' then it's signifying an action;
* that's a form input control, or grouping element, then it's signifying a purpose;
* containing content then it's signifying a meaning.
Though again, as Joanmarie asked, is there a distinction here from our perspective? And again again, even if there is, can't we reliably get that distinction from the role of the element?
Why combine all three attributes, as opposed to just @action and @destination?
* It seems they are all doing the same thing—telling the user what an element is for, or does, or means—but they're just applied to different types of elements.
* I interpret the current spec as implying that we would not set @purpose on an element that already had either @action or @destination, so there's no chance of collision. However, we should ask: are there any cases we can think of where you would want to set more than one of these?
* Having fewer attributes for developers to think about in order to provide personalization semantics seems like a good idea. We would have four rather than six in total if we merged these three.
* I think "purpose" really works as a name for all three of these and, coupled with that, wonder if it could make adoption into standards such as HTML easier, as we only need one additional word instead of three for these attributes. However that's a secondary consideration; we need however many attributes are justified to address user needs.
Why _not_ combine them (any, or all)?
* My understanding is that we are fundamentally indicating the purpose of things with all three of these attributes. If this is not the case, then I've missed something and this would likely be invalid.
* I can't think of other specs that have such a wide variety of possible values for an attribute, though I would say again that if they really are all serving the same function, I'm not sure that's a problem.
A less drastic version of this proposal would be to have two attributes instead of just one:
1. a combined attribute that encompasses what @action and @destination currently are, which I actually propose should be called @purpose because it fits both.
2. an attribute that can be used to signal the intent/meaning behind a form input or content, which is @purpose as currently specified, but I think suits the name "meaning" more. (The term "intent" is used in Android apps, so could be confusing.)
This feels like it makes sense too, but do we _really_ need two separate attributes here—aren't they both just saying what the purpose of the element is?
// 3. Considering broadening @purpose to any form control or static element (but not buttons nor links)...
I hope the example in the previous section demonstrated that @purpose might be useful on static content as well as form fields. I'm aware that we have @symbol for marking up static content, and I totally support it, but...
@purpose gives us some ready-made really common keywords that devs could easily understand because (a) they're already standardised and (b) they are referred to by words (which I ACK is most helpful for people who understand English, but they still form a shortlist of highlighted known-widely-useful token values). Whereas for @symbol, the developer would need to look up the appropriate number(s). That means it works universally, but with a higher barrier to entry.
It seems to me that lowering the barrier to entry for developers/authors by allowing these standard "purposes" to be used would be a good thing. This assumes that we could always use the same symbol for these purposes—though I think that's implied by the spec, so hopefully I'm on the right lines there.
// Anticipated FAQs
0. But AT/use-case X needs to differentiate between an action, destination or purpose!
This is my main concern, and in general I do believe being explicit is better than implicit, but redundancy is bad. Again I would ask: is the choice of underlying element (or role) already being explicit enough?
Are there any situations in which the user would need the element's role to imply one thing and the attribute another?
1. But some things are just actions, and not also destinations!
This is absolutely the case; things like play/pause on media are actions only. So we'd expect them to be implemented as buttons. They _may_ be implemented as links, but that would already be a potential usability/accessibility issue. We're at least not adding to the confusion in that case.
Conversely, someone could have a link that goes to a different page and errantly put a 'play' @purpose value on it. But they could've made the same mistake by saying that this link is a 'play' @action just the same (albeit having to type 'action' there may've made them double-take and reconsider).
Either way it doesn't seem like we are making the problem worse.
Could we spec things in such a way as to avoid _any_ such confusion? We could specify rules such that certain values for @purpose are only valid on elements with particular roles. That doesn't seem too complex, though I'm not sure if you find it overly prescriptive.
The more I think on it, though, if we are using all of these values for _technically_ the same purpose, it seems we should be treating them technically the same (this puts in my mind the "You Ain't Gonna Need It (YAGNI)" principle in software development.
2. Does this mean we can't rely on the standard autocomplete attributes?
As I understand it, we can still import those, and add any other things we want. We just can't _change_ the definitions of the autocomplete purposes, but I don't think anything we, nor I, have proposed does that [BCP47 issue now resolved from our perspective].
3. But @purpose accepts a space-separated list of values, whereas @action and @destination require exactly one value!
True, and this could be a sticking point, though as JF and Charles observed, are there use-cases for this? When would we mark up one element (or grouping element in the case of checkboxes/radiobuttons) as having multiple purposes?
I wouldn't want to preclude useful use cases though, so defer to your thoughts.
4. Combining @action and @desination seems reasonable, but why @purpose too? That is a totally different set of attributes!
ACK. It's true that the autocomplete values are not entirely similar to the action/destination values we have already—but there is some overlap around contact/phone info. My initial thoughts were that it seems nicer to have fewer attributes, and I can't imagine a situation in which we'd want both an @action/@destinant and a @purpose, so why not share the attribute (and 'purpose' is a lovely word that fits all of the possible uses)?
However this lack of imagination may well be a flaw on my part :-) and maybe this is going to far in the name of simplification.
I don't feel (as above) that this would be exacerbating the problem of misleading the user about the nature of elements; we have to assume the dev is adding personalization semantics with the best intentions, and whilst we accept that sometimes they will get it wrong, as they do with other accessibility-related attributes, user testing and auditing should find these just as it would other accessibility problems.
Wondering what everyone thinks. I'm very interested in finding out more about the context of the actions and destinations, and am working on that (thanks Charles for the tip to look into COGA's work).
best regards,
Matthew
[0] https://github.com/w3c/personalization-semantics/issues/66
[1] https://www.w3.org/2021/04/12-personalization-minutes.html
[2] https://lists.w3.org/Archives/Public/public-personalization-tf/2021Apr/0010.html
--
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 Monday, 19 April 2021 15:24:05 UTC