The inaccessible web: how we got into this mess
Theoretically, anyone can access the web. In reality, disabled people are excluded.
Compared to other public spaces, the internet provides us with choices for how we consume and interact. We can use various devices, browsers and operating systems; we can change the size and colour of text; we can navigate with a mouse, keyboard, finger or mouthpiece; or we can use a screen reader to convert words to sounds.
Whatever your needs or preferences, there’s almost certainly a way to access the web.
Theoretically.
In reality, the web is a mess. These accessibility options tend to be forgotten or stripped away, even though accessible websites and apps can absolutely still be beautiful, innovative and user-friendly.
This is more than an inconvenience. This is a human rights issue. Disabled people need these options in order to access the web.
Here are my thoughts on how we got into this mess, and what we can do.
1. We can (and do) learn to make websites without learning accessibility
I learned to build web pages by hacking the code and seeing what happened. It was exciting and empowering — but dangerous. We wouldn’t trust an architect who doesn’t know about building regulations, and we shouldn’t hire web professionals to produce inaccessible websites. More broadly, this applies not just to developers and designers but also managers, content producers, bloggers, and anyone else with a role in creating digital products.
Not sure how to create accessible products? I recommend reading the articles at WebAIM or checking out the #a11y hashtag. I’ll post my own resources in the future. Stay tuned on Twitter @MischaAndrews.
After self-learning the basics, I studied computer science and psychology — and still, no mention of accessibility. My initial workplace introduction was superficial and I’ve had to unlearn those misconceptions. And when learning new skills for work, there have been few times when accessibility was mentioned unless I was at a course specifically about accessibility or searching specifically for an accessible solution.
This is a critical, systemic failure. We are creating websites and apps to be accessed, yet treating accessibility like an optional extra.
Digital career paths don’t tend to be regulated, and I don’t think they should be — but there is something missing. Accessibility needs to be embedded in how we learn to make digital products.
Here’s what we can do:
- Teachers: teach accessibility — and mark for it. If you’re not sure how, consider taking a course in web accessibility and passing on that knowledge. Even if you’re not confident enough to brand yourself as an accessibility expert, seek basic knowledge to reduce the likelihood of spreading misguided advice.
- Content producers: don’t assume your publishing platform will handle accessibility for you. It won’t. Systems like WordPress and Drupal that allow you to create accessible sites don’t guarantee your templates or content will be accessible, and automated testing tools cannot pick up everything. If you don’t know where to start, I recommend you watch this three minute video overview of accessibility, read this article on accessibility for content producers, and look through the resources at WebAIM.
- Designers and developers: if you need training, seek it out. If you already have some know-how, share your work and provide details on how you tested and fixed accessibility issues. Don’t feel like you have to include the term ‘accessibility’ in your talk or blog title to justify mentioning it. Choose platforms and libraries that enable you to make and test accessible products, but remember that your choice of tools won’t guarantee accessibility — you always need to test and improve your products.
- Managers: lead by example. Learn about accessibility, make time for it, ask your staff about it, incorporate it into job descriptions and KPIs. Hire accessibility consultants to audit your products, conduct training, and make roadmaps for more inclusive products and environments. Employ disabled staff — and if you think that’s not an option, find out why and fix the problems in your organisation.
2. We’re not held accountable for inaccessible products
What happens if a product isn’t accessible? In most cases the answer is very little or nothing.
In the workplace, your colleagues probably don’t care about accessibility unless it’s specifically their job to do so or if it affects them personally. Once your product is released to its users, there’s no guarantee that accessibility issues will be reported — just as abled users are generally unlikely to submit unsolicited usability complaints.
And even though accessibility is the law (including in the USA, Canada, Australia, UK, New Zealand, and increasingly in Europe), legal action is rare.
This general lack of consequences makes it easy to ignore accessibility in the short-term.
There are exceptions. Maybe you work at an awesome place with great accessibility leadership, or your users don’t let you ignore accessibility.
But even if you can get away with building inaccessible products, you shouldn’t assume you’re not having an affect on people’s lives, or that you’re not losing potential customers, or that your organisation won’t catch on and you’ll need to redevelop or retrofit for accessibility. (That’s when accessibility becomes expensive.)
Almost inevitably, and particularly if you’re in a team of abled developers, the work you do to make the web more accessible will be undervalued. So make a point of it. Help your colleagues understand that accessibility is important and inevitable. Show them how to use assistive technologies to test your products. Invite (and pay) disabled people to take part in user testing. Teach your colleagues, make it personal, wave the legislation about.
Raise the profile of accessibility and we’ll eliminate the accountability problem.
3. Assumptions guide us astray
Here are some of the justifications I’ve heard for avoiding accessibility:
- “Our product is made for big businesses. Disabled people don’t tend to work at those kinds of places.”
- “We have a small user base, and none of them have a disability.”
- “This is only an internal product, so it doesn’t need to be accessible.”
When you combine these perceptions, you start to wonder: where do disabled people work? If not at big businesses, or in small groups, or in your own organisation, then where? If you think the answer is ‘nowhere’, it’s worth considering why it might be difficult to find work when you are assumed not to exist.
But these assumptions are wrong. Roughly one in five people have a disability, and they’re not always obvious. You may have a colleague with a vision impairment (perhaps reading small text is difficult, so your intranet needs to support different text sizes); or a motor impairment (perhaps they don’t have the fine motor control to use a mouse, so forms need to be keyboard accessible); or they might be hard of hearing (so webinars and videos need to be captioned); or have a cognitive impairment (perhaps they’re in the 15 to 20 per cent of the population who have difficulty reading, so written content needs to be simplified).
If you feel you don’t need to cater for people with disabilities, you’re taking part in ableist discrimination. You’re creating environments where disabled people can’t work.
When this is the prevailing attitude among web producers, discrimination (intentional or not) becomes embedded in the structure of the web.
So let’s change our assumptions that prevent people from being able to access the web. Let’s make new assumptions: that our users, present or future, do have disabilities.
4. The legislation doesn’t tell us what to do
Throughout the world, accessibility legislation is ambiguous. In Australia it falls under the Disability Discrimination Act 1992 but the Act doesn’t specify what you need to do from a technological perspective. The Web Content Accessibility Guidelines (WCAG) 2.0 are increasingly being used as a global benchmark, but that benchmark is not always a legal mandate (depending on your country and industry).
But WCAG compliance doesn’t guarantee accessibility. Even if it did, compliance depends on the software and hardware of users — and since software won’t stop changing, neither will the scope for testing.
This ambiguity makes it tough for web managers and executives to make accessibility policies, but this doesn’t mean you shouldn’t do anything. Doing nothing is the worst option, socially and legally. Testing purely for WCAG compliance is not great either (and it won’t necessarily protect you from legal action), but it’s a starting point.
The best option? Make it your policy to develop content and platforms with accessibility as an essential principle. This means keeping yourself and your staff trained, and supporting a culture where accessibility is truly valued. Test your product throughout (and after) development with a wide range of assistive technologies. And as no more than a backup, have a plan in case someone can’t access your product or service. Use the plan then fix the problem at its source.
5. New trends push technology into untested territory
When clients and executives and developers and — anyone, really — talk about digital innovation, do they always mean it? Or is ‘innovation’ also used to mean ‘fashion’?
Most web designers have had a client — or several — who have been unhappy with a website that didn’t pop. These experiences have affected us. A website isn’t valued unless it’s sexy.
While there’s value in aesthetics and good design, fashion is dangerous because it changes rapidly and pushes digital products into unfamiliar, untested territory.
Accessibility and style aren’t mutually exclusive, but following design trends (or even last-minute ideas) without proper consideration and testing will lead to accessibility disasters … not to mention other potential usability problems.
To bring accessibility back into the picture, we need to slow things down. This doesn’t mean you can’t innovate, but it does mean spending more time considering and testing your creations.
- Clients: before you ask for something trendy, ask yourself why you really want it. If you can’t provide a solid case, perhaps you should reconsider. And if you do decide you need that feature or redesign, you should also ask for it to be properly tested, including from an accessibility perspective. (This means you’ll need to pay for the extra work, and wait for it to be done.)
- Designers and developers: practice saying no to undeveloped ideas, or negotiating more time for testing and bug fixes. Firmly communicate with your clients that accessibility is a necessary component that will take time. If you need to, help them understand why a product that looks complete might not be complete. Until the product has been tested on a range of devices, browsers and assistive technologies, it’s not ready to launch.
How do we fix this mess?
While it’s easy to get discouraged, it’s worth noting that making accessible websites isn’t hard and doesn’t take a huge amount of time. But that’s assuming it’s not treated as an afterthought, and that it’s not the responsibility of a single individual within an organisation.
Everyone with a role in making websites, apps or digital content needs to take seriously their responsibility in creating inclusive digital environments. Seek training where you need to. But more importantly, identify the perceptions you need to change: that accessibility is only for accessibility specialists, or that it’s not important, or that no one will notice, or that it’s too much effort, or that it doesn’t matter.
We’ve let ourselves get into this mess, seduced by the rapid pace of technology and fashion. So let’s stop being seduced! Let’s spend time to properly test and polish our digital products. Let’s make the web accessible, like it should have been all along.
Full disclosure: I do not have a disability, so my views cannot reflect what it is like to have a disability in the digital age. I am writing this as a web professional who has been responsible for both accessible and inaccessible websites and who wants to help shape a more inclusive web.
Have I missed something important in this article? Please tell me what you think. If you’d like to read more from me, you may like to follow on Twitter @MischaAndrews.
Edit: I’ve now written a starter guide for front-end developers who are new to accessibility.
Many thanks to Adam Van Winden for the original illustration, and @erabrand for her feedback on a draft of this article. Any errors or insensitivities are mine, not hers — but she has, and continues to, help me understand where my biases lie.
