Re: Conflict Resolution from Matthew Atkinson on 2021-05-10 (public-personalization-tf@w3.org from May 2021)

From: Matthew Atkinson <matkinson@tpgi.com>
Date: Mon, 10 May 2021 12:57:58 +0000
To: John Foliot <john@foliot.ca>
CC: Charles LaPierre <charlesl@benetech.org>, public-personalization-tf <public-personalization-tf@w3.org>
Message-ID: <0AE499D0-58AA-4EE6-AF0C-91886A9C8B14@tpgi.com>

Hi JF, all,

I agree we should go with the semantics that get exposed in the accessibility tree, so an anchor with role="button" is a button, and you'd expect it to have an @action attribute rather than a @destination.

Our existing action="opens-in-page-help" seems rather clunky; why not just have action="help"? Because it's an action, we know that the help will be opened in-page. Similarly I think we could have action="signin" for buttons that trigger pop-up login forms. I think it's helpful to consider your example, which is, for convenience:

Essentially this is saying that:

* this element, being a button semantically, triggers an action;
* the action happens to be opening a dialog;
* the purpose of the dialog is to provide help.

When considering this, my train of thought was...

* this seems to be overloading _some_ @destination values as things that aren't strictly destinations;
* the reason we are doing this is because we need to indicate an action will occur, but some of those "meaning" values are not specified as being actions;
* wouldn't it be simpler to allow some existing @destination values to be used as @action values, when the thing that happens doesn't take the user to a new page?
* what if we are triggering an action, and the action relates to help, but we're _not_ actually opening a dialog?

We've concentrated on the idea of buttons opening dialogs. However, one action that the help button might trigger is to show tooltips above all UI elements on the screen. That's not quite opening a dialog (in the traditional sense at least), but it is providing help info, so in that case I think action="help" is more descriptive, and less restrictive, than action="opens-in-page-dialog" destination="help".

In summary I feel that the following approach is clearer and gives more leeway for different sorts of UX to be provided, whilst still allowing us to support users by conveying the meaning.

I think this is really helpful discussion; these are the sorts of questions we are bound to get I'm sure.

best regards,

Matthew

P.S. I ACK and understand that a response to issues such as #66 was to separate most @action and @destination values but: either deciding to allow some values to be valid for both attributes after all _or_ implementing a suggestion such as JF's would result in clarifications to the spec—and I'm sure we'll be asked about it, so it's good we're pre-empting that.
--
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 03/05/2021, 17:46, "John Foliot" <john@foliot.ca> wrote:

To expand that further, we could then have something like this:

(This then argues for keeping the 3 attributes distinct, and NOT merging them together).

On Mon, May 3, 2021 at 12:43 PM John Foliot <john@foliot.ca> wrote:

Hi Matthew,

