Clueless, but looking to up your game on accessibility. Starting on a new project and wanting to make sure you keep accessibility in mind from the start? Or working on improving the accessibility on an existing codebase but not sure where to start? Well here’s some tips for you.
\nIf you’re generally wondering what web accessibility is, or why it is important, here are some great articles to start with:
\nHere are some helpful tips I’ve learned from a few years of work on web accessibility in React.
\nTwo key user groups that benefit from accessibility work are screen reader and keyboard users. Until you start navigating pages using the keyboard and a screen reader, you will be clueless to many accessibility challenges your site presents. Even without a deep knowledge of WCAG guidelines, you’ll be able to spot many common accessibility issues just by experiencing the frustrations and confusions of navigating an inaccessible page or feature with a screen reader and keyboard. Identify the issue, then delve into the WCAG guidelines to find the solution.
\nThe concept of Atomic design is especially helpful when considering accessibility. Solving accessibility issues as close to the atomic level as possible means that those issues are resolved in one place for all nested instances.
\nEvery time you work on a UI component, seek out the WCAG guidelines for the kind of pattern you’re working with (is it a group of radio buttons / checkboxes, a list, a modal?). Read up on the guidelines for it, familiarize yourself with the specific requirements and implement them.
\nIf you’re starting a totally fresh project and want it to be as accessible as possible, utilize a third party design system. The UI frameworks below not only supply beautifully styled primitives, but they also have their accessibility needs abstracted and accounted for.
\nIf you’re invested in an in-house design system, consider utilizing packages like react-aria or react-native-aria which can supply the accessibility minded HTML attributes and behaviors you need in your custom components.
Maybe you learned plain old HTML at your bootcamp or in some intro course in computer science. Or maybe (like me), you learned it editing your GeoCities blog and MySpace page. Maybe you’ve moved away from using all those plain old HTML tags like button, a, li, etc. when your wizardry with CSS-in-JS and synthetic events can make a div look and behave like anything. Plus you have to purge all that the ugly, outdated user-agent styling of plain HTML anyways…
Well, screen readers have no idea what those complicated divs your React components are actually rendering down to. A tremendous amount of helpful information is provided “for free” just by using semantic HTML.
MDN has a great article that talks more about this.
\nSeek out an accessibility test library for your test solutions. For us, currently unit testing with React Testing Library and Jest, we found jest-axe perfect for our use case.
It is said only 30% of accessibility issues can be caught with unit testing. But even catching 30% of issues, either newly introduced or regressions, with unit tests has been extremely helpful.
\nSome quick sub-tips from our experience working with jest-axe:
wrap your test call in a helper function to allow more centralized, repeatable control over it, like:
\nexpect not to be testing the accessibility of an error screenjest-axe doesn’t catch, like adding an aria-* attribute, write a test for to find that attribute to ensure that work never disappears!When you identify accessibility issues, capture screenshots or gifs of the sub-optimal screen reader / keyboard experience. Then after you fix it, capture the improved “after” experience. It’s really helpful to communicating to other product stakeholders who may not be as familiar with assistive technologies the benefits of accessibility work to see these two experiences side-by-side.
\nAccessibility and WCAG requirements are indeed labyrinth, complicated topics affecting a wide range of users and technologies. Ensuring that a sizeable codebase is accessible to the highest level is not a task suited to someone just entering the subject area. Operating a business with an inaccessible website is not just an ethical issue either, but a legal one in many countries.
\nMany organizations offer auditing, subject area expertise, and legal services with regard to web accessibility. Here at Knack, we have paired with Allyant to help get our product to the highest level of accessibility possible. Their highly trained experts in the accessibility field have helped us identify and remediate challenges to our users. Their knowledge articles on common patterns, issues and guidelines have also been invaluable resources to us on this journey.
\n