How to make the Internet available for everyone — accessibility in the web development
The Internet is a really awesome place. Everyone can find something interesting for them here — and people who share their passion. But what about people who cannot use computers the same way as us? Blind or visually impaired people, people with motion or cognitive problems — they all have to struggle every day with tasks that are super simple for people without any disabilities. And our responsibility as developers is to create the world accessible for everyone. Recently, I spent a lot of time learning and thinking about many different aspects connected with accessibility in web development. In this article, I want to share some of my thoughts and advices with you — hope it will help make our world a place where everyone feels welcomed!
Step into the user’s shoes
Why accessibility is so a difficult and non-popular topic among developers? I strongly believe it’s not because of bad will — most of us just don’t know how important it is for our users and we do not fully understand the problems they face on a daily basis. To be honest, I also had a big problem with that — theoretically I knew basic stuff about accessibility but was not using that at all. Cause it was just a waste of time, isn’t it? I read some articles about the topic but they did not convince me. Also, nobody around me did it… It’s why I want to propose to you some experiments that helped me realized why accessibility is not just a “nice to have” feature but one of the most important things to consider during programming. They were really eye-opening for me — believe they can help you too.
Invisible exhibition
A few years ago I visited the Invisible exhibition in Warsaw (https://niewidzialna.pl/en). It’s a special place where you can feel like a blind person — you come into total darkness and have to perform normal, daily tasks like preparing the meal in the kitchen. But you know what? Even if I am performing them pretty well for many years, doing them without sight was extremely difficult (not to mention I had a small panic attack when lights went out). Sense of touch, hearing, smell — all of them without vision were completely different. Moreover, the guides on the tour are blind or visually impaired people — and listening to their experiences made me think about many cases I never imagine before. I was super lucky to be guided by a visually impaired person who is also a developer — and when we started talking about some computer-connected stuff he opened to me a completely new perspective. Have you ever seen how using screen readers, in reality, looks like? I was shocked by how fast the content is read! If you haven’t seen it yet, just take a look at the video below:
Surprising, don’t you think? I strongly recommend you checking the Invisible Exhibition (I know that similar initiatives exist e.g. in Prague and Budapest) or at least start a screen reader on your laptop. Struggling with the daily problems of users will certainly make it easier to remember about accessibility in your application.
Emulate vision deficiencies
The experiment described above is the most eye-opening but I know that visiting that exhibition may be difficult. Especially, in pandemic times. It’s why I want to propose you also experiment you can conduct without getting up from the coach. Did you know that color blindness affects approximately 1 in 12 men and 1 in 200 women in the world? (source: https://www.colourblindawareness.org/colour-blindness) And most of them is not seeing the world in black-white mode but can’t see e.g. some of the colors. Can you imagine your Facebook wall without colors? Or Pinterest collection? Now, you don’t have to try your imagination but just use tools to see it with your eyes. You will just need DevTools in your Chrome browser.
What to do?
- Open the Chrome DevTools Panel (ctrl + shift + I on Linux/Windows or cmd + shift + I on Mac)
- Click 3 dots on the right side
- Choose
Rendering - Find dropdown titled “Emulate vision deficiencies”
- Choose one of the options from the menu
What is important you can perform that experiment on any webpage via Chrome browser. Try some of your favorite web pages in that mode. Can you still understand the whole content? Is everything readable? Or maybe labels without your beautiful color palette look the same as the background?
Disconnect your mouse from the computer
Can a discharged mouse have something to do with accessibility? Surprisingly, yes! Many users with motor disabilities or using screen readers have to rely on keyboard navigation. Is your webpage fully support that? Where is the focus when you dismiss/delete items? Or when you open/close modal? Can you easily use arrows to iterate over dropdown or slider? Can you access all actionable elements on the page? How many clicks do you need to access more nested content (can you skip to the main content)?
So many questions — and probably you can add some additional to that list. Test your page against them (paying close attention to your custom elements). Keyboard navigation is not as easy as you think!
Accessibility audits
The experiments described above are really eye-opening but to be honest they don’t give us any tips nor data on what is OK and what should be improved on our webpage. And many developers (especially tech newbies) tell me they know the basics, they feel accessibility is important but they don’t know where to start. This is where automatic audits may help.
Lighthouse in Chrome DevTools
The easiest way to perform an accessibility audit on your webpage is just to use a tool already built-in into Chrome browser — Chrome DevTools. Just:
- use ctrl + shift + I on Linux/Windows or cmd + shift + I on Mac to open the panel,
- go to the
Lighthousetab, - tick
Accessibilitycheckbox, - decide which version (desktop or mobile) you want to test,
- click the
Generate Raportbutton.
After some seconds you will receive the report (like in the picture below) with the most important data.
OK, so what have we got here? First of all, our webpage is scored on a scale of 1–100. A score below 50 is considered bad, 51–89 medium and 90–100 is the score we want to achieve. But the number is not all. The most important thing in that audit is the list of failing audits — visible just below the main score. When you click on one of the audits and expend details, you will receive much more data — e.g. a link to an article where you can learn more about a given problem and a list of failing elements. What’s more — when you click on the failing element you will be redirected to it in the Source tab where you can find more info about the element and where you can play with its CSS or attributes. Definitely worth checking!
Personally, I strongly recommend checking not only the section with failed audits but also the passed ones — thanks to that you can learn what is important and improve your skills.
Axe DevTools
Using Chrome DevTools is the easiest way to start but unfortunately, it can’t find all problems on the page. So, when you need more detailed info it’s worth using some more advanced solution — like Axe (https://www.deque.com/axe/). To use the free version of the tool you can open the link (https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US ) and add the plugin to your browser. After that, you will see a new tab called axe DevToolsin your Chrome DevTools panel.
The free version without login allows us only to scan all of your page but it is enough for most of the cases. As you can see it found much more problems than Lighthouse and gave me more context on them. All findings have links to gather more info, automatically assigned impact, and links to failing elements. You can even click the highlight option to check where exactly the failing element on your webpage is. Each issue contains also a section informing you what needs to be done to fix it. Trust me or not, it’s an extremely useful option.
Note
Automatic audits are really nice feature and they make our work much easier. However, we have to remember that not everything can be tested that way. Remember that things like keyboard navigation can be only partially tested by a computer, and regularly perform manual accessibility tests too.
The most popular mistakes
Ok, we know a little about how to understand the users and how to automatically find issues on the page, so let’s talk more about mistakes. Can’t hide — accessibility is so huge topic I cannot fit everything in one article. But there some super popular mistakes that can be easily fixed. Below you can find my subjective list of the most important problems and ways to fix them.
Incorrect DOM structure
Have you ever created your own beautiful widget (like dropdown) based on styled divs and spans? Or used CSS to create some visual title instead of using the h1 tag? Let’s be honest — we all were doing stuff like that. But there is a catch. Even if your custom solution is super beautiful, a screen reader may not understand it properly. So using proper HTML tags is super important. However, you don’t have to give up all your custom elements. Assign them correct roles using an role attribute. Add interactive elements tabIndex=0 to ensure they can be focused. If your element contains more specific logic test it against keyboard navigation — add arrow navigation for your banners, lists, or dropdowns (you can find more info about it e.g. here: https://webaim.org/techniques/keyboard/). Check if all your titles and subsections are written in proper h1-h5 tags. Thanks to that structure of your webpage will be clear also for people who cannot see its content and navigate through it will be much easier.
Missing/Broken keyboard navigation
If we are talking about navigations — when was the last time you checked keyboard navigation on your website? I wrote about it in the experiments section but will repeat myself — just disconnect your mouse and check. It really can surprise you! The riskiest places are custom components (where you should manually support for e.g. arrows or enter), buttons without support for pressing keys, and modals or places where you remove/add something (double-check if the focus is not lost while interacting with them). Also, it’s a good practice to add a link at the beginning of your site to skip all navigation items (e.g. from the top navigation menu) and go directly to the main content. Remember, keyboard navigation is used not only by screen readers users, so displaying some visual tips (like marking focused areas) is also a good option.
Missing accessible labels and alternative texts on images
Sometimes it’s hard to understand something without additional information. It’s why we have footnotes in books or cards with item descriptions in museums. The same story may occur on your site — especially if we remove their visual part. Add alternative text to your images by using a alt tag for images or correct title in SVG elements. Thanks to that also people using screen readers will know what is in the picture. When the image is only decorative leave those tags empty or add aria-hidden=true— screen readers will understand and omit that. Also, check if without visual content all interactive elements are still well-labeled— tags like aria-label, aria-labelledby, aria-description or aria-describedby might be super useful in that case.
Not sufficient color contrast ratio
Do you remember an experiment with emulating vision deficiencies? You may have discovered through it that some texts become unreadable when we do not see the page in its original colors. In most cases, it is connected with an insufficient color contrast ratio between text and the background. Fortunately, those issues are quite easy to detect by automated tools. In the audits section, I presented how that error may look like in Chrome DevTools and Axe reports. But that’s not all — as developers, we have also support in fixing that issue. When you open Chrome DevTools and inspect the given element toolbar with details of it will be presented. And as it’s visible on the picture it may show us an orange warning icon close to the Contrast category. It means the contrast color ratio between text on that element and its background is not sufficient.
When you take a look at the Styles tab of that element you can do even more. Click on the square color preview on the left side of the color property value to open the color picker. Below the color value input, you may see an expendable section with contrast ratio information. The red icon close to the ratio informs us that we should take a look at that values. And reload button allows Chrome to automatically propose the new color — which will have a correct contrast ratio and as close to ours as possible. Nice way to fix that issue, don’t you think?
Of course, the list of the accessibility issues and problems is not exhaustive — but the things I listed are a good start to make your webpage accessible. If you want to learn more check https://www.w3.org/WAI/ or https://webaim.org webpages.
How to avoid accessibility problems in the future?
When you understand why it’s so important, know how to perform audits, and are aware of the most common mistakes, you may ask what to do to avoid those problems in the future. We have to remember that taking care of accessibility is not a one-time action but the whole process — each change on your website may have an impact on it. It’s why I strongly recommend adding some steps to your development process.
Code reviews
The second pair of eyes is always useful. You may be tired, don’t know something, or just miss some spots. Also in the accessibility area. Ask your teammates to take care of the accessibility part during code reviews. Add this step to your template checklist if you are using them. That small change can bring a really big impact.
Add accessibility plugins to your code
Have you heard about eslint-plugin-jsx-a11y plugin? It’s a fast way to make your life easier. Just install it and add it to your package.json file and .eslintrc configuration. The plugin will check the most popular accessibility rules (and your own if you define them) and highlight problems directly in your code editor. More about the tool and its configuration you can read here: https://www.npmjs.com/package/eslint-plugin-jsx-a11y.
Jest-axe unit tests
If we can unit test our components to be sure they work and display as expected, why don’t we unit test them against accessibility problems? Yes, it’s possible. One of the packages you can use is jest-axe. The unit test for accessibility may look like the snippet below (taken from jest-axe readme file). Of course, you can also set a list of your rules to include/exclude both globally and just for the given test.
const React = require('react')
const { render } = require('react-dom')
const App = require('./app')
const { axe, toHaveNoViolations } = require('jest-axe')
expect.extend(toHaveNoViolations)
it('should demonstrate this matcher`s usage with react', async () => {
render(<App/>, document.body)
const results = await axe(document.body)
expect(results).toHaveNoViolations()
})You can find more examples and information about the tool on its GitHub page: https://github.com/nickcolley/jest-axe
Regular audits
Even the best automatization cannot fully replace manual audits — remember to perform them regularly. Involve people with different disabilities into them if possible. Remember to test not only the happy path but also more complicated scenarios. Recall the experiments from the beginning of my article — could you call your page `accessible` having them in mind?
Summary
This article is a result of the long time I spend learning, experimenting, and thinking about accessibility. I hope it helped you better understand the problem and gave tools to make our web world more inclusive for everyone. If you find that interesting or useful clap the button below or share the link with your friends. Happy coding!