My experience trying to ensure accessibility on an earlier blog post.

Be aware this is a draft post — please adjust your expectations accordingly. Get in touch if this post could use an improvement.

Contents

I recently wrote a blog post about my new, potentially permanent Miniflux + Pocket workflow.

I started wondering about how it would treat a “convenience merge” between a kbd HTML element and the list item text. To elucidate, this is when the first letter of the word is also a keyboard shortcut. For example, the key o for the action open.

A screenshot from my draft blog post. The list has 4 items, with the fourth list item holding a further 4 list items in its tree. Everything except the root fourth list item is blurred. The visible and text-in-question reads: "open the first item to start reading." The o is marked up as a kbd element, whereas pen is not. Together they read as open. — A screenshot from my draft blog post. The list has 4 items, with the fourth list item holding a further 4 list items in its tree. Everything except the root fourth list item is blurred.

This prompted me to go down an accessibility testing rabbit hole, especially as Dan DiGangi’s tweet had been lingering in my mental to-do list.

First attempt: Firefox.

My first attempt was to try Firefox. I had asked Dan, too, if there was something I could do on Firefox. He did not have any recommendations.

Second attempt: Chromium on Linux.

ChromeVox is a screen-reader and assist extension by Google. I have never used it before. This experiment ended so quickly with me being unable to select any voice at all!

The voices dropdown in the ChromeVox extension’s settings page features no voices on Chromium on Linux.

Google had already moved Chromium to a snap, and I was hoping it would be treated better, even though I only ever use it for testing for browser compatibility. It does not look like that is the case.

It seems the solution is to compile it yourself. No-go. Most people won’t and can’t do that. This is not OK.

Third attempt: Firefox.

Linked by Dan originally, I opened Mozilla’s support page and went to the screen reader section. They recommended Orca among others.

Open Pop!_Shop, install Orca, restart Firefox.

And….

It’s reading text! Success!

I quickly find out that Orca does not make any differentiation what-so-ever with open, where o is a keyboard shortcut as seen in the original text.

It reads “open” as o, brief pause, pen. That’s it. Not helpful, I guess.

Fourth attempt: boot into Windows and use Chrome.

Since Linux gets the boot, I booted into Windows and installed Chrome as well as ChromeVox.

Here’s my experience with this:

#ChromeVox on Windows works out of the box. Using the kbd element actually broke it! A list with 4 sub items was being read as a list with 2 items, because the first letter in the third sub-item was a kbd element.
Then, while reading text, there was no announce whatsoever about the “o” key being a keyboard input. It would pause, read “o”, announce[/speak] “list item” to say now the list item was being read again in continuation before having taken the pause for “o”.
Ru Singh on Fosstodon, dated 9 July 2021, 10:03 UTC+05:30

Conclusion.

Any time I need to test for basic accessibility, I’ll probably just boot into Windows and use Chrome with ChromeVox. Unsure if this is what people actually use. Let me know if there are any alternatives that are more common and more appropriate, please?

It’s a pretty grim situation, though, for Linux users, as I see it.

Last updated on 26 July 2021. Join the discussion on Mastodon, Twitter, or write me an email.