The five types of people who produce inaccessible code

Last week, my friend Eric Bailey wrote an article on the five types of people who produce inaccessible code.

In spot number one, you’ve got what I’d like to believe are a majority of the folks who create inaccessible work:

People who create inaccessible code, but do not realize they are doing so.

I’ve unfortunately run into far more of the people in spot number three than I’d like to:

People who create inaccessible code, and do not care about fixing it.

My cohosts when I was on the JS Jabber podcast were among them, and it’s a big part of why I quit the show.

But person number five has been me more often that I’d like…

People who create inaccessible code that our industry thinks is accessible, but experientially is not.

A good example of this is using the details and summary elements to create dropdowns, like GitHub does.

So, why are those elements OK for accordions but not dropdowns? In a word, semantics.

The way the elements are announced in all combinations conveys “click this thing to learn more.” It doesn’t inherently imply, “click this thing to see more navigation items,” which can lead to confusion for some users.

Eric also shares a secret trick for getting accessibility right, but you’ll have to go read his article to find out what it is!