Learn Eslint, Puppeteer and Screen-reader

A large number of people are unable to use the web effectively due to an impairment or disability.

As developers there are several tools and techniques we can use to make our web applications accessible, ensuring a great user experience that includes everyone.

We all agree that Accessibility is important. However, it’s a broad landscape and can be overwhelming figuring out where to start!

Erin Doyle is an expert in creating accessible React applications and has developed a course that will give you a concrete process for testing, refactoring, and building your applications with accessibility in mind.

After this course, you'll have a jump start on auditing and fixing accessibility issues in your applications and gain a better understanding of your target users and how to approach your web app design from their perspectives.


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

Develop Accessible Web Apps with React

OpenGraph images are the images you see when you paste a link into a social platform and it "unfurls" into an image, title, and description. This happens on Twitter, Discord, Slack, and many other platforms. This collection goes over everything from designing OpenGraph images in Figma, to implementing them in CodeSandbox, to returning headless browser screenshots from Netlify Functions, and finally using Cloudinary as a write-through cache. 

You will come away from this collection with the ability to ship an API that you can use on any of your sites, and also on-demand, that can generate images for not only OpenGraph unfurls, but also for Instagram, GitHub, and more. Using headless browsers with playwright to generate our images means we get full access to all the responsive power of CSS and all the logical power of JS to handle layout, importing assets like pngs, choosing different fonts, and more.

The image below is generated via the project you'll build and deploy in this course

