Improve Violation Highlight Styles

[BrianSipple]

This PR attempts to address some of the challenges outlined in #19 -- which seems like a great use case for striped gradients. (@nathanhammond, your right on that it would be difficult to define a color that will apply to all UI styles but with striped gradients, we aren't limited to just one 😀).

I put together a Codepen demo with some of the ideas that I've been prototyping for a violation warning -- which includes a few variants of striped repeating linear gradients and SVG filters. And at the moment, I decided on this:

The color scheme (transparent / mint-yellow / aqua-green / navy-blue, seen here over a black background) was chosen so that it will provide a strong contrast against either light or dark background -- with special care to ensure that this was also true for color-blind users. I also added a rule that removes the gradient on hover so that a user can always inspect the original element when they see the warning appear over it. Overall, this approach feels a lot more clean and performant than creating new markup and trying to perform reads/writes in the DOM to position it correctly over each component.

But that's just our default. Which takes effect by the audit function applying the axe-violation class to offending nodes. For customization purposes, I added logic that allows a user to have their own classes applied instead -- by exposing an axeViolationClassNames property that takes an array of user-provided class names. This array then gets used instead of our default name when the audit function adds classes:

Ember.$(node.target.join(','))[0].classList.add(...violationClassNames);

The more I think about it, this can also be one of the options we allow at the ENV config level while we're at it.

Furthermore, if someone really wants to do heavy stuff with their violating components in JavaScript, they'd already have the ability to do that through the axeCallback that we support. Perhaps we could add a few "recipes" to the README for how to do this if it seems like there's a significant use case?

[nathanhammond]

You may want to !important this since the specificity here is very low.

[BrianSipple]

Ah, I wanted to bring this up as an open question as well.

Part of me feels like it would be good to leave off !important here. The low specificity isn't too concerning so long as no one defines their own .axe-violation rules (i.e: we're not just trying to target div or something) -- and if they do, that may well be a valid use case that we shouldn't get in the way of.

But then I can see the other side: .axe-violation is our special sauce -- and, for their own good, someone using ember-a11y-testing shouldn't try to override it, as it would only add ambiguity to their markup.

[nathanhammond]

I'm more saying that another selector targeting an invalid element like #something .blue-background will win compared to ours without !important.

[BrianSipple]

Oh.... yep, that's absolutely true. I was only considering using the same class. Thanks for thinking outside of the box model.

[nathanhammond]

That is certainly going to get somebody's attention! I like the solution. A lot. You have a couple of failing tests that seem like they're simply relying on an element's existence which can be undefined but other than that I'd like to land this. 😄

[BrianSipple]

I'm starting to think that a greater proportion of transparency looks better between those stripes -- and that the stripes should be moving "forward":

[nathanhammond]

I like it. It's also possible that we should scale the background-image to make sure that tiny elements still get "striped."

[BrianSipple]

@nathanhammond Hmm... if I'm understanding what you're getting at by "scale", that's what I had in mind by using percentage values for the gradient stops to render the screenshot above (the percentage being relative to the container size along the gradient axis):

repeating-linear-gradient(
    135deg,
    transparent,
    transparent 25%,   /* make transparent portion somewhat wider than total stripe width */  
    var(--color--mint-yellow) 25%,
    var(--color--mint-yellow) 30%,
    var(--color--aqua-green) 30%,
    var(--color--aqua-green) 35%,
    var(--color--navy-blue) 35%,
    var(--color--navy-blue) 40%
  );

* Variables here are from the Codepen, but raw values are all we'd actually use.

More to that point, though, I'm also leaning towards if ems (font-size of the current container) as a better hook for relative sizing. That way, if you had a large container -- perhaps even with a transparent background -- with just a small amount text as the visible content, the text would still get striped. Below is the "card" with em gradient stop sizing, and then two text examples...

Percentage-based gradient stop sizing:

em-based gradient stop sizing:

... Kind of digging the ems 😄.

[nathanhammond]

We can delete this file.

[nathanhammond]

@BrianSipple Turns out I didn't understand your code and you were already way ahead of me on this. I like the way the smaller sizes work out. At this point I'm deferring to your implementation. I have no additional comments on the code. So, .

axeCallback ... "recipes" to the README for how to do this if it seems like there's a significant use case

Let's keep this in our back pocket and watch for feature requests as they come in that can be solved with this.