What is your checklist for making sure your app is accessible?

#discuss #a11y

Top comments (13)

Make sure the app has a high Accessibility Score on Google Lighthouse. This easily points out stuff you may have missed out on like contrast for background and foreground colors and labels for adding an alt label to an image, etc.

They also put out a guide for manually conducting an accessibility review for your site.

Links above are not sponsored by Google 😂

Jeriel Ng • Jun 23 '20

These are awesome. I didn’t know Google had put out these tools. Definitely want to take advantage of Lighthouse for sure!

Jaye Hernandez • Jun 23 '20

Lighthouse actually does more than accessibility - it’s a great measure of overall site performance!

Massimo Artizzu • Jun 23 '20

Just remember that Lighthouse isn't the goal: it's the starting line!

Which means, if you get 100 in the Accessibility report, this does not mean your content is perfectly accessible. But if you have reported issues, start fixing them.

Beez Fedia • Jun 22 '20

Looking forward to reading the responses to this question! One action that I think is often skipped over is usability testing – observing a user interact with your application. Especially when it comes to screen readers, observing someone who is a screen reader user (rather than someone who only uses a screen reader when testing their apps) interact with your app can be really enlightening.

Angelique • Jun 24 '20

In addition to some of the great suggestions already shared, it's worth reiterating that automated tools only take you so far.

Things I try to consider before developing a feature and then again while testing it:

Are there error messages or other page updates that need to be communicated to screen reader users via a live region or other method? (See: developer.mozilla.org/en-US/docs/W...)
Do page interactions (e.g.., opening a hamburger menu, expanding an accordion) include the appropriate ARIA attributes and updates?
Are a anchor elements and button elements used appropriately? Are there places in the markup where divs or spans can be replaced with more meaningful HTML?
Have any heading levels been skipped (e.g., the page has an h2 and an h4 but no h3)?
Are there any autoplay elements (e.g., animation, video) on the page that need pause/play controls to be added?
Are clickable elements (especially buttons) a reasonable size for all users and situations?

There are obviously more considerations, but these are the things I consistently think of when looking at comps and in code review.

Suzanne Aitchison • Jun 22 '20

Can I use all controls/interactive elements with keyboard alone?
Do I have a clean bill of health from axe/wave extensions
Has manual testing been completed using a screen reader (multiple browser/reader pairings)
Is the app performant / consider bundle size and time til interactive

These are a minimum, and I'd expect checks to be happening as individual features are added rather than only happening in a regression test.

Also I'm talking about during/after building, the app idea itself and the design should have already been considering accessibility, ideally with user research including disabled and diverse users.

Elliot Derhay • Jun 23 '20

Good point about making accessibility a priority at the beginning. It's much harder to make a project that's already being built accessible later on if that wasn't being considered at the start.