“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

Learn A11y

- Web audio APIs include support for features that aren't available by default in the native HTML audio element.
- The operating system includes basic controls
- Custom controls must be accessible with a keyboard, and make sense to a screen reader
- Don't hide the built-in controls until you know that your custom controls are working
- Listening to what VoiceOver reads should inform the a11y information you include
    - VoiceOver says "Elapsed Time" on its own, so we wouldn't want to write it in our code.
- `loadedmetadata` should have the duration to avoid glitches from new audio not being loaded.
- Elements should be labeled with a unique `id`

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

Create an Accessible Audio Player with the HTML Media Element and React

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.

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

cypress

Auditing React Apps for Accessibility 

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

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

JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

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

The pluggable linting utility for JavaScript and JSX.

eslint

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

Automate Accessibility Audits with GitHub Actions

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

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 

Test Accessibility at Runtime with Selenium WebDriver and aXe-Core

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

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 are creating an accessible popup menu for a web application. It covers various concepts, including handling keyboard events, creating a new dropdown component for reuse, using arrow keys to navigate through buttons, using the Tab key to close the menu and go to the next item in the tab order, using the Escape key to close the menu and focus on the button that closes it, using the `aria-expanded` attribute to communicate whether the menu is open or closed, and the difference between the tab index values of 0 and -1. 

**Think about:**
- Why tabindex -1?
- Why would you use arrows versus tab key to navigate through the dropdown?

Create a Dropdown Menu for Rates

In this lesson, we are using HTML, accessibility concepts, and ARIA attributes to improve the time scrubber feature of an audio player. 

The goal is to make it accessible to users of screen readers so that the time scrubber announces the actual time (e.g. 12 minutes and 15 seconds) rather than just the value (e.g. 735). 

We are also creating a new folder called "helpers" in the "src" folder and a new file called "format time.js" within it to hold a function called "format human read time" that takes time as a parameter and returns the human-readable equivalent of that time. Additionally, the author debugs the code and uses console.log to check the variable.

**Think about:** Why does a human-readable name help?

Create a Human Readable Time Formatter

I suggest using the previously learned approach but keep in mind that it may lead to an overly complex markup. We also use the `aria-label` attribute, which can be used to override the text within a label element.

**Think about:** Why would you use an `aria-label` instead of creating a visually hidden span?

Using Aria-Label as a Solution for Overly Complex Markup

We create an input range with a label, where the range is between 0 and 1 with a step of 0 - 1. The input's value should be determined by a ternary statement that checks if the volume is muted and sets it to 0 or to the current volume if not muted. 

An `onVolumeScrubberChange` function is also added that sets the volume to the event target value when the input value changes and updates the volume in the state and an audio reference. The `onVolumeChange` function does not need to be used and the logic needs to be adjusted to ensure that the volume can be updated and that it mutes when the volume reaches 0.

**Think about:** Why do we have to add `audioRef.current.volume === 0` in addition to `audioRef.current.muted`?

Implementing a Volume Range with an onChange Event

We are creating a toggle button for muting and unmuting an audio element using React hooks `useState` and `useRef`. It destructures `isMuted` from the `useState` hook and sets the initial state to false. 

The button's inner text is dependent on the state of `isMuted`, and a `toggleMute` function is created which sets `isMuted` to the opposite of its current state and also sets the `audioRef.current.muted` property to the opposite of `isMuted`. 

A `onVolumeChange` function is added to the audio element that sets the `isMuted` state based on the value of `audioRef.current.muted`. This allows the `isMuted` state to change even when the mute button on the audio element itself is pressed.

**Think about:** 
- Why do we have to add `onVolumeChange` for instead of `onMuted`? 
- How can we use `onVolumeChange` to check for things being muted?

Creating a Toggle Button for Muting and Unmuting an Audio Element in React

We are creating a playback rate button in a React application. An array of rates is created, and each element of the array is mapped to a button. Each button is given an onClick handler that calls an anonymous function called `changeRate`. 

`changeRate` sets the playback rate of an audio element to the rate passed as an argument. When the button is pressed in the browser, it shows the new playback rate.

**Think about:** We have all these states for volume, media time etc, why don't we have one for rate?

Creating a Playback Rate Button

We will create two buttons labeled "rewind 15 seconds" and "fast forward 15 seconds." Then, we created two functions, `onRewind` and `onFastForward`, to adjust the current time of a media by 15 seconds. The `onRewind` function will use `Math.max` to ensure that the time does not go into negative, and the `onFastForward` function will use `Math.min` to set a max limit. These functions will be added to the click events of the corresponding buttons. Finally, it sets the new time for the media state and the audio reference.

**Think about:** Why do you need the second parameter for `math.max` and `math.min`?

Add Fast-Forward and Rewind 15 Second Buttons

We Introduce [MDN Media docs](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) and all the APIs. 

In this lesson, we added the `useRef` and created an `audioRef` in our components. We also added the `ref` to the audio element to control it outside of the audio element. We use the `useState` hook, and we created an `isPlaying` state. And finally, we added a `button` that dynamically renders the text as pause and play depending on the `isPlaying` state. On click of that button, we toggle the `isPlaying` state, and depending on that state, we either pause or play it.


Creating a Toggle for Playing and Pausing the Audio

In this lesson we are going to create an `AudioPlayer` component that takes two props `src` and `transcript`, where it returns the audio element and renders the transcript, and we write some pseudo-code for the audio player to reference.

**Think about**: What do we get for free with common HTML elements?

Setup Native Audio and Plan our Audio Player Code

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

React's `forwardRef` function allows a component to receive a ref that has been created outside of it. This can be useful in cases where you want to have a specific part of your component, such as a section of a long transcript or a specific part of an audio recording, referenced from outside the component.

One example of when this might be useful is if you have a "listicle" type of audio, such as "5 things your tech resume needs", and you want to allow users to jump to specific parts of the audio. By converting the component to a forwarded ref component, you can create a ref in the parent component (in this case, the "App" component) and pass it into the audio component. This allows you to create a few buttons in the parent component that can control the audio ref and jump to specific audio sections.

To convert a component to a forwarded ref component, you can use React's `forwardRef` function to wrap the component, and then remove the audio ref and replace all instances with the new ref.

By doing this, you can now control the audio component, like play, pause and jump to a specific time, by interacting with the `audioRef` ref object created in the parent component and passed into the audio component.

**Think about:** What ways to control the audio outside the component could help with accessibility?

Topics

Instructors

Content Type