Improve Accessibility

[niklas-wortmann]

So it looks pretty good that we are adding swirly to the rxjs docs. I didn't think about that before but we aim to have high standards for accessibility. I stumbled across this article describing what to do for accessibility for SVGs. Even though it is not perfect, it would be cool for us if there would be a configuration option for those properties.

What do you think of that?

[timdp]

Years ago, I actually spent quite a bit of time on a11y for a Flash-based SVG renderer. It was quite the ordeal, and the poor quality of screen readers in particular was surprising.

That said, I'm happy to take a stab at it. Not sure what attributes to add where though. Could you link to the article you mentioned? Some best practices and examples would definitely be helpful.

[niklas-wortmann]

Lol sorry here it is https://css-tricks.com/accessible-svgs/

[timdp]

Thanks. That case study about a graph is definitely helpful.

Now, before I start adding metadata blindly (no pun intended), I was thinking I'd take a diagram SVG, annotate it, and see how the Jaws screen reader behaves. Of course, it'd be even better to get input from someone who's actually using a screen reader, but I'm not getting my hopes up.

Some initial thoughts:

• Swirly already uses SVG groups (<g> elements) heavily, which should help.
• I think a (first-order) stream could be role="list" and the messages inside role="listitem".
• Swirly lets you name streams, so that could be their label. The default for unnamed streams could be the generic "stream".
• Marble labels can obviously be the label on the marble, maybe prefixed with "Event: " or so.
• Similarly, operator labels could be "Operator: [name]". It won't work for complex names containing ASCII art, but it's a start.
• Screen readers don't like hierarchies, so we'll need a way to flatten higher-order observables. This is probably the trickiest part. The approach can be incremental though.
• With a little luck, we won't need too many role="presentation" attributes to bypass the screen reader. If we do, that's going to bloat the SVG output. In that case, I'd make the feature opt-in; otherwise, it can just be force-enabled, since it's unobtrusive.

[timdp]

@roelvangils I know this is your expertise. If you feel like weighing in at all, that'd be awesome.

[roelvangils]

I’ll have a look on Monday ;)

[timdp]

I implemented some of this on the a11y branch but it's completely untested. :bomb:

[niklas-wortmann]

I contaced an a11y expert too. That's pretty much his recommendation:

. Some of the things that need to happen: Add role="img" to the

• Add the
• Add a unique id on the
• Add an aria-labelledby referencing the title’s id in the
• The title would in effect be the alt text for the image. If a longer description is required, you’d do good to add as well. You’d need to use a unique id on the desc element, and add it to the value of the aria-labelledby

[timdp]

Yeah, those are definitely relevant as well, but they're about the outer SVG element. You could even argue that Swirly doesn't even need to produce them, because the party who's embedding the image could easily add them themselves. Of course, it'd be more convenient if Swirly did everything.