Re: Conflict Resolution

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<mailto: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"