DEV Community: Ben Robertson

The Sneaky Total Blocking Time Issue That PageSpeed Insights Didn’t Catch

Ben Robertson — Fri, 22 Aug 2025 16:42:24 +0000

For months, I was plagued by a performance issue on ColorBliss.

PageSpeed Insights reported 100+ seconds (!!!!) of total blocking time on my home page and a couple of my key landing pages (like this photo to coloring page converter).

I was starting to lose my organic rankings to competitors, and I was convinced that the poor performance on my marketing pages was part of it.

Having worked with a lot of companies on performance issues in the past, I knew that total blocking time (TBT) was one of the hardest Core Web Vitals to tackle. It usually involved getting deep into the weeds of the chrome dev tools performance tabs and untangling a mess of JavaScript code and dependencies to find slow downs.

Digging into PageSpeed Insights

Usually PageSpeed Insights gives you a helpful starting point, like Script Evaluation or Rendering. But not this time.

This time, 100+ seconds were showing up under "Other":

Ok, that's not helpful at all.

Digging Deeper with DevTools

So I did what I've always done in the past: I opened up the Chrome Dev Tools performance tab and started poking around at the on-page JavaScript. I removed packages, changed analytics implementations. But nothing worked.

Finally, I had enough, and assuming that it was an issue in my underlying Next.js usage, I decided to do an MVP of a migration to Astro for my marketing pages.

I got a new page all built out in Astro, and a lot of metrics were better! The first few tests were great.

But then I noticed that I was still seeing 10 to 30 seconds of total blocking time on some PageSpeed runs on a page WITH ABSOLUTELY no JavaScript.

It was infuriating, and I was stumped.

The Fix

At a complete loss at what would be causing it, I went to ChatGPT to see if it had any ideas at what would be going on:

Here's what it suggested:

Render blocking fonts or CSS (look big or sync style tags)
Audit 3rd party embeds or scripts (there were none)
Images or assets decoding during paint (huge svgs or images can trigger main thread work during initial paint)
Hydration edge cases

It gave me these specific tips:

switch from .woff to .woff2 fonts and preload them explicitly.
make sure css is split, purged, and async if possible.
avoid huge base64-encoded SVGs inline in the html.
remove ALL 3rd-party scripts temporarily, retest, then add back one by one.

Well, none of those in particular was going on, but the SVG call outs got me wondering. My hero had two SVGs included in it using tailwind, like this:


<div class="relative overflow-hidden bg-[url('/assets/hero-bg.svg')] bg-no-repeat bg-center bg-cover before:content-[''] before:absolute before:bg-[url('/assets/crosshatch.svg')] before:top-0 before:left-0 before:right-0 before:bg-top before:w-full before:h-full before:opacity-50 before:z-auto">
    // rest of the code
</div>

Notice the two background svgs included in there?

One was a simple cross hatch illustration to add some texture, and the other had some Gaussian Blur in it to make this pretty color background:

I ran a test removing that background SVG with the blurred colors in it and to my surprise, Total Blocking Time dropped to 160ms.

I was shocked! I couldn't believe that something I thought was so simple caused such a huge issue rendering issue.

I removed the SVG, and swapped it out with a relatively simple css gradient:


.hero-gradient {
  background:
    radial-gradient(
      circle at 36% 36%,
      rgba(254, 164, 146, 0.4) 0%,
      rgba(254, 164, 146, 0.2) 30%,
      transparent 60%
    ),
    radial-gradient(
      circle at 66% 15%,
      rgba(146, 196, 254, 0.7) 0%,
      rgba(146, 196, 254, 0.3) 25%,
      transparent 50%
    ),
    linear-gradient(
      135deg,
      rgba(255, 255, 255, 0.1) 0%,
      rgba(240, 240, 240, 0.05) 100%
    );
  background-size:
    100% 100%,
    100% 100%,
    100% 100%;
  background-position: center center;
}

And it worked great. Achieved basically the same look, but with none of the performance issues.

But why was the SVG causing 100s of Total Blocking Time?

Well, that solved my problem, but I still didn't quite understand why. Here's what I leanred.

It turns out that the SVG blur function is incredibly expensive, and my blur radius was ver large.

Browsers are much more efficient at calculating CSS gradients - they draw it once with lightweight math.

To process the SVG blur, the browser has to take an offscreen image of my hero area, then for every pixel average a bunch of neighboring pixels, and do that over multiple passes. And I had standard deviation set to 150 (ie 150 smears). It came out to millions of pixel operations just to render that background.

Takeaways

Anyways, I learned that SVG usage can be an important place to look for performance issues. My leaning has always been that JavaScript is usually the culprit for most performance issues (and in my experience it usually is!) but if you are having a hard time tracking down your Total Blocking Time, it might be worth taking a look at some of your SVGs for expensive operations like blur.

Web Performance Resources for Front End Developers

Ben Robertson — Thu, 05 Jan 2023 00:51:51 +0000

One of the best ways to level up your front end development career is choosing one or more areas to specialize in. Web performance can be directly tied to increases in conversion rates and revenue generated and is a great choice for front end developers looking for an area of specialty since it is so in demand.

By focusing on performance, a front-end engineer can help ensure that their projects are able to handle large amounts of traffic and provide a smooth and enjoyable user experience.

And as the web continues to evolve and new technologies emerge, front-end engineers who are experts in performance will be well-positioned to take advantage of these developments and stay ahead of the curve. They will be able to implement cutting-edge performance optimization techniques and stay up-to-date with the latest best practices in the field. This expertise can also lead to career advancement opportunities and help set a front-end engineer apart from their peers.

There's lots of information out there on web performance, but here are some tried and true docs, courses, books, libraries and tools to dive into if you ar a front end developer serious about getting into web performance.

Resources for getting started

Core web vitals | web.dev

Start here! Core Web Vitals are part of an initiative started by Google to provide high level metrics that act as quality measures of a website. They've picked metrics that represent how quickly your page is visible (First Contentful Paint), how much the layout shifts (Largest Contentful Paint, Cumulative Layout Shift), and how quickly the page is interactive (First Input Delay). These are particularly important because your scores on these metrics affect how your site ranks in Google search results.

Courses

Web Performance Fundamentals

This is a great introduction to the fundamentals of web performance: what makes a website (feel) fast or slow, how to measure performance, how to improve performance, and how to optimize specific metrics.

JavaScript Performance

This a deep dive into understanding JavaScript performance. It includes a brief introduction to web performance, a deep dive into JavaScript performance, sections focused on rendering performance, load performance and tools. The rendering performance and load performance sections in particular are most relevant for front end developers looking to understand how to measure, diagnose, and improve performance on the client.

Modern Dev Tools

A video based course to develop, debug & performance audit your websites. Level-up your web development skills and create blazing fast experiences. Great hands-on practical guide to using dev tools to identify and fix performance issues.

Lightning-Fast Web Performance

A free course led by Scott Jehl that starts with the basics and assumes no prior knowledge of performance concepts.

Advanced Topics

Progressive Hydration

Many front end libraries and frameworks provide the ability to generate HTML and CSS on the server to greatly speed up First Contentful Paint and then later have a "hyrdation" step where JavaScript is loaded, parsed, and the UI is made interactive. This article discusses the hydration pattern in more detail - an important concept when trying to decrease time to interactive.

Books

High Performance Browser Networking: What every web developer should know about networking and web performance

Published in 2013, Ilya Grigorik's book on networking covers the foundations of how browsers work--great for becoming an expert in what's going on behind the scenes on every request to your website.

Going offline

An introduction into using service workers to make your website resilient to network unreliability.

Tools

Lighthouse

Lighthouse is an open source tool developed by Google that helps improve the quality of web pages by measuring performance, accessibility, SEO and progressive web apps. You can run Lighthouse tests from inside of Chrom DevTools, CI environments and as a node module.

Lighthouse scoring calculator

Useful to see how individual metrics play into the larger lighthouse score. Shows you how each metric is weighted, how the weights have evolved over new versions of Lighthouse, and what benchmarks qualify as passing or failing.

PageSpeed Insights

PageSpeed Insights is a tool from Google that along with allowing you to run performance tests measuring Core Web Vitals, combines real world user experience data for users accessing your site, so you can see the real world performance data. PageSpeed Insights also can give you recommendations on where to focus your optimizations. This is a quick and easy way to run a Lighthouse test from on the web.

WebPage Test

WebPage Test is a tool that lets your run several different kinds of tests: Core Web Vitals, Lighthouse, Visual Comparison between two pages and traceroute. You can also customize the device type, network speed, and location to match your users and get a sense of real world performance.

Calibre

Calibre automates testing, reporting and alerting, so you don’t have to. You can set up automated testing of specific pages of any website, set up performance budgets to set targets and meet your goals and monitor progress over time.

Speedcurve

Speedcurve has tools for measuring the performance of your site or app in a lab (also called Synthetic Monitoring) as well as Real User Monitoring, which collects field data from real users on your site to show how they experience the performance of your app. This lets you make targeted, strategic decisions for improving performance for your specific audience.

Popular libraries

Webpack Bundle Analyzer

Webpack bundle analyzer is a tool that helps you visualize the output of your webpack config and see what actually made it into each of your JavaScript bundles.

Other Resources

Got other recommendations? Share them with us on twitter at @remotefrontend and we'll add them here!

Color Swatches in Storybook

Ben Robertson — Mon, 15 Jul 2019 05:00:00 +0000

One thing I had wanted in Storybook for a while was color swatches of all the colors we are using in our project.

We had color swatches in the style tile, but that’s a pretty static document and it doesn’t really get updated once we start dev, even if colors start to change. Plus, I wanted to be able to display the color variable names we are using along side the hex codes so that hopefully as we discuss colors in the project we can use consistent names.

Really, I wanted something exactly like what Brad Frost has in his site’s Pattern Lab:

I only wanted to add this if it was going to be maintainable though. I didn’t want us to have to update storybook separately from any color changes we had to make.

Exporting SCSS variables for use in JavaScript

