First off, the title of this post is obviously link bait. I don’t seriously believe this to be a real “issue.” But if you’ve not read my last post, it might be worth reading for some context, I’ve found an answer as to why I was having issues using VoiceOver. And I thought I’d share.
What I didn’t divulge last post was I was primarily trying to use VoiceOver with my work. Again, as I alluded in my previous post, I’m talking about VoiceOver on OSX. For sometime I’ve been very casually building what I refer to as “an orderly, semantic mark-up centric, un-styled and accessible WordPress starter theme” — for which, as of this writing, it’s technically none of the above. But I’ve named it bA53.
My goals with this personal project are many. But most importantly I’m using this opportunity to push myself to learn about a few different aspects of web development, specifically. Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA), how Screen Readers actually interact with what I build and actively using Git/ Github in my workflow to my advantage — I’m the master of the tiny commits and the much too frequent push’s.
Frankly it’s been frustrating, humbling and fruitful few months. Long story short, today I figured out, with some help from a colleague, why VoiceOver would stall on my code.
My issue
The problem was VoiceOver would start to read a page just fine. But whenever it came across a list, it would read the first list item, then stop. And if I started it again, by pressing the VoiceOver Keys (Control + Option) + A it would continue from where it left off but it would stop yet again after reading right after the next list item it would encounter. Why?
It didn’t make any sense. My Hyper Text Mark-up Language (HTML) (the content a Screen Reader interacts with) was valid, even if it was a bit “verbose,” with the extra WAI-ARIA code I had added (and I’m still testing my work), but given this it wasn’t that far out of line with other sites where VoiceOver works without a hiccup on.
Not what I expected
So after writing a simple, yet separate HTML document, we were able to track the issue down. Turns out lists, or list items, weren’t the problem. Linked text inside of those list items were. And not how you’d expect either. It wasn’t how the linked text was written in the HTML. Rather it was strangely how the links were styled via Cascading Style Sheets (CSS).
Now I’m not convinced this is anything more than a bug. I had applied a display: inline-block; to the :focus states of links within my template. I mistakenly applied it to the :focus state exclusively thinking it was applied to all links in any state. Oops.
But it gets stranger. If I apply display: inline-block; to the all-encommpassing a element and leave it in the :focus state style block, VoiceOver still functions as it should. And how one might expect. It’s only when I remove the generic a‘s display: inline-block; rule and leave it alone on the :focus style block does VoiceOver gets hung up.
Why does it matter?
Honestly, I’m not sure it really does. But the point regarding why this is an interesting quirk, theoretically speaking at least (leave it me to find this), is with said rule applied to the :focus state of a link, for whatever reason VoiceOver will stop reading anything after it’s finished reading that styled text link.
After all whatever VoiceOver is interacting with on a webpage (for the record I’m talking about Safari here, the colleague I mentioned above said something about Firefox now having VoiceOver support, but that’s a whole other issue for another day) it has focus. And apparently the display: inline-block; rule has sway over how VoiceOver behaves in this instance.
Curious.
Addendum
As you’ll see just below, Patrick left an inquisitive query regarding if VoiceOver on iOS suffered the same fate. So I built a demo simply titled Focus Bug, with the hope to test real quick and have an answer (since it took so long to get around to build). Silly me, I should know better.
It’s never as easy as you wish anything to be. Long story… well… less long, it’s my honour to report, the same thing happens in VoiceOver on iOS.
Even more curious.
Interesting post.. Be curious to know if you experienced the same issue with iOS & VoiceOver
Equally as interesting. And thank you. I’ve thought about that previously, just after posting this article, in fact. Which I’ve not had an opportunity to test yet. But I plan to.