Re: Conflict Resolution

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"