With some searching, I found that you can export variables from SCSS for use in JS with Webpack. In fact, I didn’t have to change the Webpack configuration for Storybook at all in order to do this.

Our _colors.scss partial looks like this:

// Defining color variables.
$color-dim-gray: #676767;
$color-zorba: #A19A94;
$color-white-sand: $F1F0ED;
// ... other colors

// Export color variables for use in Webpack.
:export {
  dimGray: $color-dim-gray;
  zorba: $color-zorba;
  whiteSand: $color-white-sand;
  // ... other colors
}

Now that we have the export defined, we can import this object in a JS file, and loop over each color to create a swatch.

// Import colors object.
import colors from './_colors.scss';

const colors = () => {
  return (
    <ul>
      {Object.keys(colors).map((color) => (
        <li>
          <span
            style={
              backgroundColor: colors[color],
              display: 'block',
              height: '4em',
              marginBottom: '0.3em',
              borderRadius: '5px',
              border: '1px solid lightgray'
            }
          />
        <span>{color}</span><br /> // color name
        <span>{colors[color]}</span> <br /> // hex value
      </li>
      )
    )
  )
}

This generates a pretty nice list of colors. A couple things were missing though:

the color name displays in camelCase, but that’s not how we reference the colors when we use them in SCSS.
the colors are in a single big list, and could be organized better.

Computing color names

Based on the swatch above, we would get output that looks like this:

{swatch color}
dimGray
#676767

What I was aiming for was this:

{swatch color}
Dim Gray (color name)
$color-dim-gray (variable name)
#676767 (actual color variable)

With some help from Stackoverflow, I found a snippet that would help me split the camelcased color name on uppercase letters:

let color = 'dimGray';
color.split(/(?=[A-Z])/);
// returns ['dim', 'Gray'];

This let me do some transformation on the color text.

const colorVariable = (color) => {
    // make an array of the separate words in the color name
  const array = color.split(/(?=[A-Z])/);
  // add a dash in between each word, lowercase everything, and
  // prefix with '$color-'
  return `$color-${array.join('-').toLowerCase()}`;
};

colorVariable('dimGray')
// returns '$color-dim-gray'

I used a similar method to create the color name:

const colorName = (color) => {
  const array = color.split(/(?=[A-Z])/);
  return `${array.join(' ').toLowerCase()}`;
};

colorName('dimGray')
// returns 'dim gray' (I use css to capitalize this in the component)

So that gets me all the values I wanted for each color.

Grouping colors

Another thing I wanted to do was group the colors together. I wanted to display all the neutrals together, all the brand colors together, and the accent colors together.

I found that when you are exporting your values from SCSS, you can nest values in the object:

// Before, without nesting
:export {
  dimGray: $color-dim-gray;
  zorba: $color-zorba;
  whiteSand: $color-white-sand;
  // ... other colors
}

// After, with nesting
:export {
    neutral: {
        dimGray: $color-dim-gray;
      zorba: $color-zorba;
      whiteSand: $color-white-sand;
      // ... other colors
    };
  brand: {
   // brand colors
  };
  accent: {
    // accent colors
    };
}

Now, when you import the colors into JavaScript, each color key will be prefixed with the nested object key name. For instance - dimGray will come in as neutral-dimGray.

This means I need to adjust the methods I created above for parsing the color names. I want to remove the prefix when I display the names, so I need to split on a ‘-‘ and grab what comes after the hyphen, like this:

color.split('-')[1]

So my colorVariable function becomes this now:

const colorVariable = (color) => {
  const array = color.split('-')[1].split(/(?=[A-Z])/);
  return `$color-${array.join('-').toLowerCase()}`;
};

And the colorName function is adjusted similarly.

// Convert the color key to the color proper name.
const colorName = (color) => {
  const array = color.split('-')[1].split(/(?=[A-Z])/);
  return `${array.join(' ').toLowerCase()}`;
};

The components

The last step in this was creating the components for rendering in Storybook.

I created a <ColorGroup /> component that displays a collection of <Color /> components.

Here’s the display I ended up with in Storybook:

And here’s my entire stories.js file for reference on how it all comes together:

import React from 'react';
import PropTypes from 'prop-types';
import { storiesOf } from '@storybook/react';
import colors from './_colors.scss';

const filterGroup = (filter) =>
  Object.keys(colors).filter((color) => color.indexOf(filter) === 0);

storiesOf('Global|Colors', module).add('all', () => (
  <div style={ padding: '20px' }>
    <>
      <h3>Neutral Colors</h3>
      <ColorGroup group={filterGroup('neutral')} />
    </>
    <>
      <h3>Brand Colors</h3>
      <ColorGroup group={filterGroup('pbr')} />
    </>
    <>
      <h3>Accent Colors</h3>
      <ColorGroup group={filterGroup('accent')} />
    </>
  </div>
));

// Convert the color key to the color variable name.
const colorVariable = (color) => {
  const array = color.split('-')[1].split(/(?=[A-Z])/);
  return `$color-${array.join('-').toLowerCase()}`;
};

// Convert the color key to the color proper name.
const colorName = (color) => {
  const array = color.split('-')[1].split(/(?=[A-Z])/);
  return `${array.join(' ').toLowerCase()}`;
};

// A component for displaying individual color swatches.
const Color = ({ color }) => (
  <li
    style={
      borderRadius: '5px',
      border: '1px solid lightgray',
      padding: '5px'
    }
  >
    <span
      style={
        backgroundColor: colors[color],
        display: 'block',
        height: '4em',
        marginBottom: '0.3em',
        borderRadius: '5px',
        border: '1px solid lightgray'
      }
    />
    <span style=>{colorName(color)}</span>{' '}
    <br />
    <span>{colorVariable(color)}</span> <br />
    <span>{colors[color]}</span> <br />
  </li>
);

Color.propTypes = {
  color: PropTypes.string.isRequired
};

// A component for displaying a group of colors.
const ColorGroup = ({ group }) => (
  <ul
    style={
      display: 'grid',
      gridTemplateColumns: 'repeat(auto-fill, minmax(120px, 175px))',
      gridGap: '20px',
      marginBottom: '40px'
    }
  >
    {group.map((color) => {
      return <Color color={color} key={color} />;
    })}
  </ul>
);

ColorGroup.propTypes = {
  group: PropTypes.array.isRequired
};

I’m thinking about packaging this up as an addon for Storybook. If you would find that useful - let me know either via email or Twitter!

The Myth of Inaccessible React

Ben Robertson — Thu, 13 Jun 2019 05:00:00 +0000

On Twitter, in Slack, on Discord, or in IRC, or wherever you hang out on the internet, you may have heard some formulation of the following statements:

React doesn’t support accessibility
React makes websites inaccessible
People should write accessible HTML instead of React
React is ruining the internet

There’s a somewhat common misperception that JavaScript frameworks and web accessibility don’t mix. React, being one of the largest JavaScript libraries, is often the target.

In my career, however, I had the interesting experience of being introduced to accessibility and ReactJS at around the same time. I found tooling in React that helped me learn a lot about accessibility that I never would have encountered otherwise.

And so while I don’t disagree that there are plenty of libraries, websites, apps, etc. written in React that are inaccessible, I do disagree there is something inherent in ReactJS that makes developers build inaccessible sites. In fact, I love the accessibility tooling available in the React ecosystem, and so this post is really about how React can help you make more accessible websites than you’ve ever made before.

I’ll outline how you can combine React linting tools, DOM auditing, and Storybook (a component library tool) to provide a really supportive accessibility environment for developers – whether they are accessibility pros or just getting started.

By the end of this post, you’ll have the following configured for your Gatsby project (or other React project):

in-editor reporting of accessibility errors
a pre-commit hook for preventing accessibility errors from getting into the repository
browser console reporting of accessibility errors during development, with links to info on how to resolve the errors
a component library with built-in accessibility testing so all project stakeholders can hold the team accountable for accessibility issues

Want to get started right away? I created a Gatsby starter with all these accessibility tools built in. Checkout my gatsby-starter-accessibility repo that has all these features available out of the box.

Tools and Setup

eslint-plugin-jsx-a11y

If you’ve written JavaScript over the past few years, you’ve probably used or at least heard of eslint. If not, now is a great time to get started with it!

Eslint is a linting utility for JavaScript that helps you catch formatting and syntax errors while you are writing your code. Most editors have some sort of linting configuration built in, which lets you see errors in your editor while you are writing code.

This is really helpful for keeping code consistent, especially when there’s a lot of people working on a project.

Eslint also has a really healthy plugin ecosystem. You can include rules specific to the JavaScript framework you are working with (ie, React, Angular, Vue, etc), among others. For React, I typically use the eslint-plugin-react and the really helpful eslint-plugin-jsx-a11y. This plugin lints your code for known accessibility violations, using these rules.

Having these automated tests run while you are writing code can prevent so many errors. Even though automated accessibility testing catches only about 20-30% of all accessibility errors, catching these errors before they make it into a codebase can save time, budget, and energy for doing more manual testing once the code is in the browser.

Usage

Here’s how you can get started with accessibility linting in your React project.

First, we’ll need to install the necessary eslint packages:

npm install eslint eslint-plugin-react eslint-plugin-jsx-a11y --save-dev

In your package.json, add the following configuration:

"eslintConfig": {
    "parserOptions": {
      "sourceType": "module"
    },
    "env": {
      "node": true,
      "browser": true,
      "es6": true
    },
    "plugins": [
      "react",
      "jsx-a11y"
    ],
    "extends": [
      "eslint:recommended",
      "plugin:react/recommended",
      "plugin:jsx-a11y/recommended"
    ]
}

With this added to your package.json, eslint will use the rules recommended by eslint, react, and the jsx-a11y plugin while you are working.

You’ll want to make sure your editor is set up to display linting errors in the editor for this to be really useful.

Add a pre-commit hook for preventing inaccessible code in the codebase using lint:staged

So, now that we’ve got some accessibility linting set up, and hopefully everyone working on the project has linting turned on in their editor so they can see any errors while they work.

But you can’t be 100% sure that everyone will be paying attention to the linter. And even if they are, it’s easy to make a quick change, switch files, and any errors will be out of sight, out of mind.

What we can do as an extra check to prevent inaccessible code from entering the codebase is to add a pre-commit hook that runs the linting we set up above every time a developer tries to commit code. If an accessibility error is found, an error message will display with the relevant linting error and location of the error, and the commit will be prevented until the developer resolves the issue.

lint-staged will run a pre-commit hook that will catch any accessibility errors raised by eslint-plugin-jsx-a11y

Usage

The easiest way to set up pre-commit linting hooks is using the lint-staged package. After you’ve got all your eslint configuration set up (from our first step), run the following command in your project directory:

npx mrm lint-staged

This command will install the husky package for managing the pre-commit hooks and look in your package.json to automatically setup a pre-commit hook based on your linting configuration.

A simple configuration that lints all JS files based on the existing eslint configuration in the repo will look like this (from package.json):

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
},
"lint-staged": {
    "*.js": [
      "eslint"
    ]
}

