WCAG according to me

Last year at Edge conf in London, Derek Featherstone said:

You can get 80–90% of the way accessible by testing everything with a keyboard and dealing with good, solid semantic markup

And it made me wonder: If it’s that easy, then why doesn’t everybody do it?

Probably because not everybody knows it can be that easy. In every discussion on a11y, short for accessibility, there’s always someone asking “but how much is it gonna cost to make our [app/site] accessible?” This is where the discussion stops most of the time, because everybody thinks it’s going to cost so much time (eg. money) to serve everyone. Exit a11y.

Although I hate it when the discussion gets to this point (it’s people we’re talking about) they’re probably right if they want to go through each and every item on the WCAG 2.0 checklist. So because you’re unable to check the whole list, you’ll also neglect a big part of the list that’s much easier to obtain. Meaning many users who can be easily served will also not be able to get to their goals.

When I created empat.io, my main focus was on showing designers and developers who it is they should be designing and developing for. I hoped this would help them understand what they could to do help everyone. But more than once I got this question: “What should I do? What are the best practices?” I still think empathy is a strong argument and a strong motive to create better work, but if you don’t know what to do it can be very convenient to neglect a whole bunch of users altogether.

I work at an agency that is mainly driven by technology. We build software for anything connected and we build a lot of stuff for the web. I’ve been trying to make a point about paying attention to a11y at the start of every project. By doing so I ran into the same discussion I have with clients: The one about money. So I decided to make it easier for my colleagues to do the very best they can to make everything we create for the web as accessible as possible. I created a list and called it WCAG according to me. Here it comes:

1. Keyboard
   Are users able to navigate your website/app with only a keyboard? Are they able to reach all functionality with the tab key? Is there sufficient feedback to know where they are?
2. Semantics
   Is it clear what the website/app’s is about without styling? Does the hierarchical structure reflect its intentions? Are the most important components at the top?
3. Screenreader
   Have you tested with a screenreader yet? All Macs have a built-in screenreader called ‘VoiceOver’. This can be activated with Command + F5. A tutorial is available directly from the startup screen. Take it, as it can be quite challenging to use if you’ve never worked with a screenreader before.
4. Color
   Have a look at the website/app on an old monitor instead of your crisp and clear Macbook retina screen. Or have a look with our SEE! extension. Play around with the color blind filters. Is everything still readable, does it have enough contrast and are buttons and links still easy to find? 
   To find out what color combinations enable good contrast you can use Lea Verou’s Contrast Ratio.

By working your way through these 4 points, you’ll be able to check off a huge number of items from these other guidelines.

Of course this list doesn’t cover everything about accessibility. For example, the use of video and audio is left out. We’ll address that when it’s relevant to the project. But by doing this, you’ll be able to serve many more people than you probably already do. This could be the start of making it part of your workflow. Hope this helps.

Another tip

Install http://khan.github.io/tota11y/. This will also help a great deal. But these are only mechanical checks. Checks by hand are always better. So use it along with the above list.

Johan Huijkman, Interaction Engineer at Q42