Fast, easy and reliable testing for anything that runs in a browser.

cypress

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

“a11y” stands for “accessibility.” It is a numeronym, with 11 representing the count of letters between the letter a and the letter y.

Accessibility is broken down into 4 categories of disability: visual, cognitive, auditory, motor. 

Regardless of the category of disability, accessibilities aim in web development is to make applications and websites usable for everyone.

a11y

GitHub fosters a fast, flexible, and collaborative development process that lets you work on your own or with others.

github

Web accessibility (also referred to as a11y) is the design and creation of websites that can be used by everyone. Accessibility support is necessary to allow assistive technology to interpret web pages.

React fully supports building accessible websites, often by using standard HTML techniques.

Erin Doyle is an expert in creating accessible React applications and has developed a course that will give you a concrete process for auditing react apps for accessibility. In this course, you will go through different tools and libraries to audit components in a React app.

Building a component library is a great way to gain efficiencies in creating accessible React apps and Storybook is a great tool for doing that. Using the accessibility add-on to Storybook you can test your components in isolation for accessibility issues before composing them into an application.

If you can write and test each of these components initially with accessibility in mind then you now have:

* A library of reusable components with accessibility baked in.
* You won’t need to solve the same problems over and over again.

## Resources
* https://storybook.js.org/
* https://www.npmjs.com/package/@storybook/addon-a11y

Audit Component Accessibility Using Storybook

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing.
* The flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app.
* A safety net for any accessibility regressions.

Here we'll see how to use `jest-axe` with `ReactDOM` to render components for `jest-axe` to audit for accessibility.

## Resources
* https://github.com/nickcolley/jest-axe

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

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing.
* The flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app.
* A safety net for any accessibility regressions.

Here we'll see how to use `jest-axe` with `enzyme` to render the components for `jest-axe` to audit for accessibility.

Enzyme is a JavaScript Testing utility for React that makes it easier to test your React Components' output. You can also manipulate, traverse, and in some ways simulate runtime given the output.

## Resources
* jest-axe: https://github.com/nickcolley/jest-axe
* enzyme: https://enzymejs.github.io/enzyme

Write Unit Tests for Accessibility Using jest-axe and enzyme

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing
* the flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app
* A safety net for any accessibility regressions

Here we'll see how to use `jest-axe` with `react-testing-library` to render the components for `jest-axe` to audit for accessibility.

The React Testing Library is a very light-weight solution for testing React components. It provides light utility functions on top of react-dom and react-dom/test-utils, in a way that encourages better testing practices.

## Resources
* jest-axe: https://github.com/nickcolley/jest-axe
* react-testing-library: https://testing-library.com/docs/react-testing-library/intro/

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

To audit our app for accessibility issues at runtime we can use Selenium WebDriver to run our application in a browser environment and then with the aid of the aXe-core `webdriverjs` library we can analyze the current page for any accessibility issues.

## Resources
* https://www.selenium.dev/documentation/getting_started/installing_browser_drivers/
* https://github.com/dequelabs/axe-core-npm/blob/develop/packages/webdriverjs/README.md 

javascript

Test Accessibility at Runtime with Selenium WebDriver and aXe-Core

To audit our app for accessibility issues at runtime we can use Cypress to run our application in a browser environment and then with the aid of the axe-core `cypress-axe` library we can analyze the current page for any accessibility issues.

## Resources
* https://www.cypress.io/
* https://github.com/component-driven/cypress-axe
* https://mochajs.org/#bdd
* https://www.chaijs.com/guide/styles/

Write E2E Tests for Accessibility Using aXe-core and Cypress

We can leverage GitHub Actions to automate the running of all of our accessibility auditing tools as part of a Continuous Integration (CI) workflow. 

Auditing tools will only catch a percentage of potential accessibility issues, it is no replacement for manual testing.  But being able to automate the auditing will add efficiencies to our testing and provide an early warning system that can be run much more frequently than it’s practical to perform manual testing.  Additionally, we can use our CI suite as a safety net to prevent code changes that break accessibility from being able to be merged.

## Resources
* https://app.egghead.io/lessons/react-set-up-eslint-to-audit-accessibility-issues-in-react
* https://docs.cypress.io/guides/continuous-integration/github-actions#Basic-Setup
* https://github.com/cypress-io/github-action

eslint

Automate Accessibility Audits with GitHub Actions

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

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