You can adjust this as you see fit. For example, sometimes you want to limit linting to certain directories. To run the pre-commit hook only on JS files in the src directory, you would update the lint-staged configuration like this:

"lint-staged": {
    "src/*.js": [
      "eslint"
    ]
}

The great thing about lint-staged is that it only lints the files that are part of the current commit. If for some reason there is some pre-existing errors in another part of the codebase, the commit won’t be prevented–it only prevents new errors from being introduced.

react-axe

The great thing about the linting setup we have now is that it will prevent a lot of errors from being introduced into the codebase. It won’t prevent all errors, however. Some errors only exist when several components are used together, or from certain content, and can only be caught in the browser.

Luckily, we have a solution for this, too. Axe is an open source engine for automated accessibility testing, supported by Deque. I first became familiar with axe by using their really useful browser extension for testing individual pages in the browser.

The problem with browser-extension accessibility testing is that they are typically only run after development is complete. Using the react-axe library, you can have automated accessibility testing run on every page during development, so developers can get real-time feedback on accessibility issue. This helps make sure that accessibility issues never make it to production, and it also educates developers who may not be accessibility experts on potential pitfalls.

The react-axe library is an easy to use implementation of the axe engine, specifically for React.

Usage

Here’s how to get started using react-axe with Gatsby (someone made a Gatsby plugin for it!):

npm install --save gatsby-plugin-react-axe

Add gatsby-plugin-react-axe to your plugins array in gatsby-config.js

module.exports = {
  siteMetadata: {
    title: 'Gatsby Default Starter',
    description:
      'Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.',
    author: '@gatsbyjs',
  },
  plugins: [
    'gatsby-plugin-react-axe',
    // other plugins go here
  ],
};

Now, when the page renders, the plugin will print any accessibility errors to the browser console. Here’s an example, where I’ve put an <h5> directly underneath an <h1>:

React aXe will show accessibility errors in the console while you are developing.

You can see that in the axe message in the console that it has identified my heading issue: “Heading issues should only increase by one” as a moderate issue. It also includes a link to learn more about why this is an issue and how to resolve it: https://dequeuniversity.com/rules/axe/3.2/heading-order. And lastly, it displays the specific element that is causing the issue for easy identification.

This kind of instant feedback is so important, whether you are an accessibility beginner or even a seasoned pro, catching the automated issues instantaneously can give you more bandwidth to focus on other more involved tasks.

Storybook and Accessibility

The last piece of our accessibility workflow has to do with our component-driven workflow. For React projects, I have really enjoyed using Storybook to build and document our front end components.

Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building stunning UIs organized and efficient.

Besides having a nice workflow and UI, Storybook has an awesome accessibility add-on that adds a panel to each component in your component library documenting accessibility issues.

Behind the scenes, the add-on actually also uses aXe for testing. This is really nice, because it means that the testing we are using in development is the same as what we are using in the component library. Having the errors highlighted in the component library also helps everyone on our project teams catch accessibility issues as they are browsing the library, either for QA purposes or design inspiration.

Setup

The setup for Storybook is a bit more involved, so if you haven’t used Storybook before, you can checkout the Storybook for React documentation for a generic React setup.

If you want to get Storybook running with Gatsby, see Visual Testing with Storybook in the Gatsby docs.

Once you have Storybook setup, adding the accessibility add-on is pretty straightforward.

First, install the add-on:

npm install @storybook/addon-a11y --save-dev

Then add this line to your addons.js file in your storybook config directory:

import '@storybook/addon-a11y/register';

And lastly, add this line in your Storybook config.js file to automatically add the accessibility panel to all components:

addDecorator(withA11y);

When you run Storybook now, you should now see the accessibility panel (see a live version here):

Our storybook configuration has built-in axe tests for each component and a color blindness simulator, provided by the storybook accessibility add-on.

As a side note - you can control the order of the tabs in your add-ons panel based on the order that you import add-ons into your addons.js file, if you want to have the accessibility panel display by default, make sure it is the first line in your addons.js.

Wrap up

If you didn’t follow along with the setup or just want to get a new project setup quickly with this workflow, checkout the gatsby-starter-accessibility Gatsby starter

You can create a new Gatsby site with all the configuration I described above out-of-the box with this single line in your terminal:

npx gatsby new my-accessible-project https://github.com/benjamingrobertson/gatsby-starter-accessibility

Or you can checkout the specific configuration in the repo.

Whether you ran through all the steps above or just run with the starter, you’ll have the following features set up in your Gatsby / React project:

in-editor reporting of accessibility errors
a pre-commit hook for preventing accessibility errors from getting into the repository
browser console reporting of accessibility errors during development, with links to info on how to resolve the errors
a component library with built-in accessibility testing so all project stakeholders can hold the team accountable for accessibility issues

On a complex project with many team members and moving parts, automating accessibility testing will help save time to make sure you can pay more attention to the accessibility tasks that can’t be caught by automated tests.

Beyond that, tools like this can really help developers level up their accessibility knowledge.

I know it’s helped me–I hope it helps your team too!

Want to dive deeper into building accessible websites? Join my free email course:

📨 Common accessibility mistakes and how to avoid them. 30 days, 10 lessons, 100% fun! 😀 Sign up here!

The Cover Letter that Got Me a Remote Front End Developer Job

Ben Robertson — Fri, 26 Apr 2019 00:58:28 +0000

Some people seem to think you can skip the cover letter on job applications. I think they see it as extra work that holds them back from applying for more jobs.

But that’s looking at it all wrong. If a company is asking for a cover letter, that is your chance to wow them with how unique and wonderful you are. Yes, you can be really creative with your resume too. But if they are giving you the opportunity to send a cover letter, why not take advantage of it?

Plus, if you come up with a good cover letter template, you can repurpose it for multiple job applications. And guess what – I’m sharing the exact cover letter I sent when I was looking for remote front end work back in the fall of 2017, so you have no excuse not to include one now 😉.

The Letter

Hello Team ${companyName} :),

