Let’s Share More Accessibility Experiences

I think the accessibility community has an opportunity (has had an ongoing opportunity) to get its message across to the broader developer community that it hasn’t realized. A couple recent write-ups make me think we should all be trying harder.


Last week Medium shared its experience with working to make its site accessible. The team chose a title that was appropriately humble: Five Goofy Things Medium Did That Break Accessibility

The article outlines six (not five) lessons that the author learned but which aren’t new to those in the accessibility community:

  1. DON’T: “Intercept” clicks by creating a transparent overlay over a control.
  2. DON’T: Use opacity: 0 to hide elements.
  3. DON’T: Create an <a> tag without an href
  4. DON’T: Create a button or link without text.
  5. DON’T: Attach actions to SPAN or DIV tags to listen for user input.
  6. [Use headers and footers.]


A few days later Podio wrote about its own revelations in accessibility: How some hard truths helped us start improving the Podio experience for the visually impaired

In short, a developer met a customer with a visual impairment and realized the overall interface was lacking. He came away with a valuable lesson from the whole thing:

Sometimes you actively decide to leave out a feature, sometimes you forget some details and your implementation has bugs, and sometimes out of pure ignorance you leave your users behind with a really bad user experience

In his story he defines the basics for his readers, from semantic mark-up to screen readers (he is writing about one user, so other assistive technology is understandably absent). For a few readers there is nothing new there, but for so very many developers that is brand new information.

Current Situation

In each case, accessibility-minded people point out where the lessons and efforts fell short. Skipped headings on Medium, too low text contrast on Podio, and many more items. That approach has defined the message from the accessibility community for years — you didn’t go far enough. There are exceptions of course (A11y Wins comes to mind), but it can be intimidating for anyone giving accessibility a go.

Meanwhile, these two developers were ill-prepared to even consider accessibility. I challenge you to find an instructor in a higher education setting who teaches his or her students about accessibility; someone who integrates it into the conceptual skills most developers need or even into the tool-set and language training that developers use to get jobs.

Combine these factors and you have developers who haven’t been exposed to accessibility. For those who become developers without schooling first, there is no easy way to discover accessibility practices and many never even realize that there are practices.

How We Can Reset the Conversation

My version of WebAIM’s Hierarchy for Motivating Accessibility Change (guilt, punish, require, reward, enlighten, inspire — each with increasing effectiveness) puts a star on top labeled Make it about me! I first proposed this model at the HTML5 Developer Conference in March 2014 (see my Selfish Accessibility slides).

The average developer might look at the Medium list and not immediately understand why those are issues. That same developer recognizes the Medium brand and sees that brand’s willingness to acknowledge that it learned by screwing up. The same is true of Podio.

That can be powerful. That can reach developers in a way that the accessibility experts cannot — partly because of the perception that we (I’m a bit uncomfortable using we here) all take the fun out of web development by not letting designers use grey text on white or developers use divs as links.

Perhaps as accessibility advocates we can move away from taking shots at sites that do it completely, utterly wrong (like I continue to do with Virgin America) and instead promote the ones that are making an effort.

Every time we help an organization to learn something new about accessibility and improve its tooling, processes, user interfaces, and so on, we should encourage them to write about it. Help them share those lessons and wins with the broader community.

Think of developers who love to read about what’s going on at their favorite sites as told by other developers — their peers. Imagine if those stories included regular experiences and lessons learned from improving accessibility (often with the follow-on benefits). Consider how many of those could be informed by the time you spent consulting or raising issues on accessibility.

I’d love to see developers brag about some new accessibility feature just as frequently and fervently as they do with some new shiny technology. I’d love to see that from all developers, not just those in the accessibility world.

Let’s all see if we can appeal to the existing desire to share (or just appeal to ego) when we help someone discover an accessibility trick and help them get it in writing. Maybe we can change the nature of the conversation altogether, modifying the tone from negative to positive.

I think that would be pretty swell.

Self-Fulfilling Tweet

Sort of out of context, but it preemptively validated my point…

Update: June 21, 2016

Shopify may not be aware of this post, and may not even care, but it is going and doing exactly what I hoped more companies would do. It is sharing what it is learning, both what it gets right and what it gets wrong. Dave Newton kicked off the series with this:

At Shopify, our mission is to make commerce better for everyone. […]

I hope more companies follow Shopify’s lead.

Update: March 23, 2017

U.S. Digital Services put out an article sharing its own experiences: Mythbuster’s Guide to Accessibility



I was happy to blog about our failures at Safari since I knew it would push us to do better.

Deborah Kaplan; . Permalink
In response to Deborah Kaplan. Reply

The URL for that blog post has changed since this comment was posted, so I have updated the comment to use the current URL.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>