To automate running Lighthouse audits on our application we can add the use of the Lighthouse CI tool to our Continuous Integration suite using GitHub Actions.  By making use of the Lighthouse CI GitHub App we can add to the checks in every Pull Request a report with the score from the audit run on each URL we configure for Lighthouse to audit.

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

Automate Lighthouse Audits with GitHub Actions

Auditing React Apps for Accessibility 

https://app.egghead.io/api/v1/lessons/react-audit-component-accessibility-using-storybook/subtitles

Instructor: [0:00] To install the Storybook add-on, we'll need to npm install or yarn add the npm package to our development dependencies. Then, to enable the add-on, we'll need to add it to our Storybook config in the main.js file within the .storybook directory. You'll just need to add it to this array of add-ons.

[0:26] Now, let's see the add-on in action in our Storybook. Here's a story I've written with an example form. We've got some form inputs and some buttons. Over here, in the add-ons panel, we now have a tab here for accessibility. We click on that and it's already run tests on this Story.

[0:48] We've got two violations here. We can expand them to learn more about them. Each violation will list what the test criteria was, how that test criteria was violated, and it'll list each element that violates the test criteria.

[1:07] For this one, we've just got this one button. Down here, we have an input and a text area that are violating this test. If you click to Highlight the Results, it'll highlight in the Story, the actual element that is violating the test. For each of the elements that violate the test, it lists more details about exactly how it was violated, and suggestions on how to fix.

[1:41] Finally, there are links to more info, which takes you to Deque University, and gives you a plethora of details about this issue.

[1:53] Let's fix these errors and come back and test again, and see what our results look like. We had two violations. If we refresh this, the tests are run again. We no longer have any violations.

https://app.egghead.io/api/v1/lessons/react-audit-component-accessibility-using-storybook/transcript

https://app.egghead.io/api/v1/lessons/react-render-components-with-reactdom-to-write-tests-with-jest-and-jest-axe/subtitles

Instructor: [0:00] To get started with jest-axe, we'll need to npm install or yarn add it to our development dependencies. Now that that's installed, let's go ahead and write a unit test. Here, I have the beginning of a unit test that I'm going to write for my login page. I'm already importing React. For this unit test, we're going to be using ReactDOM to render the component that we are testing.

[0:26] Here, I'm importing my component that I want to test. What we'll need to do is we'll need to import axe and the toHaveNoViolations function from jest-axe. Now that we've imported those functions, we're going to extend Jest's expect() function with the toHaveNoViolations() function, so that we can use it as an expectation.

[0:51] Since we're using ReactDOM to render the component that we want to test, I'm going to go ahead and create a div that I can render my login page component into. I'm going to use ReactDOM to render my login page component. My login component takes a history prop. We're going to stub that out with a Jest mock function, and we're going to have that rendered into the div I created above.

[1:19] We can go ahead and test this component to make sure it has no accessibility violations. We do that by passing the axe function the element we want to test. We're passing it that login page div that I created that's containing the login page component that I want to test for accessibility. We can write an expectation on this Results object that we got back from the axe function to verify that there were no violations.

[1:45] Let's run this test and see it in action. I'm going to run my test suite by running npm run test. There, you can see it picked up my login test, and here are our results. We can see here that we have one failure. Because axe was able to scan the entire component that was passed to it and all children within that component, there could be multiple violations found from this one test.

[2:09] In our results, we see each element that had a violation is listed. We've got an input here that had a violation. We see what the violation was. We've got a number of suggestions on how to fix that issue. Here's a link to more information about it, and then here's another element that had the same issue. Continue scrolling, and here is a third issue.

[2:35] Let's see how it looks if I go fix all of these violations and run it again. I've made some changes to my code. Let's run this test again and see what we get. There we go, it ran my login test again, and it passed.

https://app.egghead.io/api/v1/lessons/react-render-components-with-reactdom-to-write-tests-with-jest-and-jest-axe/transcript

https://app.egghead.io/api/v1/lessons/react-write-unit-tests-for-accessibility-using-jest-axe-and-enzyme/subtitles

Instructor: [0:00] To get started using Jest-aXe with Enzyme, we'll need to either, npm install or yarn add jest-axe, enzyme, and the Enzyme adapter for whichever version of React you're using -- I'm using React 16 -- and save those to your development dependencies.

