Fixing all the things

If you didn't already know, your CSS can influence screen readers. One of the most surprising things to me was learning that VoiceOver removes list semantics from uls and ols when list-style-type: none is applied to them.

Turns out, this is actually intended behavior:

This [not announcing a list for a groups of links when list-style is set to none] was a purposeful change due to rampant "list"-itis by web developers…Basically, if you remove all default visible indication of the list, there is no indication to a sighted user or screen reader user that the content is a list…

—James Craig, Webkit Bugzilla

This is one of those interesting things that may seem wrong to developers that apparently was annoying accessible technology users. James goes on to say the easiest way to fix this is to explicitly define a list role on the list:

<ul role="list">
    <!-- list content here -->
</ul>

Unfortunately, as Scott O'Hara reminds us in his fantastic write up on this issue, the first rule of ARIA is to not use it when there are existing HTML elements that already have the needed role. Scott mentions a nice CSS-only fix put forth by Gerard Cohen and retweeted by Sara Soueidan:

.list li {
    list-style-type: none; /* remove bullets */
}

.list li::before {
    content: "\200B"; /* add zero-width space */
}

I think my biggest takeaway from Scott's article, though, is that "bugs" like this may be best left alone:

While this behavior can be unwelcome in some situations, let’s also not spend too much effort over correcting an over correction which was in response to an over use of unnecessary semantics.

VoiceOver users are used to the quirks that the technology presents. Forcing a consistent experience may end up making things worse. Just like everything else in web development, you need to test with real people.

When I began my journey of learning about accessibility, I enthusiastically "fixed" everything I could find in my code, usually over-complicating markup and making things worse for people. More often than not, it pays to keep it simple.

If you'd like to hear more about how I've overcomplicated things in the past, check out this letter to my younger self, or you can just ask me on Twitter about all the hot garbage code I've been known to write. Maybe you can learn from my (many) past mistakes.