Re: Conflict Resolution

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"

Received on Tuesday, 27 April 2021 10:10:36 UTC