[0:20] Now that those are installed, we'll need to configure Enzyme to work with Jest. You'll need to create a setup file, if you don't have one already. Here, I'm adding a setup test file in my source directory. In that file, we'll need to import configure from Enzyme, and we'll need to import the adapter that we just installed. We're going to pass a new instance of that adapter into the configure function.

[0:47] Now that we have our setup test file created, this will automatically run before our test suite. Now we can go ahead and write our unit test. Here, I've got the beginning of a unit test for my Login page component. What we'll need to do is, we'll need to import the mount function from Enzyme. That'll allow us to render the component we want to test.

[1:06] Then we'll need to import aXe, and to have no violations from jest-axe. We're already importing the Login page component that we're going to be testing for accessibility. Next, we'll need to extend Jest's expect function with jest-axe's, to have no violations. That's what we'll use to actually verify that the component that we're testing doesn't have any accessibility violations.

[1:31] Let's write this test. We'll need to pass the component we want to test, our Login page, to Enzyme's mount component. Then, we'll need to get the DOM node from our mounted Login page, and pass that to aXe, which will scan our component for any accessibility violations.

[1:49] Let's run this test and see what we get. We run our test suite with the command, npm run test. You see it finds our login test, and here, we can see that it failed. Scrolling up, here we can see the results we got, and output some very thorough details on which elements violated accessibility. I'm going to go ahead and fix all these findings, and then we can run it again and see what we get.

[2:11] Now that I've made those changes, let's go ahead and run this test again and see what it looks like. This time it passed.

https://app.egghead.io/api/v1/lessons/react-write-unit-tests-for-accessibility-using-jest-axe-and-enzyme/transcript

https://app.egghead.io/api/v1/lessons/react-write-better-unit-tests-with-react-testing-library-and-jest-axe/subtitles

Instructor: [0:00] To get started using jest-axe with React Testing Library, you'll first need to npm install or yarn add jest-axe, and if you haven't already, React Testing Library, and save it to your development dependencies.

[0:16] Now that that's installed, let's go ahead and write a unit test. Here, I have the scaffolding for a unit test already started. What we'll need to add is, we'll need to import render from React Testing Library. We'll also need to import aXe, and to have no violations from jest-axe. We're already importing the LoginPage component that we want to test for accessibility.

[0:44] The next thing we need to do, is we need to extend Jest's expect function to use jest-axe's, to have no violations, so that we can use it in our expectations. Now, let's write our test. We use React Testing Library's render function to render the component we want to test. We need to pass the container into the aXe function. It will scan that component for any accessibility violations.

[1:11] Finally, we'll use the toHaveNoViolations expectation on that results object, to make sure that there were no accessibility violations found.

[1:20] Let's go ahead and run this test and see what it looks like. We run our test suite by running npm run test. You can see, it finds our login unit test. Here, it's logged our results. We can see that one of our tests failed. Here's what that looks like.

[1:34] Let's fix these issues. We can run it again and see what we get. Now that I think I fixed all of my issues, let me run my test again and see what I get. Here, we can see that this time the test passed.

https://app.egghead.io/api/v1/lessons/react-write-better-unit-tests-with-react-testing-library-and-jest-axe/transcript

https://app.egghead.io/api/v1/lessons/javascript-test-accessibility-at-runtime-with-selenium-webdriver-and-axe-core/subtitles

Instructor: [0:00] To audit our app for accessibility issues at runtime, we can use Selenium WebDriver to run our application in a browser environment. Then, with the aid of the @axe-core/webdriverjs library, we can analyze the current page for any accessibility issues.

[0:14] To get started, we'll need to npm install selenium-webdriver and @axe-core/webdriverjs. We'll save that to our development dependencies. Through WebDriver, Selenium supports all major browsers on the market, such as Chromium, Firefox, IE, Opera, and Safari.

[0:33] Before you can get started using WebDriver, you'll need to install the necessary driver executables for which browsers you wish to test with. Then, you'll need to add these to your systems path. You can find the browser drivers to download here. I'm going to install the Chromium driver, for now. I'll need to find the version that I have installed on my machine.

[0:59] Now that that's downloaded, I'll need to place the executable in a directory of my choosing.

[1:12] Now, you'll need to add it to your system PATH. You'll need to open up your shell config file and add the location of where you downloaded your driver executable to the PATH variable. Here's my shell config. Here, I'm adding the location of where I put that executable to my PATH. Now that that's done, we can go ahead and start writing our tests.

