Audit Component Accessibility Using Storybook

Render Components with ReactDOM to Write Tests with Jest and jest-axe

Write Unit Tests for Accessibility Using jest-axe and enzyme

Write Better Unit Tests with react-testing-library and jest-axe

Test Accessibility at Runtime with Selenium WebDriver and aXe-Core

Write E2E Tests for Accessibility Using aXe-core and Cypress

Automate Accessibility Audits with GitHub Actions

Audit an App's Rendered Pages Locally with Lighthouse CI CLI

Automate Lighthouse Audits with GitHub Actions

Auditing React Apps for Accessibility 

You’ve probably heard of Lighthouse before as it comes bundled with Chrome DevTools for performing a number of audits on things such as performance, SEO, best practices as well as accessibility. 

We can also use Lighthouse locally on our machines to test our application's rendered pages for accessibility issues before committing changes by using the Lighthouse CI CLI.

## Resources
* https://github.com/GoogleChrome/lighthouse-ci
* https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md

https://app.egghead.io/api/v1/lessons/javascript-audit-an-app-s-rendered-pages-locally-with-lighthouse-ci-cli/subtitles

Instructor: [0:00] To get started, we'll need to install the CI globally with either npm install or yarn add. Now, we'll need to configure Lighthouse. I'm going to create my config file here in the root of my project and name it lighthouserc.json.

[0:15] The format of the configuration file starts with a CI property. Then we're going to add specific options for how it should audit our application, which are defined in the collect property. First, we'll specify an array of URLs we want Lighthouse to audit, which, for now, will just include the login page.

[0:32] Because I'm planning on serving my application locally, I make sure to specify the correct port where my application will be served. If this were a static site, I could instead have Lighthouse serve my application for me using the built static assets.

[0:45] This can be done by providing a static disk dir property pointing to the directory where my static assets are stored. Then we can remove the port from our URLs provided to the URL property because Lighthouse will automatically add the port it ends up using for local server it starts up for you.

[1:02] Since this app is not a static site, we'll go ahead and roll this back to the URL my app will be serving itself. Because I do want my application to serve itself, I'm going to provide Lighthouse with the npm script command it can run to start the server by setting the start server command property.

[1:18] I'm setting it to a script I've added to my package.json file that will make sure my application has been built and then starts my server. In addition to the start server command, I'll also provide Lighthouse with the pattern it should be looking for as output from the server indicating when it's up and running and ready to accept connections.

[1:34] In my case, the server will output accepting connections at http://localhost:5000 once it's ready. Finally, because Lighthouse has a number of different categories of audits it can perform, such as accessibility, SEO, performance, best practices, and PWA, we can specify in the configuration if we want to limit the audits to certain categories only.

[1:56] For our purposes here, we only want to audit for accessibility issues. We can parse that category in as an array to the only categories property of the settings property. To run this, now, all I need to do is enter the command, lhci autorun. We can see that Lighthouse detects my configuration file and is automatically running my server and navigating to the URL I specified.

[2:24] When Lighthouse completes its audits it will output a bunch of results, and they're not super human readable. It does also create this directory in the working directory where it was run that holds a number of files with the results of the audit.

[2:40] Because Lighthouse ran the audit three times on the URL I provided, we have three HTML files for each of those runs. We can open these up to see the results in a nicely formatted report. It gives us an overall score for the accessibility audit that it ran, and it lists the issues it found.

[3:04] You can expand to see what audits passed out of all of the ones that it ran, and any that were not applicable to this test run. It will give you some of the details of the environment that the tests were run in.

Audit an App's Rendered Pages Locally with Lighthouse CI CLI

Share this video with your friends

Resources

Course

Auditing React Apps for Accessibility