One of the things I’m trying to do in my work this year is to get better at accessibility. I’d like to make it more visible and help people make it part of their workflow, especially as part of a bigger Inclusive Design approach. Here’s why accessibility is important to me.
Removing barriers
When we don’t make our sites accessible we are excluding people from using our products (and services) when we don’t need to. An equation that we use to define disability in our CTFEDs GAAD workshop (Global Accessibility Awareness Day), from the very excellent A Web for Everyone, is:
Ability (functional capability) + Barrier (created by product) = Disability (conflict between Ability and Barrier)
A person’s barrier to access is created by the product, not by them. If we change the way that our products are built, we can remove that barrier.
It’s not just about the edges
We could think that disability is just about people at the extremes. It’s more complicated than that, though: disability is a continuum. If we take vision as an example, we could talk about:
- blind users;
- users with low vision or poor eyesight;
- users with color blindness;
- users outside of a sunny day trying to use the shiny screen of their phone, or using an old monitor with low contrast and dodgy colors.
For these users, the barriers could be when we provide information:
- only in images (a problem for blind users);
- only in colour (a problem for colour blind users);
- in colours with low contrast (a problem for users with poor vision or on poor screens).
We can remove these barriers by making sure our images have alt
text, that we communicate with more than colour (with additional text, or by adding or removing a border), or by choosing colors that have higher contrast.
Better for everyone
Designing and developing for users with accessibility in mind helps more than just the users at the edges. Adding alt
text for images helps blind users, but it also helps users on spotty network connections when an image doesn’t load.
The Microsoft Inclusive Design toolkit suggests three classifications for disability that I really dig: permanent, temporary, situational. A person might be in one or several of these categories, depending on their situation.
The WCAG (Web Content Accessibility) Guidelines suggests a POUR framework: Perceivable, Operable, Understandable, Robust. These are great guidelines for building software for any group of users! Considering users with disabilities when using this framework results in a stronger product that’s better for all our users.
Inclusive Design
One way to do these things is to change how we design and develop a bit. Inclusive Design is a great way of getting this done. We’re not designing for the lowest common denominator: we’re looking at the toughest tests of our product and making it work there, knowing that it will work elsewhere too.
It’s the same kind of logic as having User Experience Personas representing your most extremes users: design for the edges and it will work in the middle.
Here are some resources on accessibility and Inclusive Design that I’m going to be go through again to try and make myself a better designer and developer, and to find things to add to our next run of the CTFEDs GAAD workshop:
- A Web for Everyone (book) by Sarah Horton & Whitney Quesenbery;
- Dos and don'ts on designing for accessibility on the gov.uk accessibility blog;
- Apps For All: Coding Accessible Web Applications and Inclusive Design Patterns - books by Heydon Pickering;
- The Case for Inclusive Design, which talks about the Microsoft Inclusive Design Toolkit.