[1:34] Selenium WebDriver is run via script, so we'll need to create a new script file. To start, we'll need to require Selenium WebDriver and aXe WebDriverJS. Since I installed the driver for Chrome, we'll go ahead and build the Chrome WebDriver instance. Now, we'll have the driver navigate to the page we want to test.

[2:04] Here, we're going to test our login page. The driver will return a promise. The promise will resolve once the page is finished loading in the browser. Now, we can call the aXeBuilder we imported from the aXe WebDriverJS library. It requires we pass it the WebDriver instance we created above.

[2:20] Then we can call the analyze() function, which will audit the login page against the aXe-Core rule set. The analyze() function is asynchronous and can either be passed a callback function, where it will provide the results as an argument, or it can be treated as a promise where the results will be passed when it resolves.

[2:37] All we're doing for now is just logging out the Results object so we can see what it looks like. To run the script, we'll need to run it with Node. Here's the WebDriver opening Chrome and navigating to the login page at the URL we provided. After aXe WebDriverJS finishes analyzing the page, it will resolve the promise with the Results object. Here's the Results object logged to the console as we specified in the script.

[3:01] The first property in the Results object is the inapplicable items. These were all of the rules that were found not to apply to the current page. There will likely be a lot of these. Keep scrolling, and eventually, you'll get to the incomplete items, which presumably would include any rules whose checks weren't able to be completed. For our case, there weren't any.

[3:19] Then there's this passes property listing all of the rules that did apply to the page and passed. Then, further down, you'll get to the test engine, test environment, test runner, timestamp, tool options and the URL being tested.

[3:39] Then finally is the violations property containing any rules that the page violated. Each violation lists the description and the detail about the rule, a URL where more information is available about this rule, the idea of the rule, how severe the violation impacts accessibility, and references to the exact nodes and tags of the source that violate the rule.

[4:01] Since these results are simply being output using console.log, we only see array rather than a more useful representation of the value. Now that we've seen what the Results object looks like, in logging the entire object to the console may not be the most useful format possible. We can use that to make our own report that shows us just the information that we care about in maybe a nicer format.

[4:22] Here's an example of a report using the Results object. Here, we're just pulling out the test environment, the timestamp that we ran the test and just the violations. We can add a nice header to our report. We can iterate over the violations, grabbing the impact of the issue, the details of the issue, the URL where we can find more information.

[4:45] We can iterate over that Node object, which if you recall, when we logged it to the console, all we saw was array. Now, we can dig into that and show the exact HTML of the elements that are violating the rule along with a summary of what we can do to fix the issue.

[5:02] Let's try running the script again and see what our report looks like now. Here's that header for our report, and here's the list of all of our violations, showing the severity, the description of the issue, the URL where we can go get more information, and the details of the element with the violation.

https://app.egghead.io/api/v1/lessons/javascript-test-accessibility-at-runtime-with-selenium-webdriver-and-axe-core/transcript

https://app.egghead.io/api/v1/lessons/a11y-write-e2e-tests-for-accessibility-using-axe-core-and-cypress/subtitles

Instructor: [0:00] To get started using Cypress to automate testing your application for accessibility issues at runtime, you'll need to yarn add or npm install cypress and the cypress-axe plugin to your development dependencies.

[0:19] You'll also want to add a script command to your package.json file for opening the Cypress app. When you run the command to open Cypress for the first time, it will automatically open in a new browser window, and upon running, will install some directory scaffolding with some example files into your project.

[0:39] To set up the cypress-axe plugin, you'll need to open up the index.js file that was just created by the Cypress app, which you'll find located in the Cypress support directory in your project. All we'll need to do is import the cypress-axe plugin. Now Cypress will have access to additional commands related to checking for accessibility violations.

[0:58] Let's write a sample test. Note that Cypress tests are written using Mocha and Chai with additional commands provided by Cypress and any of its plugins. We'll start by adding a beforeEach, which will run before our test. In here, we will tell Cypress to navigate to the page we want to test. We'll be testing our login page for this example.

[1:17] Then we'll add the command to inject axe. This injects the axe-core runtime into the page, so it will be available to use in our test. Now, we need to add our test to make sure our page doesn't have any accessibility violations. We do that by calling the checka11y command provided by the Cypress axe plugin.

[1:37] Now that our test is written, we're ready to run it. We'll go back to the Cypress test runner, which is still open from when we ran the open command earlier. Here, we see that Cypress has already detected the test file that we just created. A quick note that I can select which browser I want to run my tests in here, and I'm going to go with Chrome.

