The Pandemic has changed so much about how we all live our lives. In one one way or another, we’ve all had to adapt to this “new normal”. In reflecting on these adjustments, a major theme for me has been internet access and how we can help expand it.
Living through this Pandemic, we rely on internet services to go to work, go to school, catch up with loved ones, do our shopping, and even go to our doctors’ appointments. Unlike ever before, people with disabilities, people with technical challenges, and people from different cultural/linguistic backgrounds are convening in the digital space, and are relying on web-based services and platforms.
As developers, we have a responsibility, along with designers, to create and optimize interfaces to be inclusive and accessible to everyone.
In learning more about web accessibility and how to implement it, I’ve gone down a bit of a rabbit hole. While I am merely scratching the surface, I decided to put together a list of quick wins that fellow developers can implement in an afternoon, as well as some resources that I found helpful.
Please know that there are plenty of experts on this topic, and whole courses on web accessibility. I don’t want to replace these voices and would highly recommend that you go check them out if you are interested in the subject. If you’re looking for a quick way to make your project more accessible, I hope you find that this article is a good place to start.
Screen readers allow people who are blind or visually impaired to navigate the web. They work by parsing the HTML of a webpage and using text-to-speech technologies. Unlike navigating a page by sight, where users can scan to find the content they are looking for easily, screen readers read linearly. This should be considered when designing a webpage. You can try out a screen reader on your site with NVDA for Windows or VoiceOver for Mac.
- Set the document language: the lang attribute on the tag tells a screen reader what language to read the content in. Here, WebAIM gives a great example of what it sounds like if the defaulted language doesn’t match the language of the content.
- Include alt-text: Including alt-text to images, videos, graphs, and other media allow people using screen readers full-access to content.
- Check for empty links and buttons: Links that don’t contain text mean there’s no context as to what the link goes to, making it very difficult to navigate with a screen reader.
- Use semantically correct input labels on forms: This is another common context problem. For example, having a
tag that says ‘first name’ above an input field my be clear to those visibly navigating a page but difficult for those using screen readers.
<form action="/action_page.js"> <label for="first-name">First Name</label> <input name="first-name"> <input type="submit" value="Submit"> </form>
Many people who are visually impaired still access the web visually. Colorblindness, for example, affects 300 million people worldwide. Epileptic users should also be considered when styling a webpage.
- Check font-size: A small font can be difficult for some users to read. The WCAG guidelines recommend that no text is smaller than 9px.
- Check contrast: Low contrast makes it difficult to impossible to see content for some. As a good rule of thumb design with high contrast between background and text colors. You can use this checker to see if your site’s contrast meets the guidelines. It’s also important that the meaning of an element isn’t conveyed by color alone.
- Watch out for flashing colors: Gif’s videos, animations, etc. can be distracting for many people and dangerous for people with epilepsy. Multimedia that flashes at a rate of 3+ per second should be removed and looping videos should have clear controls to be able to pause. ###Allow for Keyboard Navigation Those with mobility issues may be navigating a site via a keyboard instead of using a mouse or trackpad.
- Set keystrokes for click events: If you are using VSCode and have ESLint installed, you might already know about this one as it will give you a warning in the console. Luckily for developers, many interactive HTML elements like buttons and links are written with default keystrokes. However, events like onClick or hover should be accompanied by a keystroke event like onKeyDown. Here’s an example from one of my own projects.
- The A11y Project | a one-stop-shop for lots of accessibility information
- A11y.coffee | digestible information for developers to learn over a cup of coffee.
- Follow @cariefisher on Twitter
- MDN Accessibility + ARIA pages
- Accessibility evaluations tools like WAVE and tota11y
I hope you enjoyed this article. If you have any comments or suggestions, please email me at email@example.com. I’d love to hear your feedback :)