♿️ Getting Started with Web Accessibility
Accessibility is essential to ensure everyone can effectively use and enjoy web experiences. If you've never focused on accessibility as a developer, it is easier than it may seem!
Ideally we want to our sites to appeal to many users, accessibility plays an integral role in making sure everyone can use and enjoy our websites. The initial steps to taking a journey to making your websites and the future of the internet more accessible are easier than it may seem. I will try and give some quick and easy starting points and tools to get you rolling. Let's make websites for everyone!
Immerse Yourself
Take a moment and put yourself in other people's shoes. Think about those with different abilities might experience. Here's some simple starting points:
- Keyboard Only - Misplace your mouse and use only your keyboard to navigate through a site. Note any sections you are unable to reach or are difficult.
- Screen Reader - Turn off your screen (or down your brightness) and experience a site using a screen reader only. Note any visual experiences that might be completely missing in an audio format.
- Touch Screen - Use touchscreen inputs such as an iPad to experience a site. Note buttons that may be hard to click due to size.
- Alternate Colors - Use a colorblind simulator to view a site such as this tool. Note where text might be hard to read or visuals may be hard to locate.
Let's Dig Deeper
With a bit more understanding under your belt, it's time to dig a bit deeper. Let's go a bit deeper on accessibility topics. Take notice that many times making a site accessible for some improves the experience for all.
Semantic HTML
Semantic HTML can be a great starting point to getting your website more accessible. In a frontend world filled with component libraries and heavy styling, sometimes the focus on plain HTML gets lost.
Also, this has the added benefit of generally improving Search Engine Optimization (SEO) since that has a similar mechanic of screen readers of a machine interpreting your site.
Managing Unseen Text
Many times we focus on the visual text we see. For screen readers, ideally the text would be the same but sometimes may differ to provide more context. If you're curious on what to accessible names and descriptions might look like, W3 provides this handy guide:
A simple recommendation can be to take an approach similar to internationalization to make locale files for managing both the seen and unseen text. Keeping the text paired beyond the component can help highlight the experience. As a bonus, this can be extremely useful for international sites to ensure your site is accessible in a global sense. Read our post on i18next for a hand with this.
Components & Patterns
If you're writing your own components in a tool like React, Vue or Angular, sometimes just seeing some patterns can help highlight what to look for. W3 has a list of patterns including some examples of common components like switches, buttons and tab bars. This can be helpful even if you're using a component library, but be sure to check the accessibility built into your libraries.
Learning More
There is always more to learn so be constantly exploring. There are many fun and friendly resources including great courses and tutorials. If you want to dive in quickly, here are 3 resources for courses and tutorials.
Course by Rian Rietveld
How do I Check?
Now you have a bit more experience and understanding, let's provide some tools for you to start checking accessibility on your site. This is a quick list of tools to help you to check your site for accessibility allowing you to find spots to improve on. Many of these can be worked into CI and automated to ensure all contributors keep to the same accessible patterns.
Automation does not replace manually checking your site to ensure it's usability for your users. Be sure to do both.
Axe
Axe by Dequeue is the underpinning of many of the other tools on this list. It's the base of many popular accessibility automation checks.
Accessibility Insights
Accessibility Insights from Microsoft leans on axe-core from Axe. There are both Edge and Chrome browser plugins and CI tool available.
microsoftLighthouse
Lighthouse from Google is most people's first stop on their accessibility journey. The accessibility part of the tool utilizes axe-core. Installation of the browser tool is simple with a Chrome plugin. There is also a CI tool available.
GoogleChromePa11y
Pa11y is the main alternative that doesn't rely on Axe. Useful since most tools seem to rely on Axe for any automation.
What's Next?
Let this only be the start of your accessibility journey. I hope this helps open your mind to alternate ways your site(s) may be interacted with. If you have questions, we can help over here at IRT to improve your site's accessibility. Keep looking out for future posts on this topic. I'll leave you with this video series, A11ycasts to dive into to help continue your journey.