[1:56] All we have left to do to run it is to just click on this link for our test file. Here, we can see where Cypress navigated to the URL we gave it, and it loaded our login page. Here are the results of our accessibility test. We can see that it detected four accessibility violations on the page. By clicking on an issue, it will highlight the elements on the page that have that violation.

[2:24] Additionally, if we open up the dev console, more details about the violation will be printed here. We've got the description of the issue. We've got the severity of the impact. We've got a URL where we can go find more information about the issue and how we can fix it. Expanding this Nodes array will list out each of the elements on the page that have this violation.

[2:48] This test only checked the initial render of our page for accessibility issues. We can also automate an interaction on our page in order to test for violations as the state of the UI changes. Here's a test that will click on the login button on the login page and should trigger the form validation to display errors on the required fields that are missing values.

[3:10] Let's see what the results of this test look like. We can see after this new test is run that the login button has been pressed, and the error messages for each field are showing. Here's that test.

[3:28] We still have four accessibility violations. We now have seven nodes that have the color contrast violation, whereas before, before the login button was pressed, we only had five nodes, which we can see when we hover over the violation. We can see that now our new error messages are also violating the color contrast rule.

[3:50] Once again, if we open up our console and look at the details printed there, we can expand this Nodes array and confirm that our error messages are now included in the list of elements that have this violation.

https://app.egghead.io/api/v1/lessons/a11y-write-e2e-tests-for-accessibility-using-axe-core-and-cypress/transcript

https://app.egghead.io/api/v1/lessons/eslint-automate-accessibility-audits-with-github-actions/subtitles

Instructor: [0:00] To leverage GitHub Actions to automate the running of all of our accessibility auditing tools, we'll need to set up a continuous integration workflow. If this is your first GitHub Actions workflow, then you'll need to create a .github directory at the root of your project and, within that, a Workflows directory.

[0:19] Then you'll need to create a YAML file in this new Workflows directory. Since this is our continuous integration Workflow. I'm going to name it ci.yaml. We'll start this Workflow with its name, and we'll specify that it should run on all pushes and PRs submitted to the main branch.

[0:43] The first thing we want to add to the workflow is a job for running ESLint, which, if we've got the JSX accessibility plugin installed, we'll automate checking our static code for potential accessibility issues. We'll specify that this job runs on the latest version of Ubuntu, and we'll give our job a name. Now, we specify the steps that the job needs to take.

[1:04] The first step will be to check out the branch. Then we'll need to install Node on the machine running our job, and we're going to specify that it should install Node version 14. Now, we need to install our npm dependencies. Finally, we can go ahead and run the Lint script, which, as specified in our package.json file, is going to run ESLint.

[1:27] Now, we'll add a job for running the unit tests that we've written using Jest aXe to check our components for accessibility issues. Similar to before, I'm going to specify the machine to run the job on, give the job a name. We'll repeat the same steps of checking out the repo, setting up Node and installing our dependencies. Then, finally, we'll run our test script.

[1:48] Finally, we'll need to add one more job for running our end-to-end tests. The first parts are the same as before. We'll specify the machine. We'll give it a name. We'll check out the repo. Here, we'll specify that we're going to be using the Cypress GitHub Action.

[2:04] We tell it that we want to use Chrome as the browser to test in. We give it the script that we want to use in order to start our application. We'll specify the URL for our local server so the job knows to wait until the server is ready before the tests start running.

[2:19] One thing to note is how each of these is organized into their own jobs. I could have created one big job that ran all of these scripts, but I deliberately wanted to keep them separate. This is so that I can see failures for each separately.

[2:31] If these tasks were run linearly, then if one failed, the whole job would exit before executing the following task. I want to know if I have failures in any of these jobs, rather than having to fix any failures for one, push the changes and run again before I can learn if I have any failures in the other jobs.

[2:50] Now, let's see what this looks like in GitHub when I push a PR. You can see all three of the jobs defined in our workflow have started running automatically when I created this PR, and it's running all three of them in parallel as we defined.

[3:06] Now that all three of the jobs have completed, we can see that the ESLint job was successful, but the unit test job and the end-to-end test job both failed. Again, this is why we want to see them running separately so we can see the failure separately. If we want to look at the details of any of these, we can get to them here. Let's see what failed in our unit test job.

