Four things you can do right now to prioritize accessibility
January 29, 2020
Accessibility is important. Recently (some organizations)[https://www.axios.com/supreme-court-blind-accessible-websites-dominos-fd0b2a0a-6db9-4b69-a7e8-6de9e3610d26.html] are finding that out the hard way. Whether compelled by love for you fellow human beings or fear of financial ruin, here are some things you can do right now to improve your site's accessibility.
This one is the low hanging fruit of low hanging fruit in this post. You're likely already using eslint. Simply adding eslint-plugin-jsx-a11y will add a lot of checks to keep your code accessible. Consider adding lint-staged to your project to prevent yourself from ever checking in inaccessible code ever again!
Google Lighthouse offers a lot of great insight into the front end of your app, including accessibility. If you're using Chrome it's already built into the dev tools. If you're not, no worries! You can still use lighthouse from the command line with the lighthouse cli. Lighthouse-ci also allows you to run lighthouse reports in your CI environment. (Keeping an eye out for when it becomes available through Netlify Plugins!)
Be careful of styling semantic elements
Learn about the HTML elements available to you and be careful of styling directly on the element. This is one of the things I've been most guilty of. I would style each header to fit the theme (
h1,h2,h3...) and then use the one that LOOKED the best when creating a page. But that's the problem, those elements mean something. Each section should have one and only one
h1. Also, you can't just skip headings. For example, having an
h2, and then an
h3. My solution has been to create heading classes,
.h1, so the style and the markup can be different.
Learn how to navigate with your keyboard and a screen reader
Learn how to use VoiceOver (with Safari) and just a keyboard to navigate your site. Not all issues can be caught by lighthouse and eslint. You'll need to actually navigate around your site to catch issues.