Today we released @HashiCorp #Nomad v0.12.2 which includes a new scaling events timeline. I wanted to talk about some of the small #a11y details that went into its design and implementation.
✨ thread ✨
✨ thread ✨
Line charts are designed for visual consumption, but that doesn't mean we can't provide some screen reader support. Plus a11y covers more than just sight.
The thesis here will be that making accessible interfaces isn't typically hard work but it takes paying constant attention.
The thesis here will be that making accessible interfaces isn't typically hard work but it takes paying constant attention.
To start, consider the ticks on the axes of a line chart. These are SVG text elements which will be read by a screen reader by default. Since the line itself won't be read out loud, the ticks are reference material without the context. The fix here is to make the axes hidden.
But simply hiding the chart isn't so good. It has useful information! We started adding programmatic descriptions of the range and domain of the data using SVG title and description elements combined with aria-labelledby and aria-describedby.
That covers the basics of a line chart pretty well, but the scaling events timeline also has annotations. How can we make those accessible?
First, we can Use The Platform™. Instead of using SVG shapes with click events we use HTML buttons. This gets us things like tabbing and keyboard activation with enter and space keys. HTML is more limited than SVG in many ways, but horizontal positioning can be done just fine.
Note that annotations are just positioned icons. We can visually derive meaning from the iconography and position as it relates to the labeled x-axis, but this isn't helpful for screen readers. The title for the button needs to include the event type and x value.
Another subtle issue with annotations is order. Annotations are naturally ordered visually based on their x-value, but that doesn't necessarily mean they are ordered in the DOM.
Again, this is an easy fix but it's also easy to overlook. We also sort annotations from right-to-left for timeseries charts. Why? Because if the same information was presented as a list, you'd expect the most recent events to be shown first.
The last detail has to do with click area. There are two components to this.
First, annotations left to their own devices can overlap. Overlapping annotations mean a reduced surface area for the bottom annotation. We use a common trick here and stagger annotations.
First, annotations left to their own devices can overlap. Overlapping annotations mean a reduced surface area for the bottom annotation. We use a common trick here and stagger annotations.
Second, WCAG Target Size requires a truly large clickable area. So large it may mess with your visual design, causing things to have more visual weight than you wanted. Targets don't have to be visible! My favorite use is here where the target area is 3x the visual height.
This might seem less like a11y and more like general UX but that's kind of the point. A11y *is* general UX. This feature is just as useful if you're able-bodied using a laptop trackpad in your lap or if you have reduced motor function.
There you have it! A bunch of little details, none of which were particularly tricky to implement, that add up to a much more inclusive experience even for a feature that is very visual.
Thank you for coming to my thread talk 🙇♂️
Thank you for coming to my thread talk 🙇♂️