I’m a front-end developer based out of Greenville, SC, and I create fun, innovative, accessible, and fast websites. I try to leave every bit I code I touch more readable, modular, performant and accessible than I found it. I’ve worked with major universities across the Southeast US, including Clemson University, University of North Carolina at Chapel Hill, and award-winning work for the University of Kentucky (https://www.upandup.agency/awards/upup-wins-ucda-excellence-award-university-kentucky-website).

Beyond front-end coding chops, I’m also passionate about writing and sharing what I’ve learned both with my teammates and the broader web community. I really value the ability to not only perform web development work but also help others improve their craft, because I’ve gained so much from others sharing their skills and knowledge. At Up&Up, I’ve led several different documentation initiatives for my current team, including our use of pattern libraries (https://css-tricks.com/build-style-guide-straight-sass/), a CSS style guide (https://benrobertson.io/front-end/css-standards), and an internal best practices site. I’m also in the process of writing a book on accessible web design (https://benrobertson.io/accessibility-for-web-developers/), to share what I’ve learned over the past several years.

On a team, I tend to help bring out a clearer sense of purpose and encourage clearer communication, resulting in better team results and a higher sense of satisfaction for all involved.

Let’s talk about how I could put my eye for detail, practice of web standards and communication skills to work for ${companyName} and friends. Thanks for your consideration.

Ben Robertson

Anatomy of the Cover Letter

Wow, right? Are you kind of wanting to hire me right now too? 😜

Feel free to repurpose that letter as you see fit for yourself. What I really recommend though is going through my explanation below and crafting your own very unique letter. I’ve gone through paragraph by paragraph explaining what I’m trying to communicate in the letter and I’ve included ideas that may help you brainstorm your own amazing creative cover letter.

Greeting

Hello Team ${companyName} :),

For my greeting, I wanted them to know I was writing a cover letter specifically for their team, so I always included the company name.

I also wanted to communicate that I’m a warm, friendly person, so I included an emoji. I guess if you wanted to be even warmer, you could include a hugging emoji, or something. I like smiling so I included a smiley 🙂.

First Paragraph: Introduction and Establishing Credibility

In the first paragraph, I have a few goals. First, I want to introduce myself and show a little more of my personality:

I create fun, innovative, accessible, and fast websites.

I came up with this tagline to show what I value in my work. I’m trying to communicate that web development for me is not just about churning out websites, but that I have a value system behind my work. I’m explaining what’s important to me, and what kind of person I am, in addition to showing that I know that accessibility and performance are important buzzwords 😉.

I follow up that tagline by going a little deeper:

I try to leave every bit I code I touch more readable, modular, performant and accessible than I found it.

Here I’m trying to show that I also know that code should be readable so that other developers can work on it and it should be modular for maintainability. In other words: I am team focused.

I’m also expounding on my value system a little bit by revealing that I do this on all projects. I’m explaining that they won’t have to tell me that readability, modularity, accessibility, and performance are important. I already value those things and I take the initiative on my own to implement them.

Lastly, I attempt to establish some early credibility by mentioning some work that I have done, focusing on bigger name clients I had worked on. Like any web developer looking back on their code years later, I’m not proud of all the code in those projects, and some of them hadn’t launched at the time (and maybe still haven’t). What’s important here isn’t that I’m pointing to some amazing code I wrote, but simply that I’m establishing credibility. Really what I’m trying to say is: “Hey, I’m a guy you’ve never heard of, but these people think I’m good enough to do work for them so maybe you will too.”

Second Paragraph: Highlight some accomplishments

In this second paragraph, I try to highlight some accomplishments that I am particularly proud of:

Beyond front-end coding chops, I’m also passionate about writing and sharing what I’ve learned both with my teammates and the broader web community. I really value the ability to not only perform web development work but also help others improve their craft, because I’ve gained so much from others sharing their skills and knowledge. At Up&Up, I’ve led several different documentation initiatives for my current team, including our use of pattern libraries (https://css-tricks.com/build-style-guide-straight-sass/), a CSS style guide (https://benrobertson.io/front-end/css-standards), and an internal best practices site. I’m also in the process of writing a book on accessible web design (https://benrobertson.io/accessibility-for-web-developers/), to share what I’ve learned over the past several years.

For a long time, it was so difficult for me to come up with web development accomplishments that I was proud of, because I was always looking at code that I wrote in the past and saw all the things that were bad about it with my 20/20 hindsight.

Then, one day, I sat down with a blank sheet of paper to write down the things I was proud of as a web developer, and I realized it wasn’t the actual code I had written. What I was really proud of was introducing our team to a new way of doing things, finding a new library we could use, or just always trying to help the team improve.

And the more I thought about it, I realized that being motivated and able to identify ways for a team to improve was a Really Valuable Attribute to bring to a new company. If you had the choice between hiring a rock star developer that is really good but keeps to herself, or a person who will help improve himself and everyone around him, who would you hire? Who is going to have the biggest impact on your team? Who will have the biggest impact on the bottom line?

So in this paragraph, I focused on those things. I was really proud of my article on CSS Tricks. I posted some articles on my blog that I had initially written for an internal best practices site, so the writing could be public. And I decided to write a book (I haven’t actually written the book. I’m still planning it – but being someone who has a plan to write a book still sets you apart from others).

For you, I recommend spending some time thinking about the accomplishments that make you the most proud. They could be some amazing portfolio pieces, or a super cool npm library you wrote. Or, like me, they could be soft skills. Are you a good writer? Are you good at planning, estimating? Did you save your company a bunch of money some how? Try to think from a business perspective rather than from a strictly coding perspective.

Third Paragraph: More soft skills

I highlighted some specific accomplishments in the second paragraph, but now in the third paragraph I’m highlighting some more general soft skills that I have:

On a team, I tend to help bring out a clearer sense of purpose and encourage clearer communication, resulting in better team results and a higher sense of satisfaction for all involved.

Soft skills are especially important in remote work. Being a good communicator is non-negotiable. At Mediacurrent where I ended up, the team focus is so strong that I think the fact I identified this really made me stand out.

Think about the unique perspective you bring to team meetings. Think about the questions people ask you. Think about the questions you ask. All these can be clues to the value and role that you play in a team.

Fourth Paragraph: Brief summary and close

Let’s talk about how I could put my eye for detail, practice of web standards and communication skills to work for ${companyName} and friends. Thanks for your consideration.

In the last paragraph I bring it to a clean conclusion. I say “Let’s talk” because that’s what I want: an interview. I see it as a call to action.

I make the call to action a brief summary of what I’ve laid out above, highlighting one aspect from each paragraph. “Eye for detail” sums up the first paragraph where I talk about always leaving the code better than I found it. I call out web standards because I mentioned accessibility and performance a couple of times in the first and second paragraphs and I want to remind them of that. And I call out “communication skills” as a nod to my third paragraph about soft skills.

I also include the company name for personalization, and for agencies I added “and friends” to acknowledge I understand that clients are important 🙂. For some applications, if it was a product I used or company that I loved, I also highlighted that fact here.

The call to action is clear (“let’s talk“) and what’s in it for them is also clear: I’ve laid out a brief summary of the things that are great about me. I add a courteous “Thanks for your consideration” to be professional and grateful and sign off.

Wrap up

So, there you have it: the cover letter template that I used to get the remote front end developer job I have now. I guess you could copy it word for word, but that would be weird.

But do feel free to take whatever you find helpful from the letter and from my anatomical break down of the letter. I’m writing this because I want you to get your dream job, just like I got mine. Because even though you might be doubting yourself now, getting that new job is within reach for you. And if you are front end developer looking for remote work – try out your new cover letter on our latest remote front end developer job listings.

Looking for a new job?

Front end remote jobs is a curated job board featuring fully remote front end jobs for front end developers. New jobs are added every week.

View all remote front end jobs =>

Designing Layouts for Screen Readers

Ben Robertson — Tue, 11 Dec 2018 14:00:00 +0000

It’s easy to think about a layout as being a primarily visual concern. The header goes up top, the sidebar is over here, the call to action is in an overlay on top of the content (just kidding). Grids, borders, spacing and color all portray valuable visual data, but if these hints to the structure of a page are only visible, some users may find your content unintelligible.

You can experience this first hand if you try using a screen reader on the web. When I fired up VoiceOver on my Mac and took it out for a test drive, I realized that to a screen reader user, a lot pages are just a big heap of ‘content’, missing helpful organizational cues.

The experience can be kind of like listening to a long rambling story without any indication to what details are important or related to the main thread of the story. Halfway through the story, you aren’t sure whether it’s worth it to keep listening because you don’t know if you’ll even find what it is you’re looking for. In the context of a website, your screen reader might be halfway through reading you a list of 50 sidebar links when you start wondering if there is any valuable content on the site at all.

Experiences like this are caused by websites that are built with layouts that are only visual. Ideally, however, our visual layouts should point to an underlying organizational model of our content. They should be visual indicators for a conceptual model. The visual indicators are just one way of revealing this model. The Web Accessibility Initiative’s ARIA (Accessible Rich Internet Applications) project provides alternative indicators to users who may need them.

I’ll walk through how to make use of these indicators to make a simple web page easy to use, navigate and read for users of assistive technology. All the example code is available on github.

Want to up your accessibility game? Checkout my free email course:
✉️ Common accessibility mistakes and how to avoid them.

Initial Layout

Here’s an example of a page with a pretty simple layout. We’ve got a header at the top containing a logo and navigation, some body content, a sidebar off to the right with a related posts list and a list of social media sharing links, a search box below the content and a footer containing the contact info of our business.

Visually, the content is pretty well divided, using a simple grid and background colors to distinguish the different elements. If you fire up VoiceOver on this page, you can navigate through the page pretty well using the next element command. The order of elements in the markup pretty much follows the visual order of elements. First we read the header, then the body copy, then the sidebar, then the search box, then the footer. That’s pretty good. If I press CAPS + U to pull up the VoiceOver menus, I can get a list of all the headers on the page and all the links, and navigate directly to them.

Just by using well-structured HTML, simple grouping with <div> elements and a good use of heading tags we’ve got a decent experience. It’s better than the rambling story websites I mentioned above, but it could be even better.

Skip Link

First we’ll add a skip-link as the first item of the page. A skip link is a very common accessibility feature that allows users to skip past lengthy lists of links and other information repeated on every web page directly to the main content of the current page.

It’s a link that is the first element in the tab order of the page. It is typically visually hidden, but when focused, it appears on-screen. To visually hide the link, we’ll add the following CSS:

.skip {
    clip: rect(1px, 1px, 1px, 1px);
    position: absolute !important;
    height: 1px;
    width: 1px;
    overflow: hidden;
    word-wrap: normal !important; /* Many screen reader and browser combinations announce broken words as they would appear visually. */
}

/* Display the link on focus. */
.skip:focus {
    background-color: #fff;
    border-radius: 3px;
    box-shadow: 0 0 2px 2px rgba(0, 0, 0, 0.6);
    clip: auto !important;
    color: #888;
    display: block;
    font-weight: bold;
    height: auto;
    left: 5px;
    line-height: normal;
    padding: 15px 23px 14px;
    text-decoration: none;
    top: 5px;
    width: auto;
    z-index: 100000;
}

The link location of the skip link needs to be an id pointing to the main content of the page. In our case, I added id="main" to the <div class="content"> section and gave the skip link a url of href="#main".

If you visit the skip link page and hit your Tab key, the link should display. If you fire up VoiceOver and start navigating through the page, the skip link should be the first thing you come across, and clicking it should trigger VoiceOver to start reading the main content of the page.

WCAG Techniques Used

Skip Links

With this step, we’ve allowed users to skip straight to the meat of our page, but beyond easily accessing the main content, they still don’t have a good conceptual map of the rest of the page.

ARIA Roles and Landmarks

One way to provide users with a conceptual map of the page is by using semantic HTML5 elements like <header>, <nav>, <main>, <section>, and <aside>. These elements have built in data associated with them that is parsed by browsers and screen readers. They create landmarks on a web page. By using these elements judiciously in place of <div> elements, we can provide extra information to assistive technology devices and help the user build a conceptual map of our page.

I’ve maintained the same layout as before, but I’ve swapped some divs for some semantic HTML5 elements. I’ve also added a role attribute to the search component. Alternatively, you could keep all the divs and add a role instead of swapping them out for the new HTML5 elements. (See the w3 guidelines for ARIA roles)

- Preview the updated layout

View the updated HTML

<div class="header"> becomes <header class="header">
<div class="main-navigation"> becomes <nav class="main-navigation">
<div class="content"> becomes <main class="content">
<div class="sidebar"> becomes <aside class="sidebar">
<div class="related-posts"> becomes <section class="related-posts">
<div class="search"> becomes <div class="search" role="search">

Now when I fire up VoiceOver and press CAPS + U, I get a new Landmarks menu. Inside this menu you can see the following elements:

banner
navigation
main
complementary
search
content information

Selecting any of these menu items takes the user straight to that element, so they can easily navigate through the different elements of a page. If they are at the bottom of the page, they can easily get back to the main navigation in the header via the Landmarks menu.

WCAG Techniques Used

ARIA Landmarks

We’ve dramatically increased the navigability of our page and provided an initial map to our users, but we’re missing a few things to make this experience really awesome. First, the names of our site sections are fairly generic. We aren’t exactly sure just from listening to the menu what might be in any of the elements. Second, some elements aren’t easily navigable. For instance, our sidebar components are all grouped under the label ‘complementary’.

We can add some well-thought out ARIA labels to make this experience even better.

Using Appropriate ARIA Labels

By peppering in some ARIA labels we can give the user an even more detailed conceptual map of our layout.

In this next iteration, I’ve added the following labels:

<nav class="main-navigation"> now has an aria-label of Primary Navigation.
<main class="content"> now has an aria-labelledby attribute of main-title and its <h1> has an id of main-title.
<aside class="sidebar"> now has an aria-labelledby attribute of sidebar-title and its <h2> has an id of sidebar-title.
Both <section> elements in the sidebar now have an appropriate ARIA label.

Let’s fire up VoiceOver again and pull up our Landmark menu with CAPS+U. Now we see that the ARIA labels we provided display next to each of our generic menu items. We also have a few extra menu items, because the <section> elements we provided labels for (Related Posts, Share Links), now have their own menu items.

Now an assistive technology user has an equal (and maybe even better) conceptual map of the content and actions they can take on this website compared to a non-assistive technology user. They can get a quick overview of everything on the site, easily navigate to the section of the page they want, and quickly find what they are looking for.

WCAG Techniques Used

Wrap Up

With a combination of well-structured HTML markup, thoughtful use of ARIA roles and a careful labeling of site sections using ARIA labels, we’re able to create a user experience for assistive technology users that rivals the experience of non-assistive technology users. We were able to take the conceptual map that was implicit in our visual layout and expose it to assistive technology.

You may find holes in your conceptual map or sections that unnecessarily have the same function. The process can help you clarify your designs, identify areas that might not make sense conceptually or visually, and improve your design for all users of your site.

Want to dive deeper into building accessible websites? Join my free email course: 📨 Common accessibility mistakes and how to avoid them. 30 days, 10 lessons, 100% fun! 😀 Sign up here!

A Short Guide to Screen Reader Friendly Code

Ben Robertson — Tue, 16 Oct 2018 13:00:00 +0000

If you want to have an accessible website you have to make sure it works with screen readers.

What is a screen reader, you ask? A screen reader is a piece of software that reads the contents of a computer screen out loud to a person and lets that person interact with the content via their keyboard.

Why does it matter?

Why must websites work with a screen reader? Screen reader software gives people with visual impairments access to the wealth of information on the internet. If you want to build the internet the way it was meant to be, then you want your websites to be accessible to as many people as possible. Web design after all, is so much more than just visual design.

Luckily, HTML is accessible to screen readers by default! Unfortunately, writing good HTML often falls by the wayside for a host of reasons. Most people don’t know better. I know I didn’t know any better when I got started as a web developer.

When we developers write bad HTML (and JavaScript, and CSS) it can render a website unintelligible, unusable and downright worthless to people who need a screen reader.

Want to up your accessibility game? Checkout my free email course: ✉️ Common accessibility mistakes and how to avoid them.

Since HTML is accessible to screen readers by default, using semantic HTML will go a long way in making any site usable for people who use screen readers. To ensure an excellent experience for people using screen readers, follow these five tips:

Pay attention to the title tag
Make sure your site is navigation-friendly
Every image needs an alt attribute
Role Attributes and Landmarks
Avoid click event listeners on <div> elements

1. Pay attention to the title tag

The title tag is the first thing a screen reader user will hear when they reach a page. It helps people know what the page is about, and whether they are in the right place. When they come back to the browser tab later, they will know what page they are on.

It may seem obvious, but title tags can get lost in the shuffle in a large project. A common mistake I see is setting a default title tag that is used on every page. This process causes every page to have the same title.

Imagine a user who is trying to compare several cars to decide which one to buy. They might have 15 tabs open, each containing reviews, make and model details, trim levels, and pricing information. Imagine if they all had the same title, how would they know which one to open? It can be so annoying especially if you are relying only on a screen reader to tell you the contents of a tab, so make sure all pages have an informative and unique title!

2. Make sure your site is navigation-friendly

Another important consideration is that screen readers provide different ways for users to navigate the website. A person using a screen reader may not even use your carefully constructed mega menu. In fact, if it’s not accessible, they probably won’t be able to. Let’s look at a few of the ways they might navigate a website instead:

Headings

One option is a list of headings. Heading tags form the outline of a web page, so they are a natural navigation method for screen readers to use. If you are using heading tags correctly and following correct nesting order (H2 under H1 only, H3 under H2 only, etc), then the outline of your site will be a clear overview of the content on the page. This order is why it is important to use heading tags as structural elements, not simply stylistic elements.

List of All Links

Another option is a list of links. Screen reader users can get a list of all links on the page, and then navigate through them, skipping all content that is not a link. This navigation process is one major reason to eliminate link text like “read more” or “click here”. If there are 50 links that say “read more”, a screen reader user navigating via the links menu is going to skip all of them because they have no context and are essentially meaningless.

Make sure the link text accurately reflects the linked content so people can find the content they are looking for, or use an aria-label to provide more contextual link content for screen readers.

Landmarks

Perhaps one of the neatest navigation options is the landmarks menu. Screen readers will interpret elements like <header>, <footer>, <main>, <aside>, and <nav> as landmark elements, and let users navigate directly to them. You can see how these landmarks are displayed and read to users in macOS VoiceOver below.

A thoughtful use of landmarks can give a website extra organization that will help people find information more easily. Beyond making the site more accessible, making decisions about using landmarks on a site can provide clarity about the true purpose of different elements on a site.

3. Every image needs an alt attribute

If an image is missing an alt (alternative text) attribute, screen readers will read the image file name. That can be very annoying for computer generated names like 201018acn300x450.jpeg.

If an alt attribute exists and has text in it, the text will be read. No need to include “Photo of” or “Image of”, the screen reader will indicate that it is an image.

If an alt attribute exists and is empty, the screen reader will skip this image entirely. If the image is not content, is purely decorative, and not important for understanding content or functionality, an empty alt attribute can be a good strategy.

4. Role Attributes and Landmarks

As was mentioned earlier, screen readers allow people to navigate via landmarks. Here is an example landmarks menu from a site that uses a combination of landmark elements, role attributes, and aria-labels to create a clean, easily understandable landmarks menu.

Take a <nav> element for example, which would be used to define navigation element. The screen reader will note to the user by default that this is a navigation element. This can be taken a step further and provide an aria-label (<nav aria-label=”Primary Menu”>) which will tell the user that this is the Primary Menu navigation.

In the example screenshot above, the Sidebar, Related Posts, Social Share Links, and Search sections of the page are labelled to make them more easily discoverable. It makes the entire site easier to understand and navigate.

5. Avoid click event listeners on `<div>` elements

A common pattern for interactive sites is to make the website do something when a user clicks on an element. Click on this text or button, and the menu expands. This functionality is accomplished with Javascript by listening for click events, like this:

const interactiveElement = document.querySelector('div.className');
interactiveElement.addEventListener('click', doSomething());

For screen readers, listening for clicks on HTML div elements can be detrimental because divs convey no semantic information to screen readers.

Here are the problems:

VoiceOver and other screen readers present them as a generic text element.
Users will not be able to tell that they can click on the element.
If a user is using their keyboard to navigate a page, they will never land on a <div> because it is not focusable. The div will never receive focus, and their browser will skip over it.
Also, there is another menu in voiceover that shows all the interactive buttons on the page. A div with a click event will not show up in this button menu.

In short, <div>s are inaccessible to screen readers.

There are workarounds for making divs more accessible, but the fastest route is to just use the HTML <button> element. When the <button> element is listening for click events you get all the functionality screen readers and keyboard users need to use that element: the screen reader will tell the user it’s a button, users can navigate directly to the button, and the button will have the same functionality with a mouse or a keyboard. The <button> element does a lot of the heavy lifting of making interactive elements accessible, so use them.

(Need help styling your buttons? Andy Bell’s Button Pal is a great CSS resource!)

It’s not too scary, right?

I hope you see from these 5 tips that starting on accessibility doesn’t have to be scary. For the most part, accessibility is about doing the simple things the right way. We want to make the web easier to use and understand for everybody, no matter what.

When you get to the bottom of it, this is the core of web accessibility, and really the driving principle of the web in general: ensuring that anybody can access, use, and understand the information, regardless of the method they use to interact with the internet.

Want to dive deeper into building accessible websites? Join my free email course: 📨 Common accessibility mistakes and how to avoid them. 30 days, 10 lessons, 100% fun! 😀 Sign up here!

4 Principles for Getting Started with Website Accessibility

Ben Robertson — Wed, 08 Aug 2018 16:34:50 +0000

When I was entering the front end developer ranks, no one talked to me about accessibility. I didn't know you could break the law for having an inaccessible website, until one day a university client came to my team to help them perform an accessibility audit. Man was I in over my head.

I started digging in and doing research, but found a lot of the documentation intimidating. Some of it was over my head, and there was so much to digest, but I eventually made my way through. (Well, I'm actually still making my way through).

I've since learned that accessibility doesn't have to be intimidating, and can even be fun.

What would have helped me at the beginning were a few practical principles to help me grasp the basics.

So let me share with you:

Ben's Homegrown Web Accessibility Principles

They're not rules.

They are mental shifts that I had to make when I started developing accessible websites.

Let's get into it.

Principle 1: Web Design is more than Graphic Design

When I started my first web job, I was handed a picture of a website and asked to turn it into a website.

After I did that, the designers then meticulously compared my website to their picture of a website and told me all the mistakes I made.

Line height should be 18px, not 16.

This gray is the wrong light gray. It should be light-light gray.

The box-shadow blur is off by a pixel.

Stuff like that. They were very impressive and I learned a ton.

But none of us really considered that the web is not a controlled medium. We were so concerned with the visual elements of the work, that we didn't consider how the site might perform on a $99 Android phone over 3G or for someone who was color blind, or someone who couldn't see at all.

And the fact that the web can be accessed by these people in those situations is what makes web design so much more than graphic design.

So instead of focusing merely on visual elements, I split my work into three main tasks.

Three Tasks of Web Design

Task 1: Write good (read: semantic) markup.

The first task is to write good markup.

This means organizing the content on the page well. Using HTML the way is was meant to be used. HTML is accessible by default. So if we get this right from the beginning our jobs are so much easier. We'll spend some more time on this a little later.

Task 2: Enhance the markup with CSS.

The second task is to use CSS to enhance the excellent markup that we have written.

CSS should be used to emphasize the meaning of your content. It should make it more meaningful, more impactful. But you've got to use the right HTML to begin with or else your job will be a lot harder.

Task 3: Layer interactivity on your HTML and CSS with JavaScript

And the third task is to layer interactivity over the structure and style with JavaScript.

Before and After

The difference between this approach and how I used to build websites is that I used to just reach for the element that was easiest to style, and use that.

I need big text, so I'll use an h1.

I have a complicated accordion interface, so I'll use a bunch of divs

Stuff like that. But that only focuses on the visual aspects. To build accessible websites, we need to think about more than just how closely the site matches the picture. It's more than visual design or graphic design. That's why we call it web design.

This brings us to principle 2.

Principle 2: Be ASAP: As Semantic as Possible.

Here's how I recommend doing this.

Every time you start typing <div>...

Stop.

Look in the mirror.

And ask yourself.

Could I use a more semantic element?

How do you know if there is a more semantic element to use?

The Mozilla Development Network has a page of all HTML elements organized by their purpose. (This reference is awesome - use it!)

Let's look at some of the semantic alternatives we have for <div>s.

Alternatives to `<div>`

If you have a stand alone section of a page, consider using the <section> tag.

If you have a blog, news article, forum post, or any kind of self-contained piece of content, you could use an <article>.

Got several components of the same kind next to each other? Consider using an ordered or unordered list (<ul> or <ol>).

Got a top section on your blog post with title and metadata? Use a <header>. Got a bottom section with tags and such? Use a <footer>.

Got a sidebar? Use an <aside>!

Got something that needs to be clickable - use a <button>. This one is important. If it needs to be clickable and is not a link, you should probably use a button.

Let me repeat that: If it needs to be clickable and is not a link, you should probably use a button. We'll talk more about that later.

Just remember: Be ASAP. As semantic as possible].

Principle 3: Web Sites Should Look Good Naked

What I mean by this is that if you remove all the CSS from your page, your website should still be readable and usable.

This principle is really driving home the point of principle 2: Be as semantic as possible.

Think about it like this: if your markup is semantic, then you are using elements that convey meaning. And that means the browser will provide affordances and signifiers for the meaning and / or functionality of your markup.

So the "naked test" is really a test of how semantic your markup is.

Your markup should look like a well-structured outline, like we used to make in school for research papers.

How do you check this?

Here is the code. If you pop this into your dev tools console, it will strip out everything from the <head> of your document, including the styles.

document.head.parentNode.removeChild(document.head);

What it's doing is targeting the document head and then removing all its children.

Most of the time, I use this as a little bookmarklet in my browser.

javascript:(function() {
   document.head.parentNode.removeChild(document.head);
})();

To use this as a bookmarklet, add a new bookmark in your browser. In the url field, copy and paste the code above instead of a URL. Now, you can click this bookmark while on any site and it will remove all the styles from the document head.

Let's look at an example of this in action.

The Google Sign-in form

I think everyone is likely familiar with the Google sign-in form. It's got a title, the email input, and a couple buttons for Forgot Email, Create Account, and Next.

So what happens when we look at it naked?

Naked Google Sign-in form

After we remove the styles, we still have the nice Sign in heading, so we know what this page is about.

We have a few inputs, but the labels aren't exactly clear.

And...where did our buttons go?

If you look closely, you can see that what used to be the "Next" and "Forgot Email" and "Create Account" buttons now all appear to be normal text.

We've got three inputs now, instead of the one we had before and the labels appear to be after them.

The Next and Create Account buttons swapped positions.

So everything is still here, but I'd say the main concern I have is with the buttons not really being buttons. They aren't clear.

And let me just say that just because Google isn't using the HTML <button> element doesn't mean this form is inherently inaccessible, it just means they have to do a lot more work with JavaScript and managing keyboard interactions that the browser would typically do for you.

I typically use the naked test as a gut check for myself. Just because a site fails the Naked Test doesn't mean the site is necessarily inaccessible. You can fail the naked test and still have an accessible website. But the Naked Test will reveal areas where you aren't using semantic markup, and these areas may need special accessibility attention.

What to look for during the Naked Test

Here is what I look for when I run this test.

First, I check to make sure the structure of the site makes sense. Are things in the right order? Does each section have a clear heading with the right level of heading tag?

Next, does the content appear to be organized? Can I skim the page and get an idea of the content as if I were skimming an outline?

Third, I look to see if interactive elements look to be interactive. If I've created a bunch of interactive elements using <div>s, they won't appear interactive. Then I'll know to spend a little more time checking the keyboard functionality of those elements for accessibility.

And lastly, I want to make sure inputs have clear labels.

That about sums up the naked test. To reiterate, the point of the test is to reveal weaknesses in the semantics of your site and point out the areas where you'll need to spend a little more time testing to make sure those components are accessible.

Principle 4: Talk to your computer

Here is my fourth and last homegrown principle: Talk to your computer.

Ok, maybe don't actually talk out loud to your computer. What I mean here is to communicate with your computer - give the browser some context using ARIA attributes.

ARIA Attributes

ARIA stands for Accessible Rich Internet Applications, and there are ARIA states, roles, and properties that tell the browser certain things about your web page, if you choose to use them.

I am suggesting that you use them where appropriate. They won't be visible to users, but they will be used by the browser and by screen-readers to provide a little extra context to users behind the scenes.

Here are some examples:

`aria-label`

The aria-label attribute can be added as an attribute of an HTML element to tell a screen reader what it is. I use these on links a lot, to provide extra context to screen reader users for where the link is going.

`aria-expanded`

The aria-expanded attribute tells whether an element is open or closed. You might use this on a hamburger button that controls your main navigation. When the screen reader user focuses on the button with an aria-expanded value of false, the screen reader will say something like "Main Menu, collapsed button" and they will know they can open the menu.

`aria-describedby`

The aria-describedby attribute points to an element that describes the current element. If you want to add some error text to an input, you might use this.

Here is an example:

<label for="example-input">Email</label>
<input type="email" id="example-input" aria-describedby="email-error" />
<div id="email-error">
    <p>The email address is in an invalid format.</p>
</div>

In this example, on form submit, the text "The email address is in an invalid format." is added dynamically to the div. When the input is focused, this message will be read aloud to screen readers.

`aria-live`

ARIA-live lets the computer know that an area of the page will be updated later. This is really handy with AJAX stuff. It can have a value of polite, aggressive, or off.

ARIA means extra context

Using these attributes, you are giving the browser extra context so it can have a better idea of what functionality a certain element may have and more context to users of screen readers and other assistive technologies.

The Principles: A Refresher

That wraps up my four simple principles.

Just to recap:

Principle 1 is that web design is more than graphic design.
Principle 2 is be as semantic as possible.
Principle 3 is that websites should look good naked.
Principle 4 is talk to your computer, use ARIA.

By minding these principles, you will be able to avoid a good chunk of the mistakes that are made by using non-semantic code concerned only with appearances.

And, if you want to see how to start putting these into practice, I'm launching a free email course: Common Website Accessibility Mistakes and How to Fix Them. Get access to the course by signing up here!

Lazy Loading Video Based on Connection Speed

Ben Robertson — Fri, 01 Dec 2017 14:00:00 +0000

A while back I was involved in redesigning the Up&Up website from the ground up. The team wanted to do one of those full-screen background videos on the home page. I wasn’t excited about it because the home page was already a little unwieldy with the large background images and some of the scroll-jacky things we are doing there.

In past versions of the site, we’ve had some very heavy videos in the background. (I’m embarrassed to say, there was once a day we had a 40mb background video.) For this version, I wanted to make the site as performant as possible, so I got curious about how I could treat the background video as a progressive enhancement for users on connections that could handle a potentially large download. I made sure to emphasize to our team the importance of a small, compressed video file, but I also wanted some programmatic magic to happen too.

Here’s a breakdown of the solution I ended up with:

Try loading the <source> with JavaScript
Listen for the canplaythrough event.
Use Promise.race() to timeout the source loading if the canplaythrough event doesn’t fire within 2 seconds.
Remove the <source> and cancel the video loading if we don’t detect the canplaythrough event.
Fade the video in if we do detect the canplaythrough event.

The Markup

The main thing to note in my video markup is that even though I am using the <source> elements inside the <video>, I have not set the src attribute for either of the sources. If you set the src attribute, the browser automatically finds the first <source> it can play and immediately starts downloading it.

Since the video is a progressive enhancement in this example, we don’t need or want the video to load by default. In fact, the only thing that will load is the poster, which I have set to be the featured image of the page.

<video class="js-video-loader video-autoplay--reduce-motion" poster="<?= $poster; ?>" muted="true" loop="true">
    <source data-src="path/to/upup_homepage_loop.webm" type="video/webm">
    <source data-src="path/to/upup_homepage_loop.mp4" type="video/mp4">
</video>

The JavaScript

I wrote a small JavaScript class that looks for any video that has a .js-video-loader class on it so that we could reuse this logic in the future for other videos.

Here’s the constructor:

constructor () {
    this.videos = Array.from(document.querySelectorAll('video.js-video-loader'));

    if(!this.videos || window.innerWidth < 992) return;

    this.videos.forEach(this.loadVideo.bind(this));
}

What we are doing in here is finding all the videos on the page that we want to lazy load. If there are none, we can return. The video was also having conflicts with some of the more intense scroll-jacking stuff we were doing on the homepage, so I’m also returning for small screens. (I’m thinking now I could have done this with media queries in the <source> elements, but I’m not sure.)

Then I run our video loading logic for each video.

loadVideo() is a small function that calls some other functions:

loadVideo(video) {
    this.setSource(video);

    // Reload the video with the new sources added.
    video.load();

    this.checkLoadTime(video);
}

setSource() is where we find the sources that we included as data attributes and add them as proper src attributes.

 

/**
 * Find the children of the video that are <source> tags.
 * Set the src attribute for each <source> based on the
 * data-src attribute.
 *
 * @param {DOM Object} video
 */

setSource (video) {
    let children = Array.from(video.children);
    children.forEach(child => {
        if (
            child.tagName === 'SOURCE' &&
            typeof child.dataset.src !== 'undefined'
        ) {
            child.setAttribute('src', child.dataset.src);
        }
    });
}

Basically what I am doing is looping through each child of the <video> element. I only want to find children that are <source> elements and that have a data-src attribute defined (child.dataset.src). If both of those conditions are met, we use setAttribute to set the src attribute of the source.

Now that video element has its sources set, we need to tell the browser to try loading the video again. We did this above in our loadVideo() function, with video.load(). load() is part of the HTMLMediaElement API that resets the media element and restarts the loading process.

Next up is where the magic happens. In checkLoadTime() I create two Promises. The first Promise resolves when the <video> element fires the canplaythrough event. This event is fired when the browser thinks it can play the media without stopping to buffer. To do this, we add an event listener in the Promise, and resolve() only if the event is triggered.

// Create a promise that resolves when the
// video.canplaythrough event triggers.
let videoLoad = new Promise((resolve) => {
    video.addEventListener('canplaythrough', () => {
        resolve('can play');
    });
});

We also create another promise that functions as a timer. Inside the Promise, we use setTimeout to resolve the Promise after an arbitrary time limit. For my purposes, I set a timeout of 2 seconds (2000 milliseconds).

// Create a promise that resolves after a
// predetermined time (2sec)
let videoTimeout = new Promise((resolve) => {
    setTimeout(() => {
        resolve('The video timed out.');
    }, 2000);
});

Now that we have two Promises, we can race them against each other to find out which one finishes first. Promise.race() accepts an array of promises and we pass in the promises we created above to this function.

// Race the promises to see which one resolves first.
Promise.race([videoLoad, videoTimeout])
.then(data => {
    if (data === 'can play') {
        video.play();
        setTimeout(() => {
            video.classList.add('video-loaded');
        }, 3000);
    } else {
        this.cancelLoad(video);
    }
});

In our .then() we are looking to receive the data from the Promise that resolves first. I send the string ‘can play’ through if the video can play, so I am checking against that to see if we can play the video. video.play() uses the HTMLMediaElement play() function to trigger the video to play.

The setTimeout() function adds the `.video-loaded’ class after 3 seconds to help the finesse the fade-in animation and the autoplay loop.

If we don’t receive the can play string, then we want to cancel the loading of the video.

The cancelLoad() method basically does the opposite of our loadVideo() function. It removes the src attribute from each <source> and then triggers video.load() to reset the video element.

If we didn’t do this, the video would keep loading in the background even though we aren’t displaying it.
`

// Cancel the video loading by removing all
// source tags and then triggering video.load().
cancelLoad (video) {
    let children = Array.from(video.children);
    children.forEach(child => {
        if (
            child.tagName === 'SOURCE' &&
            typeof child.dataset.src !== 'undefined'
        ) {
            child.parentNode.removeChild(child);
        }
    });

    // reload the video without source tags so it
    // stops downloading.
    video.load();
}

The downfall of this method is that we are still attempting to download a potentially large file over a potentially poor connection, but by providing a timeout, I’m hoping to save data and recoup some performance for users on slow connections. In my tests in the Chrome Dev Tools throttled down to a Slow 3G connection, this logic ends up loading <512kb of the video before the timeout fires. Our current video loop is 3-5mb depending on if you are loading the webm or mp4, so this is still a significant savings for users on a slow connection.

Caveats

I’m pretty new to working with Promises, so this logic could probably be better, and I’m sure there’s things I’m doing with resolve() (and not doing with reject()) that I should or could be doing.

How to Write Accessible JavaScript

Ben Robertson — Thu, 05 Oct 2017 12:00:00 +0000

You’re wrapping up a web project and just as you’re putting the finishing touches you get sent a list of accessibility errors forwarded to you by your project manager.

Inadequate color contrast.

Missing alt tags.

This interactive component needs to be keyboard accessible.

We might not like to admit it but we’ve all been there: at the end of a project trying to reverse engineer accessibility into our site. It’s frustrating for developers, designers, project managers and clients.

While accessibility can be frustrating, you can set yourself, your team, and your client up for success by planning for accessibility from the beginning. Here are 4 techniques to save you time and trouble when building accessible JavaScript-enabled websites and applications.

Use the <button> element for anything that users click on.
Plan for Common Keyboard interactions.
Manage ARIA states
Managing Focus

1. Use the `<button>` element for anything that users click on.

In general, using semantic HTML elements will be a boon to the accessibility of your web project. When working with interactivity, the <button> is the semantic tag for things users are clicking on that aren’t links or other inputs. It is a semantic way to denote that an element is clickable and will be your new best friend.

The HTML <button> element represents a clickable button.

- Mozilla Developer Network

When you use the <button> element for interface elements that are clickable and bind click event listeners to those buttons, you get a lot of functionality for free.

First, buttons are automatically focusable ; they are in the tab index of a page. If a user lands on your site and is only using a keyboard, they can press the tab key to cycle through all the focusable elements, including hyperlinks and buttons, on your page.

Second, screen readers will announce to a user that a button is in focus. Screen reader users know by default that button elements are interactive. This makes it especially important to include clear, understandable text inside your <button> so all users can understand what clicking it will do. There are also some helpful aria attributes you can add to your button, but we’ll get to that later.

Third, when you add a click event listener to a <button> element, you get keyboard accessibility for free. This means can write less JavaScript when you use the <button> element. By contrast, if you add a click event listener to a div, you would also have to add keyup listeners for the spacebar and enter keys in order to make that element accessible to keyboards. With the button element, the default keyboard actions (spacebar and enter) and screen reader click actions trigger the click event. You don’t have to write extra keyboard listeners.

To sum up: if a user is clicking on it and it’s not a link or some kind of input, just use a <button>.

2. Plan for Common Keyboard interactions.

For more complex interactive components, there are likely several interactive elements in the component. Pay attention to what kind of event listeners you are adding to the DOM, and consider whether these actions be able to be triggered by the keyboard.

For instance, is there a close or minimize button on your component? The ESC key should probably be able to trigger the close as well. Is there some sort of horizontal scroll-type action or Next / Previous buttons? Consider binding events to the arrow keys.

Common interactions can include:

Exiting the current component
Submitting
Moving position / browsing

Common keys to add actions to:

enter (keyCode 13)
spacebar (keyCode 32
arrow keys (37 - 40)
ESC (keyCode 27)
tab (keyCode 9)

How do you bind actions to specific keys? You can do it by adding an event listener to the keyup event. When you pass the event into your callback function, you have access to the keyCode property, and you can trigger actions depending on the keyCode. I have a hard time remember the keyCodes, so often during development I’ll add an event listener that logs all keyCodes to the console so that I can find the ones I need to use:

document.addEventListener('keyup', (event) => {
    console.log(event.keyCode);
});

To make things a little bit easier though, I’ll document the most common keycodes I end up needing to reference. Here is a common pattern I end up using in components, with the most common keyCodes that I use:

document.addEventListener('keyup', (event) => {
    switch (event.keyCode) {
        // escape
        case 27:
            // exit
            break;
        // enter || spacebar
        case 13 || 32:
            // submit or something
            break;
        // left arrow
        case 37:
            // move back / previous
            break;
        // right arrow
        case 39:
            // move forward
            break;
        // up arrow
        case 38:
            // move up
            break;
        // down arrow
        case 40:
            // move down
            break;
       }
}

I don’t use all of these in every situation, but they are the ones I use most frequently.

Something else you’ll want to keep in mind is that you’ll often want to add these event listeners conditionally: only when a certain component is active or in use by the user. Otherwise you may have actions being triggered at the wrong time if all of your event listeners are in the global scope.

To add these conditionally, I usually have a function that handles all the keyup logic (with the creative name this.handleKeyup()). When my component is activated, I add an event listener with that function as the callback. When my component is disabled, I fire a removeEventListener() with that same function as the callback. That way, you can trigger different actions with different keys depending on what the user is doing at the moment.

You can take this to another level and test whether the user was also holding down the shift key by testing if event.shiftKey === true. You might do this is you are trying to trap focus inside of a modal and want to prevent users from SHIFT+TABing backwards out of a modal.

3. Manage ARIA states

There’s a lot to the Web Accessibility Initiative’s Accessibility of Rich Internet Applications (WAI-ARIA, or just ARIA) spec, but when you’re getting started with interactive JavaScript you should really focus on the aria-expanded attribute.

A lot of interactivity is focused on showing or hiding content on the page. The aria-expanded property “indicates whether the element, or another grouping element it controls, is currently expanded or collapsed,” according to the W3C spec.

You’ll want to make sure that your element renders with the appropriate aria-expanded attribute: false if the element is not expanded, true if the element is expanded. This attribute should be applied to the element that controls the expandable element. If the grouping element is a child of the controlling element, you don’t need to do anything special, but if you have a <button> that is going to control a sibling <ul>, you will need to indicate that that the button controls the list with the aria-controls attribute (aria-controls documentation at W3C). This attribute accepts an ID or list of IDs that are controlled by the interactive element. In our example, our markup would look like this:

<button class="list-expander" aria-expanded="false" aria-controls="expandable-list-1">Expand List</button>
<ul id="expandable-list-1">
    <li><a href="http://example.com">Sample Link</a></li>
    <li><a href="http://example.com">Sample Link 2</a></li>
    <li><a href="http://example.com">Sample Link 3</a></li>
</ul>

Now we need to toggle the expanded state. The way I normally do this is with the setAttribute() method.

const listExpander = document.querySelector('.list-expander');
const list = document.querySelector('#expandable-list-1');
listExpander.addEventListener('click', (e) => {
    if(list.getAttribute('aria-expanded') === "true") {
        list.setAttribute('aria-expanded', 'false');
    } else {
        list.setAttribute('aria-expanded', 'true');
    }
});

Note that when I check to see the value of the aria-expanded attribute, I use === "true". That’s because getAttribute returns either the string "true" or "false", not an actual true or false value. (That tripped me up at first).

You can use this same kind of thinking with other true / false ARIA attributes. Most commonly, I use this with aria-hidden for showing and hiding modal dialogs.

4. Managing Focus

The last thing we’ll cover in this guide is managing focus. Focus refers to the singular element in the browser that is able to be acted upon via the keyboard. Elements often receive focus when a user clicks on them, uses the TAB key to cycle through focusable elements, or uses a screen reader. At a basic level, you need to make sure that users can visually tell at any time what element is in focus.

The most common place that I end up managing focus is in modal components.

Here’s a sample problem we need to solve. We have an about page that contains a bio of a person and a button that says “Contact this person”. This button opens a modal that contains a contact form. But if the form is not in the natural tab order of the page (as is common with modals), when the user hits tab their keyboard focus is behind the modal. It’s common for keyboard and assistive technology users to get stuck and frustrated with poorly designed modals.

To solve this, we want to do a couple of things:

When the modal opens, move the focus to the first focusable element inside the modal.
Ensure that users can easily close the modal via the keyboard when it is open.
When the modal closes, return focus to the element that was active when the modal opened.
If we want to be really careful, we can trap the TAB forward and backwards inside the modal so users can’t escape unless they close the modal.

Get the first focusable element.

I have a few helper methods to help me determine all focusable elements and the first focusable element in a given context. Here’s how I find all focusable elements on the page (h/t to Chris Ferdinandi).

/**
 * Get all focusable elements inside of the specifed context.
 *
 * @param {String} [context='document'] The DOM context you want to search in.
 * @return {Array} Array of focusable elements
 */
function getFocusable(context = 'document') {
    let focusable = Array.from(context.querySelectorAll('button, [href], select, textarea, input:not([type="hidden"]), [tabindex]:not([tabindex="-1"])'));
    return focusable;
}

This function uses querySelectorAll with a list of selectors that are normally focusable: <button>, links with an href attribute, inputs, and things that have a tabindex set (that is not -1). I also am filtering the <input> selector by removing any input that is hidden, since those aren’t focusable. I do the same kind of filtering for elements with a tabindex attribute set to -1, since those elements should only be focusable via JavaScript method, not in the normal tab index. I use Array.from to create an array from the NodeList returned by querySelectorAll.

What I like about this function is that I can also pass in a context. By default, the context is set to document, so it will find all focusable elements in the document. But in our modal example above, you could pass in the modal element itself as the context and get a list of all focusable elements in the modal 😎.

Finding the first focusable element is trivial now, it’s a matter of popping off the first element in our array. I typically have another helper function to get me the first focusable element, and don’t actually call that first one directly. It is like this:

/**
 * Get the first focusable element inside of the specified context.
 *
 * @param {String} [context='document'] The DOM context you want to search in.
 * @return {Object} A DOM element
 */
export function getFirstFocusable(context = 'document') {
    let focusable = getFocusable(context);
    return focusable[0];
}

You pass in a context and it calls our original getFocusable() function and returns the first item in the array. Now we can call focus() on that element to programmatically focus the first focusable element. It would look like this:

getFirstFocusable(modal).focus();

Ensure that users can easily close the modal via the keyboard when it is open

We’ve partially addressed this earlier when we discussed planning for common keyboard interactions. This is a perfect example of time when you want the user to be able to ESC out of a component.

You might also add an overlay between the modal and the site content that is clickable and focusable with click events that close the modal.

When the modal closes, return focus to the element that was active when the modal opened.

In our example, the user clicked on a button and then their focus jumped to the modal. When they close the modal, we want to return their focus to the button that triggered the modal. This is actually pretty trivial using the document.activeElement property.

When we detect that a modal should open and before we transfer the focus to that modal, we can save the current active element to a variable like this:

let previousActiveElement = document.activeElement;

Then we can transfer focus to our first focusable element, and whenever a user is done with the modal and decides to close it we transfer the focus back to our saved element:

previousActiveElement.focus();

And now the user is back where they started!

Trap the TAB and SHIFT + TAB inside the modal

As I mentioned above, if we want to be really careful, we can trap the TAB forward and backwards inside the modal so users can’t escape unless they close the modal.

To do this, we need to listen to the keyup event while the modal is active, and here’s the function I use to trap the focus (it depends on our getFocusable() function from above:

/**
 * Traps the tab key inside of the context, so the user can't accidentally get
 * stuck behind it.
 *
 * Note that this does not work for VoiceOver users who are navigating with
 * the VoiceOver commands, only for default tab actions. We would need to
 * implement something like the inert attribute for that (see https://github.com/WICG/inert)
 * @param {object} e the Event object
 */
export function trapTabKey(e, context) {
    if (e.key !== 'Tab') return;

    let focusableItems = getFocusable(context);
    let focusedItem = document.activeElement;

    let focusedItemIndex = focusableItems.indexOf(focusedItem);

    if (e.shiftKey) {
        if (focusedItemIndex == 0) {
            focusableItems[focusableItems.length - 1].focus();
            e.preventDefault();
        }
    } else {
        if (focusedItemIndex == focusableItems.length - 1) {
            focusableItems[0].focus();
            e.preventDefault();
        }
    }
}

First, we need to pass in the event object so we can detect what key is being pressed and a context for the user to be “trapped” inside of.

If the key they pressed was not the TAB key, we can safely return and do nothing.

If it was the TAB key, we get all the focusable elements in the modal and the element they are currently focused on. Once we have these two things, we can use the indexOf method to tell where the user is in the tab order of this context.

If they were holding the shift key (e.shiftKey === true), they were going backwards, so we want to stop them when they get to the first focusable item in the modal and focus on the last focusable item: focusableItems[focusableItems.length - 1].focus().

If they were going forward and got to the last focusable item in the modal (focusedItemIndex == focusableItems.length - 1), we need to focus the first focusable item.

We need to call e.preventDefault() for both of these cases to prevent the default TAB function from firing. For all other instances though, we can let them TAB normally.

You’ll want to make sure you remove your keyup event listener when the user closes the modal to let their TAB functionality return to normal.

Conclusion

We’ve covered a lot here, but it should be a really good start for you to start developing accessible interactive JavaScript sites and applications and give you a framework for thinking about how you might program other widgets and components. Remember to:

Use <button> for clickable elements
Plan for common keyboard interactions like ESC, Arrows, Enter and TAB.
Think about and manage any appropriate ARIA states.
Manage focus when necessary.

Keeping these techniques in mind from the beginning will save you time and trouble and your users will thank you!

PS: If you want even more accessibility tips, I'm launching a free email course: Common Website Accessibility Mistakes and How to Fix Them. Get access to the course by signing up here!

DEV Community: Ben Robertson

The Sneaky Total Blocking Time Issue That PageSpeed Insights Didn’t Catch

Digging into PageSpeed Insights

Digging Deeper with DevTools

The Fix

But why was the SVG causing 100s of Total Blocking Time?

Takeaways

Web Performance Resources for Front End Developers

Resources for getting started

Courses

Advanced Topics

Books

Tools

Popular libraries

Other Resources

Color Swatches in Storybook

Exporting SCSS variables for use in JavaScript

Computing color names

Grouping colors

The components

The Myth of Inaccessible React

Tools and Setup

Usage

Add a pre-commit hook for preventing inaccessible code in the codebase using lint:staged

Usage

react-axe

Usage

Storybook and Accessibility

Setup

Wrap up

The Cover Letter that Got Me a Remote Front End Developer Job

The Letter

Anatomy of the Cover Letter

Greeting

First Paragraph: Introduction and Establishing Credibility

Second Paragraph: Highlight some accomplishments

Third Paragraph: More soft skills

Fourth Paragraph: Brief summary and close

Wrap up

Looking for a new job?

Designing Layouts for Screen Readers

Initial Layout

Skip Link

WCAG Techniques Used

ARIA Roles and Landmarks

- Preview the updated layout

WCAG Techniques Used

Using Appropriate ARIA Labels

WCAG Techniques Used

Wrap Up

A Short Guide to Screen Reader Friendly Code

Why does it matter?

1. Pay attention to the title tag

2. Make sure your site is navigation-friendly

Headings

List of All Links

Landmarks

3. Every image needs an alt attribute

4. Role Attributes and Landmarks

5. Avoid click event listeners on <div> elements

Here are the problems:

It’s not too scary, right?

4 Principles for Getting Started with Website Accessibility

Ben's Homegrown Web Accessibility Principles

Principle 1: Web Design is more than Graphic Design

Three Tasks of Web Design

Task 1: Write good (read: semantic) markup.

Task 2: Enhance the markup with CSS.

Task 3: Layer interactivity on your HTML and CSS with JavaScript

Before and After

Principle 2: Be ASAP: As Semantic as Possible.

Alternatives to <div>

Principle 3: Web Sites Should Look Good Naked

How do you check this?

The Google Sign-in form

Naked Google Sign-in form

What to look for during the Naked Test

Principle 4: Talk to your computer

ARIA Attributes

aria-label

5. Avoid click event listeners on `<div>` elements

Alternatives to `<div>`

`aria-label`

`aria-expanded`

`aria-describedby`

`aria-live`

1. Use the `<button>` element for anything that users click on.