![An example opengraph image](https://relaxed-payne-d1bfbe.netlify.com/opengraph?title=Building%20an%20OpenGraph%20image%20generation%20API%20with%20Cloudinary%20Netlify%20Functions%20and%20React&tags=figma,netlify%20functions,playwright&author=chrisbiscardi)

Building an OpenGraph image generation API with Cloudinary, Netlify Functions, and React

screen-reader

There are many techniques for hiding content in user interfaces, and not all are created equal! Learn how different hiding techniques in HTML, CSS and ARIA impact keyboard and screen reader users in addition to visual display. As a bonus, we'll also take a look using a screen reader on a mobile device.

How Visible vs. Hidden Elements Affect Keyboard/Screen Reader Users

Nuclide is the IDE Facebook employees use to write React code. But setting it up to use Flow type checking and Eslint to lint files on the fly is tricky. This video shows you how. 

Setup Nuclide to use Flow and Eslint (Mac)

Puppeteer is a Node library which provides a high-level API to control headless Chrome or Chromium over the DevTools Protocol. It can also be configured to use full (non-headless) Chrome or Chromium.

puppeteer

In this lesson we are going to send commands to the chromium browser with Puppeteer. These commands will enable us to calculate both the total number of CSS stylesheets used on the page and the ruleUsage for each of those stylesheets. With these metrics we will be able to calculate the percentage of unused CSS on the page. 

Get the Percentage of Unused CSS on a Page with Google's Puppeteer

In this lesson we are going to use the firstPaintTime metric from chrome's load times, as well as the navigation start from the W3C window metrics, to calculate how long it takes a page to paint. We will set up a quick function and test it out on google.com

Calculate a Page's First Paint Time with Puppeteer

In this lesson we are going to use Google's Puppeteer to gather metrics about a page's load time. We'll use a high level date subtraction method as well as gather data from the window performance timing. Then see how throttling the network to 3G affects the page's load time. 

Get a Page's Load Time with Puppeteer

It can be helpful when automating tests, metrics, and integration tools to know not only how much JavaScript there is on a page but to calculate how much is not being used. We are able to calculate the percentage of JS used by getting metrics from the window object. 

Get the Percentage of Unused JS on a page with Puppeteer

The pluggable linting utility for JavaScript and JSX.

eslint

JavaScript is great! JavaScript is also full of features and flexible options that can make it easy to introduce bugs. ESLint uses static analysis to check that your code adheres to a list of rules to help you avoid some specific runtime errors. ESLint is highly configurable, so in this lesson, we'll install ESLint and configure some baseline rules for our boilerplate.

Avoid Common JavaScript Errors with ESLint 

The Chrome Developer Tools (DevTools for short), are a set of web authoring and debugging tools built into Google Chrome.

chrome-devtools

What's in a name? In this lesson, I'll explain the concept of naming interactive elements for screen reader users, including forms, buttons, and links. You'll learn how to debug accessible names and descriptions using the Chrome Accessibility Developer Tools (previously a Canary experiment, now in Chrome), using multiple labeling techniques. We'll also listen to the effects of proper accessible names and descriptions in Voiceover and Safari.

For more information and the nitty-gritty browser implementation algorithm, refer to WAI-ARIA 1.1: 
- https://www.w3.org/TR/wai-aria-1.1/#namecalculation
- https://www.w3.org/TR/accname-1.1/

What is Accessible Name Calculation?

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](https://github.com/evcohen/eslint-plugin-jsx-a11y#supported-rules)
2. [Comparison of the difference in rules between recommended and strict mode](https://github.com/evcohen/eslint-plugin-jsx-a11y#difference-between-recommended-and-strict-mode)
3. [Background on how the Accessibility API implemented by browsers interfaces with Assistive Technologies](https://github.com/evcohen/eslint-plugin-jsx-a11y#some-background-on-wai-aria-the-ax-tree-and-browsers)

Set up ESLint to Audit Accessibility Issues in React

Landmark regions are used by screen readers to make it easier for users to navigate the content on the page by defining the structure of the page.  Tools like the Rotor in VoiceOver rely on landmark regions to provide users with the ability to skip directly to the desired section of the page.  We can do this either using HTML5 landmark elements or `<div>` elements with aria roles. In the past, the recommendation was to use both but now we should only use one or the other.

The following are ARIA roles for landmark regions:
* `banner`
* `complementary`
* `contentinfo`
* `form`
* `main`
* `navigation`
* `search`
* `application`

## References
* https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/landmarks.html
* https://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_identify_regions_of_a_page
* https://www.w3.org/TR/html-aria/#docconformance

Define Landmark Regions of a web page using ARIA roles

Using our accessibility auditing toolkit we can find issues concerning landmark regions in our web application.  The react-axe library will report findings in the JavaScript console of the browser.  We could also run the axe browser extension to see the same results.  The tota11y browser extension will annotate any landmark regions on the page and therefore if none are annotated it may indicate that they aren't any (_NOTE: tota11y will only annotate landmark regions using aria roles and not those using HTML5 elements_).  Finally using the VoiceOver Rotor in Safari will show us whatever landmark regions have been defined in the Landmarks menu. 

Test for Landmark Region Accessibility Issues in React

Landmark regions are used by screen readers to make it easier for users to navigate the content on the page by defining the structure of the page. Tools like the Rotor in VoiceOver rely on landmark regions to provide users with the ability to skip directly to the desired section of the page. We can do this either using HTML5 landmark elements or <div> elements with aria roles. In the past, the recommendation was to use both but now we should only use one or the other.  We should prefer HTML5 to ARIA roles when possible.

The following are HTML5 elements for landmark regions:
* article
* aside
* header
* footer
* main
* nav
* section

## References
* https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/landmarks.html
* https://www.a11ymatters.com/article/intro-html5-sectioning-elements/
* https://www.w3.org/TR/html-aria/#docconformance

Define Landmark Regions of a web page using HTML5 sectioning elements

We can find issues with heading levels by utilizing our accessibility auditing tools.  The library react-axe, as well as the browser extension axe, will report any findings concerning heading levels.  The browser extension tota11y will annotate all heading levels on a page and show any in red that have issues.  Finally, we can check the Rotor in VoiceOver in Safari.  The Rotor should have a Headings menu and will list in order all of them that are found on the page.  If headings are missing or inappropriate this will help us find them as well.

Test for Heading Level Accessibility Issues

Similar to Landmark Regions, Heading Levels are used by web browsers, plug-ins, and assistive technologies to provide in-page navigation.

## Rules
* Each page should have at least one `<h1>`
* Pages should be structured in a hierarchical manner
    * `<h1>`: being the most important (usually page titles or main content heading)
    * `<h2>`: usually major section headings
    * `<h3>`: sub-sections of the `<h2>`
    * and so on
* Do not skip heading levels - always follow consecutive order
* Do not use text formatting, such as font size or bold to give the visual appearance of headings.  
    * Use actual heading (`<h1>` - `<h6>`) for all content headings
* Do not use heading levels to achieve visual results only

## References
* https://webaim.org/techniques/semanticstructure/
* https://www.w3.org/WAI/tutorials/page-structure/headings/

Correctly Define Heading Levels of a Web Page

We have a number of options to use when testing for accessibility issues concerning alternative text for images.  The react-axe library and axe browser extension will both report when an image is missing alternative text.  The tota11y browser extension will annotate any images that are missing alternative text.  Running eslint with the eslint-plugin-jsx-a11y plugin installed will report on any `<img>` elements missing an `alt` attribute.  Finally, we can use a screen reader to actually hear what is read when an image has focus.

Test for Image Alternative Text Accessibility Issues

Images must have text alternatives that describe the information or function 
represented by them so they can be read and understood by those using screen readers.

## Alternative text for images
* All `<img>` elements should have an `alt` attribute provided
    * When not provided many screen readers will fallback to reading the file name instead
* The `alt` value should not include words like _“image”_, _“picture”_ or _“icon”_
    * Screen readers are already announcing that the element is an image
* Images that are decorative only and provide no information or function to the page should be hidden from Assistive Technologies by providing an empty `alt` attribute (`alt=””`)

## References
* https://www.w3.org/WAI/tutorials/images/
* https://www.w3.org/WAI/tutorials/images/decision-tree/
* https://www.w3.org/WAI/tutorials/images/tips/
* https://www.w3.org/WAI/tutorials/images/informative/
* https://www.w3.org/WAI/tutorials/images/functional/
* https://www.w3.org/WAI/tutorials/images/textual/

Define Images with Appropriate Text Alternatives

Our accessibility auditing toolkit makes it very easy for us to test for any form controls that are missing labels or are not correctly associated with their labels.  Running Eslint with the eslint-plugin-jsx-a11y installed will show us any form controls with missing or unassociated labels.  Running react-axe or using axe to audit a web page will similarly list any of these findings.  Finally using tota11y we can annotate any form controls on a page that are missing labels.  This is definitely some of the lower hanging fruit that we can easily find and fix when making our applications accessible!

Test for Form Control Label Accessibility Issues

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers.  Elements of a `<form>` such as `<input>` or `<textarea>` or `<select>` should be labelled by using a `<label>` element.  Placeholder text can be used in addition to a label but should not be used in place of a label as not all assistive technologies respect placeholder text.

Ensure Form Controls have Accessible Labels

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers. Some elements do not already have some sort of labeling text being displayed visually, such as a `<button>` without descriptive text or an `<icon>` or part of a more complex widget.  Others may have some form of text label but it is not descriptive enough for those who cannot see it.  The addition of an `aria-label` attribute to the element will provide it with an accessible label so that when that element is focused by a screen reader, for instance, a label is read that better describes the element and what a user can expect from it.

Search

Search Results