[3:28] This brings us to the log for each of the jobs. We can see that our unit tests failed because there were accessibility findings, which is what we expected. Now, let's look at our end-to-end test job. Here, we have the summary from our end-to-end tests. We can see that each of these tests failed.

[3:58] Now, if we go back to the PR, we can see that, even though some of my checks have failed, I'm still able to merge if I want to. We can add a branch protection rule that will prevent merging a pull request if any of the checks have failed.

[4:14] We can do that by going to the Settings for the repository, going to Branches, and under Branch protection rules, click the button to Add a rule. I'm going to be setting this up on my main branch. You'll want to check the box next to Require status checks to pass before merging. We'll need to search for each of the jobs in order to add them to the list of status checks that are required.

[4:43] Now that we've added all of these to the list, they should be required to pass before merging will be allowed. Now, if I go back to my PR, you'll see that now there's this message about "Required statuses must pass before merging." If I weren't an administrator, I would not be allowed to merge this pull request.

https://app.egghead.io/api/v1/lessons/eslint-automate-accessibility-audits-with-github-actions/transcript

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.

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

https://app.egghead.io/api/v1/lessons/a11y-automate-lighthouse-audits-with-github-actions/subtitles

Instructor: [0:00] To get started adding Lighthouse to a GitHub Actions workflow, we'll need to create a .github directory at the root of our project, if we don't have one already, and, inside that, a Workflow directory. I already have one here. Inside this directory, we'll create a new YAML file named lighthouse.yml.

[0:18] We'll start out by giving this workflow a name, and we'll specify that it should run automatically after every push or pull request for the main branch. Now, we'll go ahead and define the job. Again, we'll need to give it a name. We'll need to specify what machine this job is going to run on. Now, we'll need to define the steps that it should take.

[0:41] First, we're going to check out the repo, and then we'll install Node version 14. The next step will be to prepare our application to run in order for Lighthouse to audit it. For my application, that includes running npm install and building my app. Now, we're ready to run the Lighthouse CI tool.

[1:04] To do that, we need to install it first, and then we can call the autorun command. Note, I'm not passing any CLI flags to the autorun command because I already have a configuration file in my project, which Lighthouse will automatically detect and use.

[1:23] Speaking of the configuration file, we'll need to make one modification to it in order to run Lighthouse with our continuous integration suite. We'll need to add a property specifying the location where the result reports will be uploaded.

[1:35] Here, I'm specifying that Lighthouse should use the temporary public storage location that it provides for free. Now, I should be all set to push a PR and see what this workflow looks like when it runs. Here, we can see the Lighthouse workflow has automatically started running.

[1:53] Now that the Lighthouse workflow has completed, we can see that it failed, and we can look at the details here. We can see where Lighthouse started running. It found our configuration file. It ran its suite of audits three times. We had some failures, but these are not the most readable.

[2:12] Thankfully, there is a Lighthouse CI GitHub app that can help give us a nice easy-to-read repo inside of our PR. We can get that set up by going to the Lighthouse CI GitHub app and clicking on the Install button and selecting which organization or repo you want to install it into.

[2:32] I'm selecting my personal account. I'm going to install all repositories. You will need to save this token somewhere safe, like a password manager, in case you wish to use this app with other repos as well. Now, I need to go set this token up in my build environment.

[2:51] If I go back to my repo, and I go to Settings and then Secrets, here, I can add a new repository secret. This needs to be named lhci GitHub app token. Then I'll just paste in the token that I was given by the app. Here now, we can see that it's been added to my repository as a secret.

[3:15] Now, I need to go back to my workflow YAML, and I can add this token as an environment variable used by the Lighthouse CI. We'll also want to set the ref of the head of our pull request, which is going to be used by the lighthouse CI GitHub app. Now, once I push these changes, let's go ahead and see what the results look like in my PR.

[3:37] Now that my audit has completed, we can see that there's this new line item here under our checks for the login URL that we specified for Lighthouse to audit, and it shows the accessibility score from the result of the audit.

[3:50] If we go to Details, we can now see this nicely formatted repo. It shows my score. It shows the issues that it found, a list of audits that it ran in the past, and a list of audits that were not applicable to this URL that it audited. Then it details the various runtime settings that this audit was performed in.

https://app.egghead.io/api/v1/lessons/a11y-automate-lighthouse-audits-with-github-actions/transcript

Course Content