Accessibility has gained a lot of awareness in the development community. Our tools are getting better to report possible pitfalls, and the topic has become an essential matter for companies promoting inclusion, and preventing lawsuits for discrimination.

One of the reasons for the recent hype for web accessibility among developers comes from Google Chrome's team Lighthouse tool.

Lighthouse is actively promoted on developer conferences. It also became the official Audit tool on Chrome Web Browser. It is getting a lot of traction, mostly because it is straightforward to use and have useful documentation on how to fix several issues in our web projects.

As a result of this, more and more developers are sharing their Lighthouse scores on Twitter and their keynote presentations, with pride:

A practice that I would like to encourage because it shows web developers are aware of and committed to providing fast and reliable web experiences.

There's more to this than meets the eye

Chrome team has made accessibility testing as approachable as possible, which is essential when it's still a new concept to most developers.

Getting a 100 score on accessibility audit may lead to think is the same as to have a 100% accessible site, which may be not true.

Lighthouse accessibility audits are powered by Deque's Axe Core tool. Because they're using Axe as their rules engine, their reviews only return issues that can entirely be determined with automation - no false positives. The result is clear reporting of the most common and most easily fixed accessibility issues.

As Deque puts it:

The downside of the DevTools accessibility audit is that's only half of the story. Your page may have scored a 94 in accessibility according to Lighthouse, but it's only telling you the results of automated testing. You also have to perform manual accessibility testing to really know where you stand.

Lighthouse also makes this recommendation on their "Additional items to manual check" section on the results of the audits.

But since it does not affect the score, developers can be tempted to ignore the recommendations and go with it.

Manual accessibility testing is still a must if we are genuinely committed to delivering an accessible product/experience.

What to do after getting a 100 score on Lighthouse accessibility?

Start your manual accessibility review, open your webpage and start using it with the keyboard. On an excellent keyboarding experience aim to have a logical tab order and easily discernable focus styles.

Continue testing with a screen reader. If you are on an Apple device with Mac or iOS, you can use the built-in screen reader: VoiceOver.

More insights on How to do an Accessibility Review by @robdodson

Try other tools

Consider running audits with other tools, and see what other recommendations you get. Here is a list of other tools you can try:

Bookmarklets

• A11Y.css
• aslint.org
• pa11y
• tota11y — Accessibility Visualization Toolkit

Chrome Extensions

• aXe browser extension
• Accessibility Developer Tools for Chrome
• WAVE Web Accessibility Evaluation Tool
• WCAG Accessibility Audit Developer UI
• SiteImprove Accessibility Checker

Other tools

• Tenon.io (free and paid plans available)

More tools and resources: Accessibility Mindset

Conclusion

As web developers, we need to continue educating and advocating for web accessibility. Automated tools are making the testing very approachable, but this is not an excuse to avoid manual testing. We are in good shape to make accessible web sites the rule, instead of the exception.

If you are getting started on Web Accessibility, please consider reading this introduction:

The Web Accessibility Introduction I Wish I Had

Max Antonucci ・ Oct 23 '18

#a11y #beginners #explainlikeimfive

Thanks for reading! Please suggest any other tools or ideas you've tried yourself in the comments.