> how the @role attribute would be taken into consideration (we aren't changing semantics with our spec, but which semantics do we recognise?)

My $0.02 is that our attribute choice should map the actual semantic of the element. If that semantic is changed using the STRONG semantics of ARIA, then the choice of which of *our* attributes the author chooses should still map to whatever is being exposed to the Accessibility Tree.

So, <a href="" role="button"> MUST take the @action attribute to be 'valid'.

I will note however that your use-case of a 'log-in dialog' isn't completely covered by out attribute values - the closest we have for @action is the value "opens-in-page-help", which, in the context of a login is not quite right, so a minor tweak to that value may be appropriate. I will suggest "opens-in-page-dialog" might be more extensible, and cover more use-cases.

Thoughts?

On Mon, May 3, 2021 at 11:41 AM Matthew Atkinson <matkinson@tpgi.com> wrote:

Hi all,

As clarified on the call today, my "Set 1" of examples below is incorrect because "help" is no longer both an action and a destination (oops!) My intention with "Set 1" was to ask specifically about an attribute value that could be either. I just wrote a quick script to check if we have any values that could be either and we do: the only one is "end". I'm not sure if that is intended, or whether we will separate that one too.

We also discussed on the call that a browser, per convention, would just ignore invalid values/markup (and I gather that we'd expect an extension or other sort of UA to do the same). However, I think we have come close to, but not yet resolved, how the @role attribute would be taken into consideration (we aren't changing semantics with our spec, but which semantics do we recognise?) Therefore I think the "Set 2" of examples below should still be useful for discussion.

Best regards,

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

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

On 27/04/2021, 11:10, "Matthew Atkinson" <matkinson@tpgi.com> wrote:

Hi all,

Funnily enough I drafted an email on this subject last night and then found all these interesting and helpful threads on-list. In the next few days I plan to follow up on all the reference and other info; thanks JF, Lisa, Sharon and all.

I too wondered if it might help to focus on one part of conflict resolution first. Below are several markup snippets (some similar ones are in the demo page, implemented as I understood the spec). For each scenario, I'd like to understand:

1. What does the markup mean? Would we consider it valid?
2. What would we expect the user agent (or extension) to render, focusing on the personalization aspects? I agree with JF that we are not trying to override elements' semantics, so I would expect a <button> to still look like one in the browser, but expect it'll be augmented with additional info.

Lisa explained on the call that the most helpful behaviour can depend on the user. In which case, would we tend towards being more accepting, and expect there to be preferences within the user agent/extension that tune the level of adaptation made? Or would we specify that certain combinations are strictly invalid and should be dropped from rendering entirely?

Set 1: When the personalization attribute value is both an action and a destination

A. <a href="#" destination="help">
B. <a href="#" action="help">
C. <a href="#" role="button" destination="help">
D. <a href="#" role="button" action="help">

Set 2: When the personalization attribute value is specifically an action

E. <a href="#" destination="volume">
F. <a href="#" action="volume">
G. <a href="#" role="button" destination="volume">
H. <a href="#" role="button" action="volume">

I have thoughts on these and could post them in a follow-up, but I'm keen to hear your views.

Hope this helps keeping things moving. I think Charles' suggestion of asking the TAG for advice could be helpful, and would be happy to help draft/review any documentation for them.

best regards,

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

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

On 26/04/2021, 18:39, "Charles LaPierre" <charlesl@benetech.org> wrote:

Hello All,
Reading over the minutes, looking at the demo page by Mathew (which is just excellent btw!) and the few emails on this topic.
I find myself on the fence. I like Mathew's ideas, I worry what is the right approach ease to the authors, validators, and the AT implementers.

I am wondering if this is something we should seek guidance from the TAG and get their view on this, because as Janina mentioned this will get a LOT more eyes on this and we need to have a clear and compelling reason / justification of why we chose what we did or there will be formal objections when we try to go to CR and beyond.

I also don't want to keep delaying things unnecessarily but this is a big fork in the road for us and let's make sure we are going down the right path and have solid backing before we then send it out to the community to pick apart. Having the backing of TAG would be an Ace in the hole for us and to hear their thinking on the various options of keeping things separate, combining everything vs combining two of our attributes into one.

Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Imageshare Product Manager
Twitter: @CLaPierreA11Y
Skype: charles_lapierre

On Apr 26, 2021, at 8:15 AM, John Foliot <john@foliot.ca> wrote:

Hi All,
A topic that bubbled up on our call today was around conflict resolution: what do we do if/when an author uses the wrong attribute?

<opinion>
I think one of the positives for staying with 3 attributes (action / destination / purpose) is that it would make parsing tools (i.e. the W3C validator) far simpler to catch author errors. Actions belong on buttons (<button>, role="button"), destinations belong on links (<a href...>, role="link") and purpose belongs on form inputs. The direct 1-1 mapping means that if the author does not respect the mapping, it generates an error. That is both simple to catch via a validator, and simple to teach authors moving forward. (Two key considerations we should keep in mind IMHO).

To that end, I would also propose that our attributes take the exact opposite approach from what ARIA attributes do (strong semantics - over-rides native semantics) by instead having weak ("hint") semantics. In other words, our attributes augment existing elements, they don't seek to modify or change them in any way. I believe this would also resolve the open question related to computed roles: our attributes simply augment whatever the role is computed to be.

More specifically, a form input will always have a role of 'input', and our @purpose attribute would not change that - it simply and unambiguously clarifies what type of content is expected.

And while I appreciate Matthew's "less is more" approach in trying to merge the 3 attributes of action, destination, and purpose into one 'super' attribute, I personally don't think we're gaining that much, and potentially we may be introducing more confusion.
</opinion>

JF
--
John Foliot | Senior Industry Specialist, Digital Accessibility

"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"

--
John Foliot | Senior Industry Specialist, Digital Accessibility

"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"

--
John Foliot | Senior Industry Specialist, Digital Accessibility

"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, 10 May 2021 12:58:15 UTC