Why is accessibility so important?
When we’re writing code, who do we write that code for? Ourselves? Other developers? Future employers? No. We write code to build websites for other people, which means that we write code for our users.
So why would we build websites that 20% of our users can’t use or view as we intended them to? We’re doing that when we don’t code with accessibility in mind. You’re building your website for every user who comes through your page, whether visually impaired, colour blind, dyslexic, or dealing with a small child who wants attention.
A lot of the web isn’t accessible to those with accessibility requirements, which is about 20% of the world’s population. Let’s start by thinking that through from a commercial standpoint. Imagine you have 1000 users who buy your product from your website, which costs £10. Ignoring costs that all businesses have, that’s £10,000. Fantastic! Now take away 20% because your site isn’t accessible. Suddenly, you’ve lost £2000! That’s only for a relatively small company. Now consider companies that have millions of users. That’s a lot of money!
Accessibility & Ethics
Now let’s look at the ethical side of web development. When you build a website, you’re proud of what you’ve made. You want as many people as possible to experience the joy that you do when they visit your site. Now think of how frustrating it can be for assistive technology users. They see your site on a search engine and think, ‘That sounds cool!’ before clicking on your site. If they’re a screen reader user, maybe you haven’t used alt text, and they don’t know what any of your images are. If they’re a switch user, perhaps you haven’t considered focus states, and they don’t know where their cursor is. That user will leave your site, having been discriminated against due to their disability.
Equality Act of 2010
Let me repeat that. The user will have been discriminated against due to their disability. Since the Equality Act of 2010, there has been an accessibility requirement for all websites to be accessible to all users to adhere to the law. Our users don’t choose whether they have accessibility requirements or not, and it’s our responsibility as developers to ensure we are building an accessible web for everyone to enjoy. Your site should always aim to comply with Level AA of the latest version of the Web Content Accessibility Guidelines(WCAG). The laws regarding web accessibility may be different in your country, but we also have to consider which country our users are in.
Disabilities can be temporary, like a broken limb or a cat sitting on your keyboard, or permanent, like motor skills or visual impairment. While assistive technology is progressing rapidly to aid these users, there is work that we, as developers, need to do to ensure that these technologies can access our sites easily. For example, screen readers can help those with visual impairments, keyboard-only navigation, and switches for those with motor skills impairments. So how can we design our sites for these users?
A brief look into Assistive Technologies
So let’s look at which assistive technologies are available to users and how they work. Unfortunately, many developers simply aren’t aware of assistive technologies beyond screen readers, which results in other assistive technology users being forgotten about on the accessible web.
While most of us know what a screen reader is, let’s start there. A screen reader is like an interactive audiobook for a website. It will read through the elements and the text (often at a fast pace) for blind or visually impaired users. Screen readers are available for free and are often pre-installed with your operating system (Windows, Mac, Linux), so there’s no reason not to switch it on, work out how to use it, and hear your site as a screen reader user would.
Adaptive Switch
The next assistive technology we’ll look at is known as an adaptive switch. A switch is used by users with motor skills impairments, such as those with paralysis, quadriplegia, or other disabilities that reduce the use of the limbs. These are large buttons, with their purpose set by the user. Often, a user will set one switch button to the Tab key and one switch button to the Enter key. These are positioned where the user has the most mobility – usually on a headrest or armrest. If they have more switches, they can get more functionality, but switches are incredibly expensive, often at £50 or more for just one button. You can test how your site would function to a switch user by simply pressing the Tab key to tab through your webpage.
Head Pointers
Next, let’s look at head pointers. This technology is often available for free, either as downloadable software or pre-installed on your operating system. This allows you to operate your mouse using the motion of your head, tracked using a webcam, and using facial expressions such as smiling or sticking your tongue out to perform actions like clicking. Unfortunately, head pointers are incredibly difficult to use and often take a while to learn how to use accurately.
Other assistive technologies include the following:
- Braille displays are similar to screen readers but ‘print’ out the text on your site onto a braille pad for a visually impaired user to read.
- Screen magnifiers are used by users with visual impairments. This technology is often found for free on your browser.
- On-screen keyboard emulators are used by users with motor skills impairments, where a physical keyboard may be too small or badly arranged for them to use easily.
- Mouth sticks are often used by users suffering from paraplegia or quadriplegia, where they have difficulty or are unable to move their limbs in a way that would allow them to use the web.
All of these types of assistive technologies need to be considered when you’re building a website.
What are the best accessibility tools during development?
Let’s take a look at some accessibility-related web tools which can show you how someone with an accessibility requirement would view your website.
Lighthouse
First, we have the trusty Lighthouse. Made by Google, this gives you an immediate snapshot of the basic accessibility level on your site. If you code with accessibility in mind, you’ll easily find yourself in the high 80s to 90s, without having to do much extra. Then it’s hardly any work to get a perfect score. Although, whilst to you, it’s just a small amount of work, to a user with accessibility requirements, it’s the key for them being able to use your site.
Accessibility DOM
Next is the ability to view the accessibility DOM. This is an easy way to see what a screen reader would read out and to understand how your semantic HTML is being used on the page. Sadly this is only available on Chrome Dev Tools currently, but hopefully, this will get taken on by other browsers soon.
Spectrum
Then we have Spectrum. This Chrome extension enables you to view your site as someone with one of the seven different types of colour blindness would see your site.
Web Disability Simulator
The Web Disability Simulator Chrome extension allows you to view your site the way someone with accessibility requirements would see your site. So you can choose dyslexia, and the letters move the font changes, and it’s incredibly disorienting. You can choose Parkinson’s and see how infuriating those tiny tap targets really are. You can even choose concentration, which simulates the web for those with ADHD or Autism. Do take some of these simulations with a pinch of salt – some of them aren’t able to show you exactly what it’s like to view the web with a disability, so they make a simulation of the closest that they can render.
WAVE
Next is WebAIM’s WAVE, which works the same way that the W3C HTML validator does, but for accessibility. You enter your website URL, and it returns the accessibility errors and features, allowing you to view on your site exactly where those errors occur and giving you helpful notes on how to fix them.
On the topic of WebAIM, this is their Colour Contrast Checker. This is my go-to for checking colour contrast because it gives you a pass or a fail based on the use case. This means that if you’re using some colours for large text, the contrast might pass, whilst the same colours might fail for normal-sized text.
Automatic Readability Checker
For readability level checking, this Automatic Readability Checker from Readability Formulas is the best that I’ve found. It’s very simple, just copy and paste your text in, and it will give your a variety of scores based on different levels. The levels are explained at the bottom, but using the Automated Readability Index (ARI) is normally best, in which you want a score of 3 or 4.
Pa11y
Finally, if you want some automated accessibility tests in your terminal, or in your CI build pipelines, try out Pa11y. You can use the basic Pa11y in the terminal (the first link) to see accessibility failures as you go, or you can link it with your build pipelines with Pa11y CI (the last link) to ensure that your builds fail if your code fails any of the accessibility checks. This has the added bonus that no code reaches your site that isn’t fully accessible. The only thing I’ve found that Pa11y doesn’t test for is readability level.
Abigail Harrison, Code Institute Student
A11y Accessibility Series
This article was written by Abigail Harrison, a Code Institute student. This is the first in a series of articles on the subject where Abigail covers the following topics.
Try our Free 5 Day Coding Challenge 
Take our full stack course 
