Learn Aria, Cypress and Gulp

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

We'll go over the work it takes to use ARIA to show why Semantic HTML is almost always the safer bet. 

Create a Semantic Checkbox vs an ARIA Checkbox

Debug Computed Accessibility Properties with Chrome Dev Tools

In this lesson, we use the element inspector in Chrome to test and improve our contrast to meet WCAG AA Contrast Ratio Standards.

Resources:
- [WebAIM - Contrast and Color Accessibility](https://webaim.org/articles/contrast/)

Debugging Accessible Contrast with Chrome Dev Tools

In this lesson, we are creating the audio player interface more visually appealing using icons from the React Icons library and Font Awesome, in this process, we are also ensuring that the interface remains accessible to screen readers by providing text descriptions for the icons, first by using the `title` prop on each icon, and then by implementing a `visually hidden` technique that hides the text descriptions from sighted users but makes them available to screen readers. This involves copying and pasting some CSS code to create a visually-hidden class, adding an `aria-hidden` attribute to each icon, wrapping each icon in a React fragment, and then adding a `span` element above each icon with the corresponding text description and the `visually-hidden` class.

**Think about:**  
- Why use `aria-hidden` or visually hide spans? 
- What value does this add to screen reader users?

Design Accessible Buttons Using Icons

In this lesson, we will create event listeners for the play and pause events on an audio player element and use these listeners to update the value of a variable called `isPlaying` that tracks the current state of the player (e.g., whether it is currently playing or paused). The event listeners, named `onPlay` and `onPause`, will be triggered when the user presses the play or pause button on the audio player element itself, not on a custom play button that may have been created.

Add Play and Pause Events to the Audio Player

We are creating an input of type range with an associated label, this input is to represent the current playback position in the audio, and the user will be able to change the playback position using the input.

The input value is set to be the media time state, it is added a minimum value of 0 and a maximum value as the duration. The demonstration shows how the media time state updates accordingly when the user changes the time using the input range.

A function called `onScrubberChange` is added, which takes in an event as an argument and `console.logs` the value of that event. The `onChange` event is added to the input, ensuring it works as expected. A variable sets the media time state and the current time on the audio ref.

**Think about:** Why do we use the `event.target.value` to set the new `mediaTime` (reminder that the value of the range is bound to `mediaTime`....maybe take a look at that with the formatter)

Create the Audio Scrubber to Control Playback Position

In this lesson, we are creating a new state called `mediaTime` with an initial value of 0, updating sample text in the markup to display the value of `mediaTime`, and adding an event listener to the audio element for the `timeUpdate` event.

In the `timeUpdate` event listener callback function, the `mediaTime` state is set to the audio element's current time, which can be accessed using the `audioRef.current.currentTime`. A function is added to the `onTimeUpdate` event of the audio element, to be able to track the current time. And a time formatter is added to format the time for displaying elapsed time and total time.

**Think about:** How often does onTimeUpdate update? (every second, not every millisecond) 

Tracking Audio Playback Progress by Adding Elapsed Time 

We created a duration state with an initial value of zero, then added an event listener to the audio element for the `loadedMetaData` event. In the event listener callback function, you set the duration state's value to be the audio element's current duration. This ensures that the value of the duration state is only set once the audio element metadata is loaded, allowing you to display the accurate total time of the audio file.

**Think about:** Why do we need to set the duration on the `onLoadedMetadata` event?

"The `onLoadedMetadata` event occurs when metadata for the specified audio/video has been loaded." You can read the docs [here](https://www.w3schools.com/tags/av_event_loadedmetadata.asp) 


 Implementing a Duration State 

Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is very easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.

Some components render differently based on the route they are rendered on. To use router within component tests, it is best to define its default values in `cy.mount()` function. Since we can customize this in any way we’d like, we can create a custom `path` attribute where we can pass our own routes and test our component behavior against them.

Test a Component Rendering Within Different Router Locations in Cypress Component Test

Every component test that uses Pinia needs to have Pinia imported and initialized. Instead of doing this separately for each test you can customize your `cy.mount()` command to automatically use a default store. You can further then customize it to use your own store in case you want to change its state.

Rewrite Cypress mount() Command to Provide a Default Store to all Components

Instead of calling an action function to change the state, we can choose to change it directly by importing the attributes from our store. In order to not loose reactivity while destructuring properties we can use `storeToRefs()` function.

Mutate Application State Properties Directly with Pinia’s storeToRefs()

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

cypress

When component uses a state management tool like Pinia, it needs to be defined within the test. To use Pinia inside the Cypress component test, we need to create a Pinia instance and pass it into our store. For changing the state we can call our actions directly from within our test and assert different attributes of the component with Cypress commands

Call Pinia Store Actions From Within a Cypress Component Test

`emit()` function enables components to communicate with one another. While this communication is a good candidate for end to end test, we can also test this in isolation within component. To do this, we’ll use `cy.spy()` function that will watch for the defined function call. Using this, we can confirm that our emitted event was actually invoked.

Use Cypress cy.spy() Function to Test a Vue 3 Component’s Emitted Events

By passing a `slots` option to our `cy.mount()` function, we can define content to be rendered inside our current component. We can use default or named components and eve use Vue’s `h()` function to create element and pass components with desired properties.

Render a Vue 3 Component with <slot /> and Test its Content Properties

Some components can have properties passed into them, For these, we can use an options parameter in our `cy.mount()` function and pass `props` attribute which will define the properties we want to pass into our component. This way we can test whether different properties correctly render out in our component.

Pass Properties Into a Vue 3 Component Within a Cypress Test

Importing styles is going to be essential for all of our components to render properly. We will do this similarly as we do in our application - at top level. `component.ts` file is the proper file for this, as this is the one that gets loaded before running our specs. Importing our `index.css` file here will make all of our components render with the correct styles.

Setup Global CSS Properties for Cypress Component Tests

To create our first test, you’ll create a spec file that pairs with the component. Usual naming convention is using `filename.cy.ts` (or .js), but this can be easily set up in `cypres.config.ts` file. After you create the spec file, you can mount the component by importing it and using cy.mount() command inside an `it()` block. This will render the component inside Cypress app, but will not load all the dependencies that the component needs, like css styles. These need to be imported into the spec file manually. Since we are running our component in a browser and inside a Cypress app, we can interact with it using common Cypress commands.

Mount and Test a Vue 3 Component in Cypress

To start with component testing in Cypress you need to open Cypress and go through setup wizard that will help you out with your first steps. It will take you through a couple of steps, where you’ll install dependencies and create important configuration. Most of this is done for you, but you can customize anything. In our application, we will be working with Vue 3 framework with Vite bundler.

Setup Vue 3 Component Testing in Cypress

[Storybook](https://storybook.js.org/) is already powerful for being able to develop components in isolation as well as using those stories as living documentation for others. [Nx](https://nx.dev) goes a step further. It leverages the fact that Storybook exposes an `iframe.html` that allows to access the rendering of the story without the actual Storybook frame. On top of that, Nx generates a Cypress configuration to run tests against the Storybook stories.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-cypress-with-next-js-and-nx-to-battle-test-your-react-components-da273f664f81).


Write Cypress Tests for our React Storybook Components with Nx

[Nx](https://nx.dev) promotes best practices by automatically generating [Cypress](https://www.cypress.io/) based e2e tests for all applications inside an Nx monorepo workspace. Not only does Nx take away the burden of configuring Cypress, but it also allows to easily serve Cypress in "watch" or headless mode. The latter is particularly useful to also run in your CI pipeline. When you run Cypress test with Nx, it automatically makes sure to first launch the tested application, then run Cypress and point it to the running application. 

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-cypress-with-next-js-and-nx-to-battle-test-your-react-components-da273f664f81).

Write e2e Tests for our Next.js Application with Nx and Cypress

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

 We map over the initial set of results then use `Promise.all` to efficiently fetch the details of each pokemon rendered in the table. This allows us to add more columns to our pokemon table.

Fetch and display row details with Promise.all in Tanstack Table

map over the initial set of results then use `Promise.all` to efficiently fetch the details of each pokemon rendered in the tanstack table

Create a custom hook to fetch remote data by passing a promise to the React 19 `use` hook. Then render this data in Tanstack Table by memoizing the results and passing them to `useReactTable`.

Render remote data in a Tanstack Table with React 19's use hook and a promise

Create a custom hook using React 19’s use to fetch data with a promise. Render it in a Tanstack Table by memoizing and using useReactTable.

You know when you're deep in the code trenches and need someone to challenge your assumptions? That's exactly what this is about.

Instead of waiting for someone to poke holes in your master plan, you can paste that strategy straight into AI Studio and let it pressure test your ideas. We're talking about using this tool to validate everything from your feature proposals to your ambitious refactoring strategies.

The real magic happens when you hit that microphone button. Now you're in a real-time verbal sparring match. It's like rubber duck debugging but the duck actually pushes back and makes you defend every architectural decision you've made.

Here's the workflow:
1. Drop your master plan into the system instructions
2. Tell the AI to challenge every assumption
3. Hit that mic and defend your choices like you mean it
4. Watch your plan either emerge stronger or get rightfully dismantled

This approach is perfect when you're:
- Stuck in your own head with a complex problem
- Need to validate if your approach holds water
- Want to catch edge cases before they catch you
- Looking for opportunities you might have missed because you're too close to the code

It's like having a senior dev on call 24/7, ready to challenge your ideas and push you to think deeper about your solutions.

Now go forth and get your ideas challenged. Your projects will thank you for it.


An Uncomfortable and Challenging Conversation with AI Studio

In this lesson, you'll learn how to effectively brainstorm your project ideas before working with AI agents. We'll cover:

1. The importance of having a clear plan before starting work with AI agents
2. Using traditional brainstorming techniques to gather your thoughts
3. Leveraging video recording to capture your brainstorming session
4. How to review and analyze websites for inspiration
5. Documenting likes, dislikes, and potential features for your project
6. Using AI tools (like AI Studio) to organize and process your recorded brainstorming session

The lesson emphasizes a modern approach to brainstorming that combines traditional techniques with video recording, making it easier to later process your ideas through AI tools. This method helps ensure that no ideas are lost and that your thoughts can be effectively organized by AI for future reference.

How to Brainstorm Your Project Features to Prepare for AI Agents

Many people share .cursorrules files, but trying to craft your own from scratch is a huge pain. Instead, this lesson shows you how to grab ALL community-created .cursorrules files to build a custom rule set for your projects. We'll use Gitingest and Google AI Studio to gather these examples and generate an awesome starting point customized to your specific project.

Generate Custom .cursorrules for Your Project Based on Community Examples

The GitHub CLI allows you to search issues and filter on different criteria like amount of comments. This allows you to search for real-world situations and pains/solutions people have using different technology. 

With the GitHub CLI in hand we'll drop 100s of issues as context in Googles AI Studio and have Gemini determine the 10 most frequently asked questions. This will give us a sense of how people use a library and where people get hung up.

Search 100s of Issues with GitHub CLI as Context for AI Studio

I often find myself wondering how to use certain APIs in certain situations, and I have a couple of keywords that I try and search up on Google. 

What you can do in this situation is turn to GitHub and see how other people have actually used this code on public projects. The GitHub CLI enables us to run searches like this, and we can take the results and work on them programmatically.

Inside of Cursor with their Composer AI agent, we can search for the files we want, tell the agent to download them, and inspect them for better understanding of how those things work together.

Search All of GitHub's Code and Pass the Results to AI Agents in Cursor

Implement virtual scrolling to handle large datasets in an HTML table. Start with a basic table that renders 10,000 rows of data. The browser can struggle with this amount of DOM nodes to render at one time, especially on low end devices. 

We implement tanstack react virtual to render only the necessary amount of rows the user is viewing. The implementation includes proper column sizing, accessibility considerations, and convenient scroll controls, resulting in a smooth and performant table experience regardless of the dataset size.

Create a row virtualized HTML table with Tanstack Virtual

Learn how to implement virtual scrolling in React tables using TanStack Table and Tanstack Virtual with the useWindowVirtualizer React hook.

The most difficult tasks will require the strongest AI models. And those models simply aren't available as AI agents inside of your tooling. So the best workflows are to drag and drop the files you need to be changed and analyzed inside of a reasoning model such as OpenAI's O1 Pro, then letting it create a giant plan for your dumber AI agents to work on. The key here is that instead of just copying and pasting the entire plan into Cursors Composer or your AI agent, it's to create a file inside of your project and ask your agent to tackle the plan one step at a time. This allows you ample opportunity between each step to test and verify the micro steps along the way. Otherwise, as I've experienced many times, a session can go way off track and you burn a lot of time and burn a lot of AI requests Cursors Composer and it starts churning through a plan Cursors Composer and making lots of unwanted changes. Cursors Composer and it's to guide an AI agent to hold its hand along the way, especially through the most complex tasks. Cursors Composer and the most complex tasks Cursors Composer and the most complex tasks require a step-by-step plan.

Planning AI Agent Sessions with Reasoning Models

AI agents will inevitably make mistakes—it's just a matter of when. A key tool in your toolbox, once they do make mistakes after working on a problem for a while, is to use **git diff** to capture all of the changes they've made. 

Once you have those changes in a text file, you have a portable document that you can test against other AI models. This allows you to move the problem into smarter reasoning models with smaller context windows, helping you isolate and focus on the issue at hand.

**git diff** has been invaluable when working with AI agents because they'll often make many good changes but also slip in one tiny error. Finding that one small mistake is **git diff**’s superpower.

Search

Search Results