 Courses from Erin Doyle

“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

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

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

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 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

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 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

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

chrome-devtools

When the contrast between foreground and background colors is not sufficient it can be hard to distinguish outlines, borders, edges, and details and text can be hard to read. The minimum recommended contrast ratio is 4.5:1 for most text. Very large text (120-150% larger than the default body text) can be slightly lower at 3:1. 

The contrast ratio of 4.5:1 was chosen because it compensates for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision which is commonly reported as typical visual acuity of people at about age 80.

## References
* https://webaim.org/articles/contrast/
* https://webaim.org/resources/contrastchecker/
* [Accessible Color Picker Chrome browser extension](https://chrome.google.com/webstore/detail/accessible-color-picker/bgfhbflmeekopanooidljpnmnljdihld?hl=en-US)
* https://color.review/

Use Sufficient Color Contrast in Web Page Design

Just about every tool in our accessibility auditing toolkit can help us identify any issues with sufficient color contrast ratio on a web page.  The react-axe library and axe browser extension both report findings on all elements with insufficient contrast ratios.  The tota11y browser extension will annotate any elements with their contrast ratios and color those that are insufficient in red.  

Additionally, we need to use our experience tools to see what some of our users out there may we seeing.  We need to test with high contrast browser extensions as well as the display settings in Windows and Mac.  If our users with visual impairments are using these tools we need to see what our application looks like using them because we may find that under a certain mode some things may suddenly be harder to read or virtually invisible.

## Resources
* https://www.scottohara.me/blog/2019/02/12/high-contrast-aria-and-images.html

Test for Insufficient Color Contrast Accessibility Issues

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. 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 does not provide enough context to be useful enough for those that 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 provides better context for the element and what a user can expect from it.

Add Accessible Labels to Provide Elements with More Context

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers.  When there are already one or more other elements that themselves can be used to provide labeling text to another element an `aria-labelledby` attribute can be added to that element.  

Some examples of appropriate use cases for using an `aria-labelledby` are:
* Combine multiple labels together
* Associate headings with regions
* Label for a widget

Add an Accessible Label to an Element from the Text of Other Elements

When dynamic changes occur to content on a page they are usually visually apparent to users who can see the page but may not be made apparent to users of assistive technologies. ARIA live regions provide a way to make those dynamic content changes able to be announced by assistive technologies.

## ARIA attributes
* `aria-live`: the priority with which updates are read
* `aria-atomic`: whether the screen reader should always present the live region as a whole, even if only part of the region changes
* `aria-relevant` - takes a list of what type of changes should be announced

## Resources
* https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
* https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-live
* https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-atomic
* https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-relevant
* http://html.cita.illinois.edu/nav/form/aria/index.php?example=3

Define a Live Region to Ensure Dynamic Changes are Announced by Assistive Technologies

Keyboard/screen reader navigation relies on focus proceeding in a logical and linear 
order and not getting lost such that the user does not know where they are 
or how to get back to the desired point in a web page.

## References
* https://www.w3.org/TR/wai-aria-1.1/#managingfocus
* https://developers.google.com/web/fundamentals/accessibility/focus/
* https://reactjs.org/docs/accessibility.html#programmatically-managing-focus 
* https://reactjs.org/docs/accessibility.html#programmatically-managing-focus
* https://reactjs.org/docs/refs-and-the-dom.html
* https://reactjs.org/docs/hooks-reference.html#useref
    * https://medium.com/@teh_builder/ref-objects-inside-useeffect-hooks-eb7c15198780
* https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/

Appropriately Set the Focus on Each Page Load of a Web Application

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. 

aria

Although elements that are natively keyboard accessible should be used when possible, there are times when HTML falls short and custom "widgets" are necessary. Complex menus, sliders, dialogs, tab panels, etc. must all be built to support keyboard and screen reader accessibility.

## Widget behavior expectations
* For more complex widgets there are expectations by keyboard and screen reader users as to how these specific widgets will behave and can be navigated
* Interactions must be intuitive and predictable
* Events triggered by mouse clicks should also be able to be triggered via keyboard
* The state of the widget should always be clear

## References
* https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex
* https://inclusive-components.design/
* https://a11yproject.com/patterns/
* https://webaim.org/techniques/keyboard/

WTF are Accessible Design Patterns?

We should not use color alone as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.  Users may not be able to see/understand the differences in color and require additional indicators.

Along with color, use additional indicators such as:
* typography
* shapes
* grids
* spaces
* and/or allocate more weight to important elements

## References:
* http://www.particletree.com/features/interfaces-and-color-blindness/
* https://www.smashingmagazine.com/2014/10/color-contrast-tips-and-tools-for-accessibility/

Use More than Color Alone to Convey Information in a Web Page

The axe browser extension (for Chrome and Firefox) is an immensely helpful tool for auditing web pages for accessibility defects.  This extension is powered by the same rules engine developed by Deque Labs in their axe-core open source library which also powers the react-axe development tool.  Each reported defect offers a ton of information about the defect, why it's a problem, severity level, groups impacted and ways to fix the defect.  This can be a great resource for learning more about how to write accessible code.

## Resources
* [Chrome browser extension](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd)
* [Firefox browser extension](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/)

Use the axe Browser Extension to Audit a Web Page for Accessibility Issues

If you ever want to see data represented in a certain way, such as a chart or a graph, to better understand what's going on in the world, you can use AI's to grab the most recent data and then convert it into any visual format you want. This is enabled in AI studio with Gemini through what's called grounding from web search, structured output formatting data, and code execution, which can run Python and generate charts. This lesson is going to walk you through the challenges of using grounding, especially when working with numbers which need to be accurate. How you can use image recognition and convert that to structured output. And then the challenges of using code execution. Especially when AI's are confident that the code ran even though the code failed. At the end, we still get to generating a chart through the online editor and then we take it also to set up in Cursor in a local environment where we can run all the way through YOLO mode and just click around some buttons and get our chart.

Generate Charts from Current Events with Gemini's Structured Output and Code Execution

Warning: AI's make mistakes. Some of them can be _very_ costly. Terminal have access to your most private information, especially if you're using a "work computer". Please proceed with extreme caution!

Cursor's new "YOLO" feature It allows you to enter an AI prompt and then just sit back and watch as an AI will run terminal commands automatically. The AI will automatically install packages, automatically start and stop dev servers, and even check the output of the terminal commands to run subsequent terminal commands and attempt to fix them.

Traditionally, this is some of the most critical, but also some of the most boring work that a developer has to do, especially when it comes to memorizing all of the various syntax and all of their various commands that you need to know. In larger projects, it's even really easy to forget which commands are even available. So handing all this work over to an AI is a natural step in the evolution of development. But again, please be extremely cautious with these features as there are a million ways that everything could go terribly, horribly wrong.

AI YOLO - Sit Back and Watch Cursor Automatically Run Terminal Commands

GitIngest (https://gitingest.com/) is an awesome tool that allows you to batch together files from a GitHub repo in order to use them with AI tools. This lesson walks through use Git Ingest against a repository that's too large for an AI, so it configures options to narrow down to only the files that you need for your task. Then we'll use Gemini's latest Flash 2.0 model to generate a new project based on the examples we grabbed from the GitHub repo.

Use Gemini to Analyze a GitHub Repo with GitIngest

Manage column visibility in tables using [Tanstack Table](https://tanstack.com/table/v8/docs/guide/columns). Toggle each column's visibility with checkboxes, set some as non-hideable, or hide them by default. Adjust properties in the table code to control displayed columns. 

Install [Shadcn's Switch](https://ui.shadcn.com/docs/components/switch) component to render nice looking switches instead of plain html check boxes.


Hide and Show Columns with Tanstack Table

Learn to hide and show columns in an HTML table with Tanstack Table. Render switch components with shadcn. 

When comparing two visually similar websites, it can often be challenging to precisely identify the subtle differences between them. To facilitate a rapid analysis of these discrepancies, a practical technique involves leveraging Chrome's integrated developer tools to capture full-page screenshots of each site. Subsequently, these screenshots can be uploaded to a platform like AI Studio. There, the AI can analyze the images and generate a report detailing the variations. This entire process, leveraging a few quick shortcuts, can be completed in under a minute, delivering a comprehensive breakdown of the differences for efficient comparison and analysis.

Quickly Compare Two Sites Using AI Studio with Chrome Full Page Screenshots

It's fairly trivial to create a React project, but there's always a big hurdle between creating it locally and making it shareable so that someone else can run it. This lesson walks you through the process of automating creating a React project locally, creating the repository where it's going to be hosted, and creating shareable links where it can be run so that you can quickly and easily create single one-off demos and shoot them over to your friends and coworkers for sharing your code ideas in a working environment.


```bash
share-react-project() {
  if [[ -z "$1" ]]; then
    echo "Usage: share-react-project <project_name>"
    return 1
  fi

  local project_name="$1"
  local github_username=$(gh api /user --jq '.login')

  echo "Creating Vite project: $project_name"
  pnpm create vite "$project_name" --template react

  cd "$project_name"

  echo "Initializing Git repository"
  git init

  echo "Adding all files to Git"
  git add .

  echo "Creating initial commit"
  git commit -m "Initial commit"

  local codesandbox_link="https://codesandbox.io/p/github/${github_username}/${project_name}"

  echo "Adding CodeSandbox link to README.md"
  echo "" >> README.md
  echo "## CodeSandbox" >> README.md
  echo "[![Open in CodeSandbox](https://assets.codesandbox.io/github/button-edit-blue.svg)](${codesandbox_link})" >> README.md

  echo "Adding README.md to Git"
  git add README.md

  echo "Committing README.md changes"
  git commit -m "Add CodeSandbox link"

  echo "Creating GitHub repository: $github_username/$project_name"
  gh repo create "$github_username/$project_name" --public

  echo "Pushing to remote 'origin'"
  git push -u origin main

  echo "Project '$project_name' created successfully!"
  echo "GitHub repository: https://github.com/$github_username/$project_name"
  echo "CodeSandbox link: $codesandbox_link"
}
```

Automate Creating a Local React Project, GitHub Repository, and Live Hosted Demo in a Single Command

[Verdaccio](https://verdaccio.org/) is a fully featured NPM registry that you can run locally on your machine. It’s a great tool for testing your release process, running end-to-end tests, and simulating real-world scenarios like deploying packages, installing them, and verifying functionality as an end user would.

Nx includes a [generator](https://nx.dev/features/generate-code) that simplifies setting up Verdaccio. To configure it, run:

```shell
npx nx g @nx/js:setup-verdaccio   
```

This command installs the necessary NPM packages and creates a `project.json` file with a `local-registry` target. To start the local registry, open a new terminal window and run:

```shell
npx nx local-registry
```

This will:
- Launch the Verdaccio registry.
- Configure NPM to point to the local Verdaccio server at `http://localhost:4873`.

> **Note:** A `project.json` file provides an advanced way to define scripts, offering more flexibility than a traditional `package.json` for managing complex targets.

Setup local Verdaccio server to release NPM packages

Learn how to spin up a local NPM registry powered by Verdaccio to test deploy your NPM packages.

In TypeScript, developers often begin by defining the structure of their data using type definitions or interfaces, which is a powerful way to ensure type safety. However, as applications grow and become more complex, simply defining the shape of an object might not be enough to guarantee its consistent creation and behavior throughout the codebase. This often leads to situations where objects that are intended to be of a certain "type" might be missing crucial properties or have incorrect data, which can be difficult to track down and debug.

This lesson tackles the question of when and why to move beyond basic type definitions and embrace classes in TypeScript. It demonstrates how classes provide a more robust mechanism for defining object structure, enforcing type constraints, and ensuring consistent object creation. By establishing a clear blueprint for objects, classes not only improve compile-time type safety but also offer runtime benefits and better code organization, ultimately helping developers avoid common pitfalls associated with loosely structured objects in larger TypeScript projects.

Stop Avoiding Classes in TypeScript

Karabiner isn't only for your keyboard. It can also hijack your mouse buttons and enable them to be similar to layers on your keyboard, where holding down a mouse button can allow you to tap keys on your keyboard to trigger commands and macros that can completely revolutionize your workflows. For example, you can hold down the right mouse button and tap on R to go to references in VS Code. Or hold down the right mouse button and tap the left mouse button to chop up videos and Screenflow.

This completely unlocks a whole new world of possibilities and use cases for your mouse as you can hover your mouse over anywhere on the page. And just tapping keys on your keyboard allows you to trigger mouse actions, to trigger keyboard actions, or to trigger macros and applications and terminal commands. and anything that your imagination can come up with. 

Karabiner: Rethinking Right-Click as a Macro Command Center

Make an HTML table more readable on mobile devices by using the ::before pseudo-element. We add labels to each cell, so they appear like cards when the table is viewed on smaller screens. The ::before content is set using a data-label attribute for each cell to enhance mobile viewability without horizontal scrolling.



Create a mobile friendly table with the before pseudo-element

Learn to use CSS ::before pseudo-element for mobile-friendly HTML tables. Add labels to cells for enhanced readability on mobile, avoiding horizontal scroll.

Erin Doyle

Search Results