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.
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.
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.
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.
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.
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.
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
altlabel 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 😂
These are awesome. I didn’t know Google had put out these tools. Definitely want to take advantage of Lighthouse for sure!
Lighthouse actually does more than accessibility - it’s a great measure of overall site performance!
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.
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.
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.
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.
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
aanchor elements andbuttonelements used appropriately? Are there places in the markup wheredivs orspans can be replaced with more meaningful HTML?Have any heading levels been skipped (e.g., the page has an
h2and anh4but noh3)?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.
Ensure every image has an alt text that has a descriptive text of the image.
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.
I use The A11y Project checklist and Wave Tool by WebAIM
Install this in Chrome, and then follow along and do everything it tells me to do: accessibilityinsights.io/
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.