invalid-interactive should only be triggered for some event types? about ember-template-lint

[bendemboski]

onscroll is perhaps an even better example.

[rwjblue]

@bendemboski - Sorry for the super delayed response here. I agree that there are likely some tweaks we can make for this. I am not 100% certain what the right path forward is. Do you have a suggested path?

I'd like to rope in @nathanhammond for opinions also...

[nathanhammond]

@bendemboski Thank you for the detailed use case which makes it possible for us to analyze your goals and help you come up with a solution. This is the hallmark of a fantastic issue report.

The goal of invalid-interactive is to make you specify a valid ARIA role attribute so that assistive tech users are able to use your site. As you've described the interaction it's something that anybody using a screen reader or alternative input methods will be unable to accomplish as it requires precise mouse movement and building up of state.

An interactive element is any one which can trigger side effects. This is even the case for behavior which is simply event.stopPropagation(); return false; ... this change to the default behavior can break the assumptions that a user has. You must provide additional information to them in terms of role to communicate what's happening. For example, how would a screen user know that something would happen onscroll of an element? Or even that it scrolls in order to trigger that behavior?

So, invalid-interactive is still accurate here and it did catch questionable behaviors. Your approach simply doesn't account for the numerous edge cases which are a significant amount of work to handle correctly. As a linting rule this will always be the hardest one to meet so I wish you the best in getting it sorted out.

[bendemboski]

@nathanhammond thanks a lot for the thorough explanation! So, I totally get why we shouldn't implement my first option (a global filter on which types of events to and don't trigger invalid-interactive) now. But what about the second?

In practice I imagine some folks aren't interested in supporting the full gamut of assistive tech users, so what do you think of the idea of making the rule configurable so users can specify events that the invalid-interactive rule should ignore (the default being an empty set of such exceptions)?

[nathanhammond]

For this use case I would simply recommend turning off the rule in that particular template (<!-- template-lint invalid-interactive=false -->). I don't want to get into providing configuration for what amounts to partial turning off of a rule because at that point this rule doesn't provide any additional value (you've already opted into not supporting assistive tech). Also, as one of the people involved in Ember's accessibility efforts, I want people to understand the decisions that they're making.

[bendemboski]

The rule already allows you to configure a list of tags to ignore -- is this any different from the standpoint of partially turning off (blacklisting events vs. tags)?

I very much respect and appreciate your efforts toward promoting awareness of and support for assistive tech. I'm not using this rule with assistive tech in mind per se (supporting it is not a business requirement that we can justify spending resources on give our highly specific target user base), so maybe I shouldn't be using it at all. But it is still valuable to me to prevent people adding onclicks to divs or lis rather than using anchors or buttons.

It also seems to me that if people are using events for strictly aesthetic purposes like mousein/mouseout events to implement visual effects, or scroll events to operate a scrollspy (not needed for an assistive tech experience) it would be nice to give them a way to do so without littering their templates with instruction comments -- maybe others disagree, but I kinda view the instruction comments as a last resort.

So I guess I'm saying that I think this rule can still have value in at least a couple of use cases when partially disabled. If one of the goals of the rule is to educate people on assistive tech, I can respect that, but in my experience things like linting rules don't tend to do a great job of promoting education into something as complex as assistive tech, but rather promote the discovery of workarounds or the turning off of said rule :) We could always include a big disclaimer in the README's section on configuring this rule that if you blacklist anything you risk not actually supporting assistive tech, which might do a better job of promoting education than just making the rule all-or-nothing.

Anyway, I'm mostly continuing this discussion because I don't entirely agree with what you're saying, and I easily turn into this guy:

(credit: XKCD)

I don't actually feel that strongly about it, so if you're convinced I'm not going to change your mind, go ahead and say so, and I'll be appreciative of your consideration and the time you spent discussing this, and won't be grumpy or feel dismissed or anything. I will be a little grumpy that my templates have to keep looking like this:

<div class="container">
  <!-- template-lint invalid-interactive=false -->
  <div onscroll={{action 'onScroll'}}>
    <!-- template-lint invalid-interactive=true -->
     ...
  </div>
</div>

but maybe I can think up and propose a syntax for disabling a rule for a given element rather than a given range of lines and then feel better about how it looks :)

