Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
1×
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.

Autoplay

    Set up ESLint to audit Accessibility issues in React

    Erin DoyleErin Doyle
    reactReact
    eslintESLint
    ariaARIA
    javascriptJavaScript

    Our first layer of defense when building accessible React applications is to add some auditing tools to our development workflow. This should include adding static analysis checking for common accessibility standards and best practices. We can get this with the latest eslint plugin: "eslint-plugin-jsx-a11y". If you are already linting your projects adding this plugin should fit very smoothly into your workflow.

    Resources

    1. List of all the rules supported by eslint-plugin-jsx-a11y
    2. Comparison of the difference in rules between recommended and strict mode
    3. Background on how the Accessibility API implemented by browsers interfaces with Assistive Technologies
    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Discuss

    Discuss

    Transcript

    Transcript

    Instructor: If you have not yet installed ESLint, then you will need to do that first, and then include the plugin. It's eslint-plugin-jsx-a11y. I am going to save it to our development dependencies.

    Now that that's installed, we need to configure it. You want to go to your ESLint, config. Mine is in eslintrc.json file. We will add a section for plugins. Again, it is jsx-a11y.

    Now if we want to configure the rules, we can do that here. You'll just specify whatever rule it is you want to configure. For instance, if I wanted to set alt-text to warn, I could do that here.

    If, instead, you want to extend the recommended or strict set of rules, we can do that as well. We would get rid of our specific rule definitions and add to the extends section, plugin jsx-a11y, and we'd either do strict or recommended for recommended mode.

    Let's go ahead and get ready to run it. If you have not done so previously, we can create a script for the linter. We would add to our script section in our package.json file. I am going to call this lint. We run it with the eslint command, and you specify the directory that you want to lint. For my project, it's called source.

    Another really helpful thing we could do is if every time we run test we want to run the linter first, we can add a pretest script that will run our linter.

    Let's go ahead and try this out. I've got a line of code that should trigger the linter and give us the error. Right here, we have img and it is missing an alt attribute. You'll also notice I've got some squiggly lines here.

    Some IDEs will integrate with your ESLint config and will actually visually show you when there is a finding. We can already see if we hover over that that it knows I am missing my alt attribute.

    Anyway, if you are not using an IDE that integrates with ESLint, you can continue to run it from the command line. No problem.

    This should give me an error. Let's go ahead and run it, and see that that happens. I am going to run the test script, just to show it will run my linter before it runs tests. I don't have any test. We're just going to see that the linter will show us the error. There it is.

    Here is my error, "img elements must have an alt prop." That's what we're expecting. If I go ahead and fix that real quick, and let's run it again. This time I am just going to run the lint script directly.

    Let's see that my finding was fixed, and it was. Here we go. Because the command line isn't showing any more output, that means there were no more errors found.