Introduction
I first learned about accessibility from a senior engineer when I was looking for a new role as a Junior software engineer. He told me that while more and more companies are interested in accessibility, not many people have hands-on experience let alone learn about it themselves, so adding it to my skill set would make me stand out.
As this story implies, accessibility is currently considered as a "nice-to-have skill" rather than compulsory. Recent research that evaluated 1 million websites shows that an average of 50 errors per page was detected and 96.3% of homepages failed to meet WCAG 2 standards. But the more I learn about it, the stronger I came to feel that accessibility is an essential process that every software development should include in its life cycle.
In this article, I will share how I learned and improved the accessibility of my project within just two days without prior knowledge.
Day 1: Learn about accessibility
Just like learning new languages and frameworks, accessibility requires some research and learning. So I dedicated one day to learning about the background and methods of accessibility.
Understand the background
The goals here are to:
- Understand why accessibility is important.
- Understand how people with disabilities are experiencing inaccessible websites/apps.
To achieve this, I used different resources:
- Videos on Youtube (e.g., Accessible Web Design: What Is It & How To Do It)
- Podcast (e.g., Javascript Jabber 362: Accessibility with Chris DeMars)
- Blog article (e.g.,Despite efforts, businesses struggle with accessibility)
Keeping the goals in mind, I watched/read/listened to these materials just to get an overview and extract necessary information.
While it's ultimately up to you, I wouldn't recommend using WCAG 2.1 document just yet as the volume might be overwhelming and it can easily put you off if you are still new to this area.
Below are the examples of what I learned from this learning:
- There are many types of disabilities(e.g.,visual impairment, deafness and hearing loss, limited movement, speech disabilities, photosensitivity).
- Disability can be temporal (e.g., weakened eyesight with ageing or sudden injury).
- Disability is situational (= certain bodily and cognitive characters become "disability" due to the environment surrounding them).
- There are three different accessibility levels: AAA(highest level), AA(a level that most development teams should be aiming to meet) and A.
- Currently, the UK law asks companies to make a "reasonable adjustment" to make their website/applications accessible to people with disabilities (Section 20 and 29 of Equality Act 2010).
- There are different views towards accessibility (time constraints? cost? good branding? moral responsibility?)
- Accessible website = SEO friendly
Understand the accessibility level of our website/application
After learning about the context of accessibility, I checked my current personal project to see how accessible it is. First I generated a Lighthouse report.
Lighthouse is an amazing open-source Google Chrome tool that helps us improve the quality of our website/application. To use it, you access the page you want to test in your Chrome browser and find Lighthouse in the Dev tool. After selecting the accessibility option and running the audit, you will see a report that shows the accessibility level of the page and the issues that should be addressed to improve accessibility.
In my application, for example, I got a warning about the lack of names for some buttons.
And then, I navigated the deployed website with assistive technologies to gain a better understanding of how my application would be experienced by people with disabilities.
- Keyboard (Tab key to move up and down)
- Screen reader (For those with visual impairment. As a Mac user, I used Voice over.)
- Sim Daltonism (For colour blindness.)
Sim Daltonism is an amazing tool. You can use the tool just like a filter through which you can see screens through the eyes of people with colour blindness.
As you can see, the text "Log in" inside the red circle is almost invisible due to poor colour contrast. This is only noticeable because I am using Sim Daltonism's filter here.
Learn the solutions and make your Accessible checklist
I learned about potential audiences I could reach out to by improving accessibility and accessibility concerns of my current application. So in this third step, I focused on learning how to solve these problems.
Learn from real-world examples of accessibility
Just as I did in my first step, I used Youtube videos and articles to educate myself. In this process, I spent more time learning from real-world front-end development examples. I highly recommend reading what Octopus Energy has been doing on its website and application for its users. This company is very serious about accessibility and has actively documented its accessibility journey to make accessibility implementable for developers like you and me!
Iterate your accessible checklist
To facilitate the future process, I made a checklist and added accessibility coding techniques I learned from videos and articles to it. Every website and application has different UI and functions, so it is important to make a customised list that suits your project.
If you want to make it more comprehensive, WCAG quick reference should give you a thorough list of points to cover.
Day 2: Apply accessibility to your project
On my second day, I applied all my learnings to my current project.
Use tools as your guide
I already touched Lighthouse earlier and I used the tool again to test the accessibility of every page in my application. All I needed to do is to read the report and make adjustments such as adding attributes and tabIndex={0} to make UI readable by screen reader and accessible by keyboard and fixing semantic HTML.
While Lighthouse undoubtedly facilitates web accessibility, it is not a panacea. For example, the image below shows the accessibility rate of the page is 100%. But as we looked at earlier, the colour contrast of this page is inaccessible to people with colour blindness.
Other useful tools
To compensate for Lighthouse reports, I used several other materials and conducted manual testing. Here I share some websites and browser extensions that I found useful to improve the accessibility of my web application.
Colour contrast
To achieve AAA-level colour contrast, I used the following websites:
WebAIM is a contrast checker where we can add two colours in the inputs to see their contrast ratio and how well the ratio meets accessibility standards.
Accessible Colour Contrast, on the other hand, shows you options for accessible colour combinations. You can filter the options depending on which accessibility level you are aiming at. Using this website, I chose the primary and secondary colours of my application.
Let's have a look at my landing page which used to be very inaccessible. In the image with Sim Daltonism's filter below, we can clearly see the "Log in" text. This is a good example of how much difference we can make by just changing the colour contrast.
HTML Outline
Messy or flat HTML structures confuse screen readers and hinder them from navigating websites/applications efficiently.
If you are a Google Chrome user, the following extensions surely help you find out whether the elements are properly organised.
Example: how my application changed after accessibility improvements
After the implementation, I found my web application fully functioning with keyboard navigation. Screen reader now clearly tells what users can expect from each element. There is no keyboard trap and colour contrasts are all AAA level.
Below shows how this implementation changed my application visually.
Before(sign up page):
After(sign up page):
Before(modal):
After(modal):
The landing page now looks a bit empty, but this is just the first iteration. Accessible websites and applications don't need to be boring.
But I was personally surprised to learn how quickly I could achieve this level of accessibility. And I'm sure it will only become easier as I experience more.
Conclusion
Ultimately, as Ashley Firth suggests in Practical Web Inclusion and Accessibility, accessibility should be a collaborative effort if we are part of collaborative projects. This means even if we are passionate about accessibility and include it in the code we write, if others are not on board, your websites/applications stay largely inaccessible to people with disabilities.
But it does not mean we have to wait until our boss asks us to start learning it. If we believe it's the right thing to do, we should keep learning it, improving our skills and sharing our experience with our colleagues.
To stay involved in web accessibility, we could either:
- Find like-minded people to start a new project with accessibility practices.
- Become an advocate to drive accessibility implementation in our organisations.
- Join a company which has been already committed to accessibility.
Thanks for reading!
Please let me know your web accessibility experience and the tools you use to improve the accessibility of your websites and applications.
Top comments (2)
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍
Wow! Thank you for choosing my post!
It's very encouraging.