[rwjblue]

maybe I can think up and propose a syntax for disabling a rule for a given element rather than a given range of lines and then feel better about how it looks

FWIW, that is exactly what I am proposing in https://github.com/rwjblue/ember-template-lint/issues/79, I'd love your thoughts/feedback there.

[rwjblue]

Also, if we can land https://github.com/rwjblue/ember-template-lint/issues/79 I think we should just encourage that path instead of the proposal here.

My concern with adding a global configuration for this is that it is global ( 😝 ). Specifically, enabling a given type of event handler across all templates likely means that thought/care won't be put in on a per-usage basis (since it is allowed in all circumstances for all templates in the app/addon). To me, it seems better to explicitly state in your template that a given block in a given template intentionally opts out of the invalid-interactive rule (perhaps because the functionality itself is provided in an alternate way for users using assistive devices) than to allow all of your templates to utilize these non-accessible features without specific care/thought on a per-case basis.

@bendemboski - Would you want to take a crack at implementing #79?

[nathanhammond]

I like @rwjblue's proposed path forward here of #79. The advantage of linting instruction comments is that they're local and communicate exactly what you were trying to do. They're a bit "messy" but they do a better job of saying, "hey, so, this isn't exactly ideal." It's like a physical manifestation of a code smell. It also makes it easy to actually go back and identify areas where you can improve.

I do believe that it's possible to have presentation-only interactivity, that's not something that I was accounting for in my previous response. I suspect that most of those cases will be 100% bound on the JavaScript side. But for those edge cases I do want there to be escape valves. I believe the linting instructions to be ideal for that. So much of this is based in my goal of being careful to not create "separate but equal" experiences for users of assistive tech. The part that's hard for me is balancing what I see to be a social justice issue in its interaction with a technical issue.

The rule already allows you to configure a list of tags to ignore -- is this any different from the standpoint of partially turning off (blacklisting events vs. tags)?

I don't believe this to be a universal good and wasn't aware that it was possible. The original case for invalid-interactive was accessibility, raised by a member of the Ember A11y community team: https://github.com/rwjblue/ember-template-lint/issues/41

@bendemboski: Note that I'm still very happy to engage in this conversation, in no small part because of the way you've approached it. 😄 I appreciate the reasoned argument and it makes me think through my biases and experiences. I don't want to simply argue for "status quo" or "change all the things!" because that's a good way to end up at only a local maxima. Instead this forces me to understand and analyze my position. That being said, if we're not aligned at this point we should move to a higher bandwidth medium. 😄

[bendemboski]

Okay, I'm still a little skeptical of the effectiveness of something like a template linting rule for promoting education and participation in something as "lofty" as a social justice issue, but when tensions arise between convenience of the status quo and promotion of the interests of under-privileged/marginalized groups, I'm always in favor of erring towards the latter, so I'm on board.

Should we perhaps deprecate and then remove the ignored tags configuration option for the invalid-interactive rule? If so, I'm happy to open a new issue and/or PR for it. Either way, I'm closing this issue.

@rwjblue I'm happy to take a crack at #79, although it isn't exactly what I had in mind. I just left a comment on that issue elaborating, so we can take further discussion over there.

[nathanhammond]

Should we perhaps deprecate and then remove the ignored tags configuration option for the invalid-interactive rule?

I'm in favor of this, but I believe that we would still want to be able to use it on a local level. I don't know that we have the ability at this time to support differences in config available at global vs. local levels (since I don't believe that we support local rule-level config). We could expand #79 to also allow for local config via attributes passed in and then figure out how to allow vs. disallow global configuration.

[BryanCrotaz]

there are global default ignores that would make sense. I just got hit by

<img src={{url}} onload={{action "imgLoaded"}} onerror={{action "imgError"))

I can't see that these would ever require an aria as they're not user triggered. Is there a case for listing a global set of always-ignore to reduce the noise from this linter?

[bendemboski]

@BryanCrotaz whitelisting onload and onerror on img elements would be pretty simple code-wise (see here and here).

You could certainly open a PR, but note this issue and this issue imply that the intended direction is to move to a blacklist instead of a whitelist.