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

Comments

[Jaye Hernandez]

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]

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

[Jaye Hernandez]

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

[Massimo Artizzu]

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]

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.

[Suzanne Aitchison]

• 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]

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.

[Angelique]

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.

[Eugene Ogongo]

Ensure every image has an alt text that has a descriptive text of the image.

[adzika]

I usually refer to those articles:
accessibility checklist
dev article about accessibility tips
most common accessibility issues

Also, I'm using a screen-reader and keyboard on the page myself to check if it works.

[Manuel Ricci]

I use The A11y Project checklist and Wave Tool by WebAIM

[Alex 👨🏻‍💻]

Install this in Chrome, and then follow along and do everything it tells me to do: accessibilityinsights.io/

[Felipe Spengler]

2024 suggestion

I know this is old but to anyone finding this in 2024, I recommend WebAIM WCAG Checklist, as they always keep it updated.