Re: Conflict Resolution

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

<a href="" role="button" *action="opens-in-page-dialog" destination="help"*>

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

JF

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?
>
> JF
>
>
>
> 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
>> --
>> 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 27/04/2021, 11:10, "Matthew Atkinson" <matkinson@tpgi.com> wrote:
>>
>>     CAUTION: This email originated outside Vispero. Do not click links,
>> open attachments or forward unless you recognize the sender.
>>
>>
>>     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
>>     --
>>     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 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"