For further actions, you may consider blocking this person and/or reporting abuse
Read next
AI Tools That Can Make Your Life as a Web Developer SO Much Easier 😊!
Kudzai Murimi -
The Best Resources for Learning Golang
Harutyun Mardirossian -
The REM to PX relation: how to write more accessible media queries
Riley McMaster -
10 IT traditions and superstitions: from mischievous gremlins to a cactus on the desk
ispmanager.com -
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 😂
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
a
anchor elements andbutton
elements used appropriately? Are there places in the markup wherediv
s orspan
s can be replaced with more meaningful HTML?Have any heading levels been skipped (e.g., the page has an
h2
and anh4
but 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.