It looks like not all screen readers identify SVG images with empty aria
labels as a decorative image, as reported by the Axe accessibility
engine.
So we're using `aria-hidden` instead, since we don't want the text of
the SVG to be read by screen readers. We're using `aria-hidden` instead
of the `presentation` role for the reasons mentioned in commit
35659d441.
The initialjs-rails gem hasn't been maintained for years, and it
currently requires `railties < 7.0`, meaning we can't upgrade to Rails 7
while we depend on it.
Since the code in the gem is simple, and we were already rewriting its
most complex part (generating a background color), we can implement the
same code, only we're using Ruby instead of JavaScript. This way, the
avatars will be shown on browsers without JavaScript as well. Since
we're adding a component test that checks SVG images are displayed even
without JavaScript, we no longer need the test that checked images were
displayed after AJAX requests.
Now the tests show the user experience better; people don't care about
the internal name used to select the initial (which is what we were
checking); they care about the initial actually displayed.
Note initialjs generated an <img> tag using a `src="data:image/svg+xml;`
attribute. We're generating an <svg> tag instead, because it's easier.
For this reason, we need to change the code slightly, giving the <svg>
tag the `img` role and using `aria-label` so its contents won't be read
aloud by screen readers. We could give it a `presentation` role instead
and forget about `aria-label`, but then screen readers would read the
text anyway (or, at least, some of them would).
These images are always displayed next to a username, meaning people
using screen readers were hearing the same username twice in a row.
Even though we're about to replace the initialjs gem, we're making this
change in case so we've got one more test and we can check everything
keeps working after replacing the gem.
The `use_helpers` method was added in ViewComponent 3.8.0, and it's
included by default in all components since version 3.11.0.
Note we sometimes delegated the `can?` method to the controller instead
of the helpers, for no particularly reason. We're unifying that code as
well.
Not all the colors initialjs uses by default provide enough contrast
against a white text. The default initialjs colors are:
["#1abc9c", "#16a085", "#f1c40f", "#f39c12", "#2ecc71", "#27ae60",
"#e67e22", "#d35400", "#3498db", "#2980b9", "#e74c3c", "#c0392b",
"#9b59b6", "#8e44ad", "#bdc3c7", "#34495e", "#2c3e50", "#95a5a6",
"#7f8c8d", "#ec87bf", "#d870ad", "#f69785", "#9ba37e", "#b49255",
"#b49255", "#a94136"]
We're replacing them with colors containing less luminosity when
necessary in order to get a 4,5:1 contrast (it could be argued that a
3:1 contrast is enough when the icons are big, but that isn't always the
case and more contrast doesn't hurt):
["#16836d", "#12826c", "#896f06", "#a06608", "#1e8549", "#1e8549",
"#b35e14", "#c75000", "#207ab6", "#2779b0", "#de2f1b", "#c0392b",
"#9b59b6", "#8e44ad", "#6c767f", "#34495e", "#2c3e50", "#66797a",
"#697677", "#d82286", "#c93b8e", "#db310f", "#727755", "#8a6f3d",
"#8a6f3d", "#a94136"]
Since initialjs doesn't provide a way to change these colors using
JavaScript, we're changing them in Ruby, following the same algorithm
used by initialjs.
