DEV Community: Lindsey Kopacz

Creating an Accessible Range Slider with CSS

Lindsey Kopacz — Mon, 04 May 2020 14:15:22 +0000

Originally Posted on www.a11ywithlindsey.com.

I’ve always loved exploring how to make semantic, accessible elements aesthetically pleasing. And yes, it is possible. Challenging myself to do this has improved my CSS skills.

Today we are going to talk about input[type="range"]. These inputs where you select a value from a slider that has a thumb on it. You start with HTML that looks like this:

<div class="wrapper">
  <input type="range" min="0" max="100" />
</div>

Selecting a purpose for an input range slider has many possibilities. You could use it for volume decibel. You could use it for an audio player. You could use it in a survey when rating from 1-10. Many times, when people make these features custom, they don't think to use the semantic features. They make a bunch of divs, and don't think about the keyboard or screen reader accessibility.

Considerations

Today I am going to be playing around with CSS to show you some of the possibilities. A lot of what I do in this post is a form of exploration. I learned a lot about linear-gradient from research for this post, and we’ll be going over how I perceived it.

When I go through these steps, I am considering the following:

Browser support - I don't talk about browser support often. But according to the POUR principles, your site and application must be robust. In the post, we’ll be going over many pseudo-elements for robust browser support.
Providing a fallback - linear-gradient isn't always supported. It looks neat, but we have to ensure we have a clear way of presenting the range even if it's not possible
Don't use JavaScript to hack - just because you can doesn't mean you should.

Starting out

When we first create that HTML, the appearance is pretty unimpressive.

The first thing we want to do is start with a clean slate in our CSS. We are going to add a position: relative; on our wrapper class. Then we add an appearance: none; to our range input. If you check out the Mozilla docs, prepending -webkit- should cover us for Firefox, Chrome, and edge.

.wrapper {
  position: relative;
  margin: 1rem;
}

input[type='range'] {
  -webkit-appearance: none;
}

There are a few things that I am going to “normalize” before I start going into the pseudo-elements. I am adding a width and a transparent background. For this particular item, I am going to add a max-width as well.

input[type='range'] {
  -webkit-appearance: none;
  max-width: 7rem;
  width: 100%;
  background: transparent;
}

Browser Specific Pseudo Elements

You'd think that you could just add a bunch of properties like height, background color, and margin, like this:

input[type='range'] {
  -moz-appearance: none;
  -webkit-appearance: none;
  max-width: 7rem;
  width: 100%;
  margin: 0;
  height: 0.9rem;
  background: #464646;
}

However, if you use something like BrowserStack, you'll see something like this in IE11.

Depending on what your analytics say for your audience's browser usage, this may be moot. And take that knowledge and apply it how you please. But I believe in robust browser support, so I’m going to cover the following pseudo-elements:

::-webkit-slider-runnable-track
::-moz-range-track
::-ms-track

Note: if you want to use these pseudo-elements, you have to create the selectors separately. That’s because if a browser isn’t supported, it’ll ignore the entire block.

input[type='range']::-webkit-slider-runnable-track {
  height: 0.9rem;
  margin: 0;
  width: 100%;
  cursor: pointer;
  background: #464646;
}

input[type='range']::-moz-range-track {
  height: 0.9rem;
  margin: 0;
  width: 100%;
  cursor: pointer;
  background: #464646;
}

input[type='range']::-ms-track {
  height: 0.9rem;
  margin: 0;
  width: 100%;
  cursor: pointer;
  color: transparent;
  background: #464646;
}

input[type='range']::-ms-fill-lower {
  background: transparent;
}

In Chrome:

In Firefox:

In Edge:

In IE11:

The main difference between the properties inside the blocks is the ::-ms-track pseudo-element needs a color: transparent. We also need to have a ::-ms-fill-lower otherwise it looks like this:

When we add all these in, we have a starting out point for our volume slider:

Now we get to play around with the part I explored the most - linear gradient.

Using linear-gradient

Linear gradient confused me for the longest time. Because I focus on accessibility more than CSS, I never learned all the fun CSS functions. I want a volume bar that shows a triangle going from the lowest step to the highest step while giving a screen reader user the ability to control volume decibel.

Our goal would be to have something that looks similar to this:

linear-gradient is a CSS function that transforms a background from one or many colors into another. This function takes on many arguments and can be very simple or very complex.

From the most basic standpoint, here is what to consider when you're creating a linear gradient:

The angles and the direction of the gradient
What colors you want in the gradient.
What percent points you want the "fade" to start and stop. More formally, we call these color stops.

I have a few examples that I played with that I show in the following CodePens.

First a rainbow:

A few of my observations:

If there's no direction or angle specified, it assumes a horizontal (0deg) angle and top to bottom direction.
If you don’t specify where the colors stop, the gradient assumes even distribution.

Now a French Flag:

My first observation: I associate linear gradients as fades. But if you want a straight line, you have to put the “stop” to be at equal values.

.flag--fr {
  background: linear-gradient(
    /* The gradient is going toward the right */
    to right,
    /* It starts at blue and stops in full opacity at 33% */
    blue 33%,
    /* White starts in full opacity at 33% */
    white 33%,
    /* White ends in full opacity at 66% */
    white 66%,
    /* Red starts in full opacity at 66%
    and will continue till the background is over */
    red 66%
  )
}

What if we want to start playing with fades and make it more blurry?

There is a gap between the stops at full opacity, and in between that gap, there is a fade. Fun stuff!

.flag--fr {
  background: linear-gradient(
    to right,
    /* Blue stops at 27%, starts to
    fade into the next color */
    blue 27%,
    /* White starts at 33% */
    white 33%,
    /* White stops at 66%, starts to
    fade into next color */
    white 66%,
    /* Red starts at 73% */
    red 73%)
}

I'm still a complete newb to this stuff, so I bet I am missing many details. But this is my "explain like I'm five" version of this.

So, this feels like a tangent, but I promise it's not. We are going to use what we learned to create a volume range. We want to visually indicate that the volume is getting higher when we increase the range value. So we are going to take the code we were using at the end of the Starting Out section, and add a linear-gradient to it. Remember, these lines won't be blurry. We'll need to make sure that the percentage of the gradient matches.

input[type=range]::-webkit-slider-runnable-track {
  height: 0.9rem;
  margin: 0;
  width: 100%;
  cursor: pointer;
  background: #464646;
  background: linear-gradient(
    to bottom right,
    transparent 50%,
    #464646 50%
  );
}

input[type=range]::-moz-range-track {
  height: 0.9rem;
  margin: 0;
  width: 100%;
  cursor: pointer;
  background: #464646;
  background: linear-gradient(
    to bottom right,
    transparent 50%,
    #464646 50%
  );
}

input[type=range]::-ms-track {
  height: 0.9rem;
  margin: 0;
  width: 100%;
  cursor: pointer;
  color: transparent;
  background: #464646;
  border: 0;
  background: linear-gradient(
    to bottom right,
    transparent 50%,
    #464646 50%
  );
}

Now, this looks like a right triangle, with the 90degrees mark being at the bottom right-hand corner.

My SCSS linter will yell at me about having 2 background properties. But I like having the background as a solid color as a fallback. If the browser doesn’t support linear-gradient, we have a browser fallback.

Designing the thumb

Now, with my goal, I want the thumb to be narrow and taller. CSS wise, this is relatively simple. Here’s the list of the pseudo-elements to make sure the thumb works across browsers:

::-webkit-slider-thumb
::-moz-range-thumb
::-ms-thumb

Again, we have to separate these all out into their separate selectors, the same as the track.

We want to set the -webkit-appearance: none; and set height, width, border, and background. For Chrome, we add a negative margin-top to balance out the positioning. The rest have no margin-top.

input[type='range']::-webkit-slider-thumb {
  -webkit-appearance: none;
  height: 1.5rem;
  width: 0.5rem;
  background: #ffffff;
  border: 1px solid;
  margin-top: -5px;
}

input[type='range']::-moz-range-thumb {
  -webkit-appearance: none;
  height: 1.5rem;
  width: 0.5rem;
  background: #ffffff;
  border: 1px solid;
  margin-top: 0;
}

input[type='range']::-ms-thumb {
  -webkit-appearance: none;
  height: 0.75rem;
  width: 0.5rem;
  background: #ffffff;
  border: 1px solid;
  margin-top: 0;
}

Now we will see the track is tall and white with a black border.

Now we can just round out the edges and add a pointer cursor.

input[type='range']::-webkit-slider-thumb {
  -webkit-appearance: none;
  height: 1.5rem;
  width: 0.5rem;
  background: #ffffff;
  border: 1px solid;
  margin-top: -5px;
  border-radius: 3px;
  cursor: pointer;
}

input[type='range']::-moz-range-thumb {
  -webkit-appearance: none;
  height: 1.5rem;
  width: 0.5rem;
  background: #ffffff;
  margin-top: 0;
  border-radius: 3px;
  cursor: pointer;
}

input[type='range']::-ms-thumb {
  -webkit-appearance: none;
  height: 0.75rem;
  width: 0.5rem;
  background: #ffffff;
  border: 1px solid;
  margin-top: 0;
  border-radius: 3px;
  cursor: pointer;
}

The source that helped me out a lot with this section: CSS Tricks

Adding custom focus states

I want to remove the focus styles (gasp!) from the entire input, and put it on the thumb itself. I couldn't figure out how to get rid of it on Firefox, so if you know, tweet at me and let me know!

I am going to remove the outline on the entire input, and instead all box shadows to the input range on focus:

input[type='range']:focus {
  outline: none;
}

input[type='range']:focus::-webkit-slider-thumb {
  box-shadow: 0px 0px 7px 3px #0065c4;
}

input[type='range']:focus::-moz-range-thumb {
  box-shadow: 0px 0px 7px 3px #0065c4;
}

input[type='range']:focus::-ms-thumb {
  box-shadow: 0px 0px 7px 3px #0065c4;
}

When it gets hairy

If you want the area between the thumb and the start of the range to be a different color, it can begin to get complicated. This differentiation indicates progress, not to be confused with the progress element.

Unfortunately, using pseudo-elements, we only have support for Edge, IE, and Firefox. There is the pseudo-element ::-ms-fill-lower and ::-moz-range-progress, but none for Chrome. I’ve played with doing this in JavaScript, but it sounds like a performance nightmare and too much math.

You can check out the CodePen where I use these pseudo-elements.

Conclusion

Thanks for reading and learning with me! I hope I've helped you explore and also realize that aesthetic and accessibility are not mutually exclusive. You just have to take some time and think it through.

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on Patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Take my 10 days of a11y free email course.
Be the first to learn about my posts for more accessibility funsies!

Cheers! Have a great week!

How Accessibility Taught me to be Better at JavaScript - Part Two

Lindsey Kopacz — Tue, 21 Jan 2020 18:26:00 +0000

Originally Posted on www.a11ywithlindsey.com.

Content Warning: There are gifs in this post.

Hey friends! Today's writing is going to be a follow up to How Accessibility Taught Me to be Better At JavaScript. If you have read my content, one of my favorite topics is about JavaScript and Accessibility. I speak about how JavaScript is actually necessary to make interactive elements accessible.

In my previous article, I talked about how I created a popup language menu with accessibility in mind. Making something functional and accessible was my first taste of vanilla JavaScript. The code certainly needed improvements, which we went over in the post. However, making the menu accessible started to help me understand JavaScript better.

Today we are going over how I took some cringy “accordion” markup and made it accessible. Remember, an essential requirement was that I was not allowed to alter the content markup in any way. This page was a WordPress post, meaning I couldn’t go in and edit the post to be the markup I wanted it to be.

Starting out

So, this right here was the starting markup.

I like clean HTML, and the inability to alter the markup got under my skin. This markup is a mess. First, it started with an unordered list, which isn’t the worst, but not ideal. Then inside the list item, it has a span for the title of the panel, an h3, another unordered list element, then a singular list item (meaning it’s not even a list?).

I detest this markup so much.

Now that I finished that soapbox, let's talk about a few goals here:

Hide the panels when we load the page
Accordion panels open and close on click.
Accordion panels open and close using the space bar or the enter key.
Make that span focusable

I added a little bit of SCSS to clean up the markup. I also added normalize.css in my CodePen settings.

Now let's get on to how I approached this problem 4 years ago.

How I approached the problem

As a disclaimer, this is what Lindsey 4 years ago did. There's only one thing I wouldn't do; however, even so, I would add more to this code, which I do in the next section.

First, let's grab some variables:

const accordion = document.getElementById('accordion')

Then, let's make a conditional statement. If that accordion exists, let's grab some other variables.

if (accordion) {
  const headers = document.querySelectorAll('.accordion__header')
  const panels = document.querySelectorAll('.accordion__panel')
}

I added the conditional statement because we loop through that nodeList. I don’t want to be adding event listeners on null

Now let's add the event listener

if (accordion) {
  const headers = document.querySelectorAll('.accordion__header')
  headers.forEach(header => header.addEventListener('click', toggleAccordion))

  const panels = document.querySelectorAll('.accordion__panel')
}

Then, let's add that function where the .accordion__header represents this and the .nextElementSibling is the .accordion__panel

function toggleAccordion() {
  this.nextElementSibling.classList.toggle('visually-hidden')
}

If we go to the element inspector and click on the accordion item, we notice the class toggle.

Then let's add the visually-hidden class in the SCSS (source: The A11y Project):

.visually-hidden {
  position: absolute !important;
  height: 1px;
  width: 1px;
  overflow: hidden;
  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
  clip: rect(1px, 1px, 1px, 1px);
  white-space: nowrap; /* added line */
}

Now let's add the visually-hidden class to the panels, so it visually toggles.

if (accordion) {
  const headers = document.querySelectorAll('.accordion__header')
  headers.forEach(header => header.addEventListener('click', toggleAccordion))

  const panels = document.querySelectorAll('.accordion__panel')
  panels.forEach(panel => panel.classList.add('visually-hidden'))
}

If you’re not thinking about accessibility, you may only add a click event and call it a day. Because these are not buttons, we have to add keypress events. We need to replicate the functionality of a button. This reason is why using semantic HTML is the best way to help accessibility.

First, we have to add a tabindex of 0 to every header.

if (accordion) {
  const headers = document.querySelectorAll('.accordion__header')
  headers.forEach(header => {
    header.tabIndex = 0
    header.addEventListener('click', toggleAccordion)
  })

  const panels = document.querySelectorAll('.accordion__panel')
  panels.forEach(panel => panel.classList.add('visually-hidden'))
}

When we do that, we can see the focus styles whenever we press the tab key.

If we press the enter or space key, nothing happens. That's because this isn't a button element with built-in keyboard events on click. That's why I preach from time to time about using semantic HTML.

We have to add a keypress event on the header elements.

headers.forEach(header => {
  header.tabIndex = 0
  header.addEventListener('click', toggleAccordion)
  header.addEventListener('keypress', toggleAccordion)
})

This “works” but not quite how we want it. Because we haven't separated which key we want to toggle the class on, it wouldn't matter if we hit the k key or the Space bar.

So first, let's pass the event into the toggleAccordion function and console.log() that

function toggleAccordion(e) {
  console.log(e)
  this.nextElementSibling.classList.toggle('visually-hidden')
}

Quick interruption here. Even though I prefer buttons for this, learning how to do it the wrong way taught me a LOT about JavaScript. I learned about event handlers and the event object. As someone who was a newb to JavaScript, I learned a great deal from exploring, even if this wasn't the best way to write the code.

Back to talking about events. When we open this up in the console, we see a bunch of properties on that event.

I see a few things I can use, particularly the code or key. I'm going to use the key property because it's a bit more verbose when I press the space bar.

So I can do this, right?

function toggleAccordion(e) {
  if (e.code === 'Enter' || e.code === 'Space') {
    this.nextElementSibling.classList.toggle('visually-hidden')
  }
}

Well, no. Because this doesn't account for the click event. Click events don't have the code property. What types of properties do they have that we can use to make this work for this click event? Let's add the console.log(e) back into our function and see what we have available to us.

So now, I check if the type is click or code is a space or enter.

To make this a bit easier to read, I am going to separate the code into a ternary operator that returns true or false. I didn't do that when I was initially doing this, but I wanted to add a little bit of readability into my conditional.

function toggleAccordion(e) {
  const pressButtonKeyCode =
    e.code === 'Enter' || e.code === 'Space' ? true : false

  if (e.type === 'click' || pressButtonKeyCode) {
    this.nextElementSibling.classList.toggle('visually-hidden')
  }
}

And now we can click AND open with a space bar and enter key.

There are a ton of things I would improve upon, which we'll go over next. But if you want to take a look at the code, take a look at the CodePen below:

What I would change now

While this technically works, it's not the most ideal. I had no idea what progressive enhancement was when I was learning JavaScript. I also had no idea what ARIA was.

So let's start walking through it. If you read part 1, you’ll know that I am a big fan of having a no-js class as a way to detect if JavaScript has loaded or not.

<ul id="accordion" class="accordion no-js">
  <!-- Children elements -->
</ul>

Then the first thing we do when our JavaScript loaded is removing that class.

const accordion = document.getElementById('accordion')
accordion.classList.remove('no-js')

We'll add some default styling if the no-js class is present, meaning that JavaScript wouldn't have loaded:

.accordion {
  &.no-js {
    .accordion__header {
      display: none;
    }

    .accordion__item {
      border-top: 0;
      border-bottom: 0;

      &:first-child {
        border-top: 1px solid;
      }

      &:last-child {
        border-bottom: 1px solid;
      }
    }

    .accordion__panel {
      display: block;
      border-top: 0;
    }
  }
}

I've removed the button that isn't technically a button and had everything open by default.

Now, back into the JavaScript. On the headers, we want to set the aria-expanded attribute to false and give it a role of button.

headers.forEach(header => {
  header.tabIndex = 0
  header.setAttribute('role', 'button')
  header.setAttribute('aria-expanded', false)
  header.addEventListener('click', toggleAccordion)
  header.addEventListener('keypress', toggleAccordion)
})

While we are setting roles, I am going to set the panels' role to region

if (accordion) {
  // header code
  panels.forEach(panel => {
    panel.setAttribute('role', 'region')
  }
}

Next, I'll toggle aria-expanded and remove the toggling of the class in the function. As a note, even though we set the attribute to be a boolean, getAttribute() returns a string.

function toggleAccordion(e) {
  const pressButtonKeyCode =
    e.code === 'Enter' || e.code === 'Space' ? true : false

  const ariaExpanded = this.getAttribute('aria-expanded')

  if (e.type === 'click' || pressButtonKeyCode) {
    if (ariaExpanded === 'false') {
      this.setAttribute('aria-expanded', true)
    } else {
      this.setAttribute('aria-expanded', false)
    }
  }
}

We don’t need to visually hide the content because we have the button that controls the information. It's not a good screen reader user experience to read the information they didn't want. I love using aria-expanded in CSS to toggle between display: none and display: block for the panel.

.accordion {
  &__header {
    // more scss
    &[aria-expanded='true'] + .accordion__panel {
      display: block;
    }
  }

  &__panel {
    display: none;
    padding: 1rem;
    border-top: 1px solid;

    h3 {
      margin-top: 0;
    }
  }
}

I'm going to be adding a few ARIA attribute to help associate the header and the panel together.

aria-controls - This can be confusing for some people. I highly recommend reading Léonie's post
aria-labelledby

I based this on the WAI-ARIA authoring practices.

First, the headers:

headers.forEach(header => {
  header.tabIndex = 0
  header.setAttribute('role', 'button')
  // This will match the aria-labelledby on the panel
  header.setAttribute('id', `accordion-header-${i + 1}`)
  header.setAttribute('aria-expanded', false)
  // This will match the id on the panel
  header.setAttribute('aria-controls', `accordion-section-${i + 1}`)
  header.addEventListener('click', toggleAccordion)
  header.addEventListener('keypress', toggleAccordion)
})

Then we'll take those and make sure they match up accurately with the panels

panels.forEach(panel => {
  // This will match the aria-controls on the header
  panel.setAttribute('id', `accordion-section-${i+1}`)
  panel.setAttribute('role', 'region')
  // This will match the id on the header
  panel.setAttribute('aria-labelledby', `accordion-header-${i+1}`)
}

If you want to play around with the code, fork the CodePen and check it out.

Conclusion

Was this the most ideal markup ever? No. Did this teach me a lot about JavaScript? Yes. Did this teach me the value of using buttons where I have keyboard events built-in? Yes.

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Take the 10 days of a11y Challenge for more accessibility funsies!

Cheers! Have a great week!

10 Ways to Help Accessibility at Conferences as a Speaker

Lindsey Kopacz — Mon, 02 Dec 2019 13:07:52 +0000

Originally Posted on www.a11ywithlindsey.com.

Hey friends! Wedding planning is starting to heat up with five months left to go. I was pretty ambitious about my writing schedule when I started my second year of blogging. I figured I had so much more free time on my hands versus what I had six months ago. But I didn’t account for the timeliness of my wedding and my other goals. Whoops. This blog is a work in progress, just like me.

Anyways, about a month ago, I presented at a11yTO conference. It was the first time that I had spoken in a while. It reminded me of how much I’ve learned about accessibility beyond the web. Speaking at an accessibility conference forced me to think about my speaker tendencies. For example, I tend to forget words when I’m nervous. I wanted to make sure I wasn’t unintentionally excluding people due to my nerves. So I practiced my presentation several times. I thought critically about everything that I said that could exclude others. I even made a few mistakes that I will be fixing in the future.

Here are my 10 tips for what I’ve learned from this past month.

Introducing yourself with your pronouns

I foresee a future where pronouns are standard. I’ve been adding my pronouns to as many places as I can. I added it to my email signature and my Twitter handle. It wasn’t until I spoke last that I thought, “why don’t I add it to my speaker slides?”

However, it’s not enough to write your pronouns onto your slides. Introducing yourself with your pronouns is vital. Here’s the format I try to take on:

"Hi! I am Lindsey Kopacz. My pronouns are she/her. Today we will be talking about [insert presentation name]."

Simple and Inclusive!

Creating readable shortened links

Whenever I link out to anything, I ensure that I use bit.ly to create a shortened version. However, it’s not ideal to have "bit.ly/37oSXR". Did you know that if you have a free account with bit.ly, you can customize the link name?

Here's how to get started:

Go to the bit.ly website and sign up for free.
Once you're signed in and set up, go to your dashboard
In the upper right-hand corner, click on “Create”
In the Paste URL field, put your link.
After you created your link, go to the “Customize Back-Half” field. After "bit.ly," type in your custom URL! (Note you cannot do custom domains unless you pay)
Press save and copy!

Before:

and After:

And voilà! There you have it!

When you include the visual text for this link, don't include the http://. It doesn’t look sightly, and when your users go without it, it won’t impact your link!

Including the link is not enough. Physically read it. Don’t say, “here’s the link if you want to check it out.” Instead, say:

"If it's easier for you to follow along on your computer, the link is bit dot L Y slash testing dash out dash B I T L Y."

I’ll talk more about the phonetics a little later. But it’s essential actually to say your link. It helps those who are not able to see your slides.

Include your slide link at the beginning

Now you have customized links! So your first slide after your introduction is your link to your slides. If someone prefers to use their assistive tech to go through your slides, they can.

Also, for those who have trouble keeping up, your audience can take a look at the slide if they missed something. For example, I have ADHD and sometimes need to re-read certain things for the information to seep in.

As a bonus, sometimes it’s helpful to include your link on all slides (in an unobtrusive way, of course). If you do this, you don't need to read it out on every slide, only on that first one.

Spell out abbreviations, especially for links

We don’t want to make any assumptions that people know how to spell abbreviations that we use. We also don't want to assume how we pronounce something that isn’t a common word is how someone else may interpret it.

A lot of my bit.ly’s have the word “a11y” in them, and I have made the mistake of pronouncing it “ally” during a presentation. Even at an accessibility conference, how would the audience know that I am not saying “ally?” Instead, what I should be saying is “A eleven Y.”

To take it a step further for necessary information (like links), I can ensure I spell out everything. So let's rewrite how I would announce the link in the section:

"If it's easier for you to follow along on your computer, here's the link spelled out: B I T dot L Y slash T E S T I N G dash O U T dash B I T L Y."

Also, as a note, make sure you enunciate and speak slowly while you do this.

Having proper contrast on your slides (and code samples!)

Have you ever been watching a presentation, and you cannot see what the slides say? You have to think about contrast even more than you would for a web site. When you consider glare and fluorescent lighting, your slides could be washed out.

Sometimes “pretty” slides aren’t the best contrast. I would much prefer that people were able to read my content. Something I’ve started doing is taking my blog theme and using those colors for my slides. That way, it’s very “on brand” and also high contrast.

I will say, the biggest offender I've seen is when people go over code samples. Have you checked your VSCode theme for contrast? What about your CodeSandbox theme?

So many code themes are notoriously lousy contrast. For example, I use the Dracula At Night VSCode theme. While most of the colors have excellent contrast, comments only past for large text. Usually, if you use a VSCode theme, they have a Github repo where they tell you all the colors. If it’s not in the README, it’s usually in the code repo somewhere. I found mine in this TypeScript file.

So the orange, green, and blue texts below have accessible contrast for my code theme (Note: I used WebAim's Contrast Checker to check the contrast):

But the comments, which I find essential to communicating to an audience what I am doing, is not:

The comments technically pass for large text. But how would that look on a screen where there’s glare?

If you're not using VSCode and using CodeSandbox, test out the theme. Write some comments and some code and use the wave tool or Google Dev Tools to check out the contrast. I always use the High Contrast theme for CodeSandbox.

Articulate alt text

I am a big fan of being descriptive and creative in your alt text. One of my first blog posts was about Writing Alternative Text that Matter. A lot of times, we will use images as visual aids in our presentations. They’re fun and help you with storytelling. But you are excluding your visually disabled audience when you present the image without comment.

So, before you present your gif or meme without comment, articulate it. Why do you have it in your presentation? Are you posting a gif that shows your annoyance when a client says something? Describe what the gif is doing and say it's a metaphor for how you feel.

Avoid using vague words

I tend to use vague words, instead of articulating what I mean. I'll point to items on the screen and say, "here we do this" or "this means." I've been trying to improve my word usage in my writing as well.

I challenge myself to ask myself: “what is here?” Or “What is this?” The only time I use "this" now is when I am referencing JavaScript this. But even then, I will be sure to clarify to my audience about its usage.

Content Warnings before Gifs

In my blog post about Reducing Motion, you learn that too much animation can be problematic. Certain animations from gifs cause dizziness and vertigo for those with vestibular disorders.

There are a few gifs that I frequently see on Twitter that bother me for this reason. Give a content warning before you post a slide that has a gif.

Not using too much slide animation

Most slide animation is unnecessary. People are coming to your talk because they want to hear you speak. They aren't coming because they want to see fancy slide animations.

If you want to reduce motion, I would go with fade animation versus sliding animation.

Ensure the conference is accessible

We don’t have optimal control over the conference itself. But as speakers, we have a unique ability to influence. I mean, without speakers, conference organizers wouldn’t have a conference, right? Using your influence is especially important if the conference is for profit. I don’t speak as often as I used to. But now, when I do, I feel that I can be particular. Tatiana Mac’s Speaker Rider, particularly the conference logistics section, has inspired me.

If the conference says they cannot afford it, I wonder:

Do they provide an open bar at their festivities?
Do they have unnecessary swag?
Do they have random giveaways?
What's the price of their ticket? Is it a free conference?
Are there free ways to make the event more accessible?

Here are some inclusive conference examples that I've seen:

Onsite post-conference events or Accessible transportation to them
Transcriptionist or Sign Language Interpreter (or both)
Ramps everywhere
Alternatives to Speaker Podiums
Elevators

Conclusion

I’ve said this before, and I’ll repeat it. Accessibility isn’t about coding (even though this blog talks mostly about coding). Accessibility is about people. Accessibility is about including and protecting people in minoritized groups. So I hope these tips help you! Let me know what tips you have!

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Be the first to learn about my posts for more accessibility funsies!

Cheers! Have a great week and a great holiday if you're in America!

Accessibility in d3 Donut Charts

Lindsey Kopacz — Mon, 11 Nov 2019 15:51:18 +0000

Originally Posted on www.a11ywithlindsey.com. If you'd like to see video examples of how screen readers interpret these, they are at the source!

Hey friends! I got back from Toronto last week after speaking at a11yTO, one of the only conferences where I wanted to speak! I spoke about accessibility and JavaScript. This talk was loosely based on my a11y and JS - A Seemingly Unconventional Romance post. So I'm pretty motivated to do a JavaScript-heavy blog post.

One of my favorite posts that I've written was my accessible bar chart post. It's been about.... 6 months since I wrote that. So much for a series, ey? Today I am going to be going through how to make an accessible donut chart with d3. I'm not going to go through all the bells and whistles and interactions. It's going to be a donut chart with accessible data.

Starting out

As a disclaimer, because I am most familiar with d3, this is how I am building out my visualization. D3 renders SVG, so if it helps you, you can explore the final result and see how the SVG renders.

I am still learning about d3, and am not exactly an expert at teaching it. I won't be going over d3 lingo in this blog post, so I recommend reading up a little bit on d3 if it's confusing to you. If it's available to you, I recommend checking out Shirley Wu's courses on Frontend Masters.

First things first, we have to get a dataset formatted. Most donut charts I see are on finance apps, so I am going to use a sample spending of a small business owner that I made up. I have no idea how much businesses spend on things, but the numbers are irrelevant here. The data structure is the most important! I am going to create an array of objects with 2 properties: label and spending.

const data = [
  {
    label: 'Office Supplies',
    spending: 460,
  },
  {
    label: 'Transportation',
    spending: 95,
  },
  {
    label: 'Business Services',
    spending: 300,
  },
  {
    label: 'Restaurant',
    spending: 400,
  },
  {
    label: 'Entertainment',
    spending: 220,
  },
  {
    label: 'Travel',
    spending: 1000,
  },
  {
    label: 'Other',
    spending: 125.0,
  },
]

For my HTML, I have a <svg> tag with an id of donut-chart and some starting d3 code. I'm not going to go through d3 step by step here because this isn't a "how to d3" it's a "how to make visualizations accessible" post.

What I've done here:

Created a pie chart using d3.arc() to generate the d attribute for the <path> and d3.pie() to format the data properly.
Created a tooltip that when you hover over the arc, it highlights the corresponding data.

Why is this not accessible?

It ignores users who navigate with their keyboard.
It ignores users who navigate with a screenreader.

Option 1: Make the tooltips accessible

This option is my least preferred option. However, it’s a great lesson about how to test for accessibility, so I do like going through the exercise.

To make tooltips accessible, we have to do a few things:

Add a tabindex="0" to all the arc paths so that we can tab to it.
Add an aria-describedby to each selected path with a unique value
Add an id to the tooltip that matched the aria-describedby value. Because each id must be unique, we have to create multiple tooltips.
Make sure that we add not only mouse events, but focus and blur events.

First, let's take care of the tabindex. The below code makes the paths focusable

arcGroup
  .selectAll('.arc')
  .data(pie(data))
  .enter()
  .append('g')
  .attr('class', 'arc-group')
  .append('path')
  .attr('class', 'arc')
+ .attr('tabindex', 0)
  .attr('d', arc)
  .attr('fill', (d, i) => colors[i])
  .on('mousemove', () => {
    const { clientX, clientY } = d3.event
    d3.select('.tooltip').attr('transform', `translate(${clientX} ${clientY})`)
  })
  .on('mouseenter', d => {
    d3.select('.tooltip')
      .append('text')
      .text(`${d.data.label} - $${d.data.spending}`)
  })
  .on('mouseleave', () => d3.select('.tooltip text').remove())

Now we can reach the arcs with our keyboard.

I'm going to add one small tweak and add a stroke color around the arc when we focus on it. I'm going to remove the outline on this with CSS (gasp!) and add a stroke color on focus instead.

In the JavaScript:

arcGroup
  .selectAll('.arc')
  .data(pie(data))
  .enter()
  .append('g')
  .attr('class', 'arc-group')
  .append('path')
  .attr('class', 'arc')
  .attr('tabindex', 0)
  .attr('d', arc)
  .attr('fill', (d, i) => colors[i])
  .on('mousemove', () => {
    const { clientX, clientY } = d3.event
    d3.select('.tooltip').attr('transform', `translate(${clientX} ${clientY})`)
  })
  .on('mouseenter', d => {
    d3.select('.tooltip')
      .append('text')
      .text(`${d.data.label} - $${d.data.spending}`)
  })
+ .on('focus', function(d) {
+   d3.select(this)
+     .attr('stroke', 'black')
+     .attr('stroke-width', 2)
+ })
  .on('mouseleave', () => d3.select('.tooltip text').remove())

and in the CSS

.arc:focus {
  outline: none;
}

Next, we have to add an aria-describedby attribute to the focusable arcs. And remember, that means we need a matching id on the tooltip itself. After we do this, if a screen reader user focuses on an arc, the screen reader reads the content in those tooltips.

Each arc and each tooltip must have a unique identifier. That way, it won't confuse the assistive technology. To do that, I am taking not only the datum's but also the indexes

First, let's add the aria-describedby

arcGroup
  .selectAll('.arc')
  .data(pie(data))
  .enter()
  .append('g')
  .attr('class', 'arc-group')
  .append('path')
  .attr('class', 'arc')
  .attr('tabindex', 0)
  .attr('d', arc)
  .attr('fill', (d, i) => colors[i])
+ .attr('aria-describedby', (d, i) => `tooltip-${i}`)
  .on('mousemove', () => {
    const { clientX, clientY } = d3.event
    d3.select('.tooltip').attr('transform', `translate(${clientX} ${clientY})`)
  })
  .on('mouseenter', d => {
    d3.select('.tooltip')
      .append('text')
      .text(`${d.data.label} - $${d.data.spending}`)
  })
  .on('focus', function(d) {
    d3.select(this)
      .attr('stroke', 'black')
      .attr('stroke-width', 2)
  })
  .on('mouseleave', () => d3.select('.tooltip text').remove())

Let’s add a tooltip per each piece of data and add an id that matches the aria-describedby value.

const tooltipGroup = svg.append('g').attr('class', 'tooltip')

tooltipGroup
  .selectAll('.tooltip-item')
  .data(data)
  .enter()
  .append('g')
+ .attr('id', (d, i) => `tooltip-${i}`)

Now the last thing we have to do is add focus and blur events and correct the d3.select() items on all the events.

arcGroup
  .selectAll('.arc')
  .data(pie(data))
  .enter()
  .append('g')
  .attr('class', 'arc-group')
  .append('path')
  .attr('class', 'arc')
  .attr('tabindex', 0)
  .attr('d', arc)
  .attr('fill', (d, i) => colors[i])
  .attr('aria-describedby', (d, i) => `tooltip-${i}`)
  .on('mousemove', (d, i) => {
    const { clientX, clientY } = d3.event
-   d3.select('.tooltip')
+   d3.select(`#tooltip-${i}`)
      .attr('transform', `translate(${clientX} ${clientY})`)
  })
  .on('mouseenter', (d, i) => {
-   d3.select('.tooltip')
+   d3.select(`#tooltip-${i}`)
      .append('text')
      .text(`${d.data.label} - $${d.data.spending}`)
  })
  .on('focus', function(d, i) {
    d3.select(this)
      .attr('stroke', 'black')
      .attr('stroke-width', 2)

+   const { top, right, bottom, left } = d3.event
+     .target.getBoundingClientRect()
+
+   d3.select(`#tooltip-${i}`)
+     .append('text')
+     .text(`${d.data.label} - $${d.data.spending}`)
+     .attr('transform',
+       `translate(${(left + right) / 2} ${(top + bottom) / 2})`
+     )
  })
- .on('mouseleave', () => d3.select('.tooltip text').remove())
+ .on('mouseleave', (d, i) => d3.select(`#tooltip-${i} text`).remove())
+ .on('blur', function(d, i) {
+   d3.select(this).attr('stroke', null)
+   d3.select(`#tooltip-${i} text`).remove()
+ })

Let's go over a bit of what we've done here.

We've altered the d3 selections to be more specific to ids and not classes.
We've positioned the tooltip on focus dependent on the approximate "middle" position. I've averaged the vertical and horizontal positions using .getBoundingClientRect()
I've removed the stroke when we blur off the event.

Potential problems:

Depending on how large our dataset is, this means we have to have one tooltip rendered per datum. Numerous unique tooltips could become a performance issue in the long run.
This technique is VERY JavaScript-heavy, and I worry about performance.
When we use a screen reader, it announces all the labels with the word "Image" at the end. This has to do with the role of the path element.

There are ways we could tweak this.

Keep the id as one on the tooltip itself
On mouseenter update the aria-describedby of the target to match that id
Remove the aria-describedby on mouseleave
Change the contents on focus and mouseenter.

If you want, you can fork my CodePen above and play around with this. Test it on slower connections. Test it with a screen reader. But I am going to move onto my preferred version, and that's creating a legend.

Option 2: Creating a separate legend

I prefer this option. The reason for this is it simplifies these problems:

gives users a visual representation
fewer performance risks
people using screen readers and keyboards can access the information

So let's take our original code and start adding a legend to it. You may have noticed that I have 2 variables in my code:

const width = 571,
  chartWidth = 189

The reason for this is we have the chartWidth, which is the width for the donut chart. But then we have the width which is the width of the SVG itself. That way, we have room for the legend itself.

First, let's get the legend built.

The first thing I do is to create a group for the legend and position it with the transform attribute. Positioning it this way makes it easier to position the children items.

const legendGroup = svg
  .append('g')
  .attr('transform', `translate(${chartWidth} 0)`)
  .attr('class', 'legend-group')

The above code positions the g element beside the donut chart. Next, we create legend item groups and translate them based on their position

const legendItems = legendGroup
  .selectAll('g')
  .data(data)
  .enter()
  .append('g')
  .attr('transform', (d, i) => `translate(20 ${(i + 1) * 30})`)

Using the index of the array, we establish the vertical positioning of each item using multiplication (yay math!).

Next, I am going to append a small square that color matches the corresponding arc. Because you know, legends usually have a key. This won't be for accessibility purposes.

legendItems
  .append('rect')
  .attr('y', -13)
  .attr('width', 15)
  .attr('height', 15)
  .attr('fill', (d, i) => colors[i])

Adding shapes doesn't do much for accessibility, so let's get some text in there.

legendItems
  .append('text')
  .attr('x', 20)
  .text(d => `${d.label} - $${d.spending}`)

So we are good, right? Well, not quite. We need to test this visualization manually. Sure this is good for a visually abled user and a keyboard user. But does it work on a screen reader?

I'm turning on VoiceOver and using it in Safari (you should always test in Safari since both are Native to macOS).

I learned through manual testing is that every single path element (the arcs) had a role of Image. And it announces on a screenreader. As a result, I'm going to put a role="presentation" on each path.

arcGroup
  .selectAll('.arc')
  .data(pie(data))
  .enter()
  .append('g')
  .attr('class', 'arc-group')
  .append('path')
+ .attr('role', 'presentation')
  .attr('class', 'arc')
  .attr('d', arc)
  .attr('fill', (d, i) => colors[i])
  .on('mousemove', () => {
    const { clientX, clientY } = d3.event
    d3.select('.tooltip').attr('transform', `translate(${clientX} ${clientY})`)
  })
  .on('mouseenter', d => {
    d3.select('.tooltip')
      .append('text')
      .text(`${d.data.label} - $${d.data.spending}`)
  })
  .on('mouseleave', () => d3.select('.tooltip text').remove())

Adding a presentation role tells the screen reader, "this is for presentation and screen readers can ignore."

Now, all it reads are the groups of the text of the legend. We could do more to make it better, like add a Legend title and reduce the duplication (the reading of the groups is really repetitive). But hopefully, you have learned how to start thinking about accessible data visualizations.

Conclusion

As I conclude this post, I want to emphasize something I often say: Manual testing is your friend. What I did is not necessarily the right answer. This is a potential answer. The critical takeaway is that I always test what I am doing with a screen reader, a keyboard, and a mouse. I think about what options we are providing for our disabled users before I start building it, so it’s easy to adapt.

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Be the first to learn about my posts for more accessibility funsies!

Cheers! Have a great week!

How Accessibility Taught me to be Better at JavaScript - Part One

Lindsey Kopacz — Tue, 22 Oct 2019 14:14:05 +0000

Originally Posted on www.a11ywithlindsey.com

Hey friends! Hope you’ve had a great week! This tweet I wrote a while back inspired me to write this blog post:

Fun fact about me: I started learning about JavaScript BECAUSE of accessibility, not in spite of it.
— Lindsey Kopacz 🐞 (@LittleKope) July 9, 2019

One of the responses was “this would be a good blog post.” So here I am.

In this post I’m going to go over:

Background on my first project as the sole front end developer
The requirements of that project that led me to get better at JavaScript
Creating a popup menu that allowed me to start playing with JavaScript
The accessibility issues I faced that I solved using JavaScript
Learning about progressive enhancement
How I would improve things now

Background

About 3-4 years ago, while I’d been in tech for a couple of years, I finally knew that I wanted to be a front end developer. I talked to my boss about owning the front end development on a project. My boss loved finding fitting projects for developer strengths and their desired growth. The project she assigned to me wasn’t particularly sexy. However, it was perfect for my learning. It was not a redesign.

Different, right? You rarely hear about build projects that aren’t redesign. The job: migrate their content to WordPress. The client disliked their previous CMS’s user experience but wanted to keep their design the same. This project allowed me to improve their CSS, accessibility, and performance.

The requirements

There was one primary requirement that had me in a panic. I was not allowed to use jQuery. At the time, I thought it was a silly requirement and couldn't fathom why we weren't allowed to use jQuery. JavaScript frameworks, like Angular and React, were still new to the market. Drupal and WordPress still heavily relied on jQuery.

The other main requirement was that I was not allowed to alter the content markup in any way. We’ll talk more about this in another post, but this ended up being a bit of a blessing for progressive enhancement!

I'm not going to talk too much about WordPress or CSS in this post. However, I am going to quickly go over some of the tasks that I remember doing to get things set up with accessibility in mind. At the time, I understood accessibility from a UI developer perspective, but not about the intersection of JavaScript.

Starting in JavaScript

We had a base theme at our agency, and I used that to get started. The theme was a blank slate with CSS and some JavaScript for accessible navigation. The first time I had to encounter JavaScript was when I created a language dropdown menu.

This website had many language sites, over 20. This menu’s purpose was to switch the language. We kept the existing functionality, which was a menu of links to each languages' homepage. Ideally, I would want to have the language switcher to get the page the user was on. However, remember, we were not changing any of the functionality; it was a migration project.

Starting with the JavaScript, I created a button with an unordered list. Then we are going to use addEventListener to toggle a visually-hidden class. To read more about visually hidden, check out the A11y Project's post about it.

Simple enough, right?

Wrong.

Accessibility Issues

When we do it this way, we can focus on links that are not visible. Take a look at this gif, and particularly the bottom left corner where you see the links. Do you notice when we focus on the button, we see a blue outline? When we start tabbing again, all the links we hid are focusable. We cannot see where it the focus of the link is

What I did in the past was way more overkill than I needed. I set all the tabindexes of the links inside that menu to be -1 upon page load. In that event listener, I also checked to see if the class existed and based the tabindex toggle off that. There is a silver lining of me going over the top with my code. I learned a lot about the properties of HTML elements in JavaScript. Which was valuable to me strengthening my skills in JavaScript. All while learning about focus management, which is important for accessibility.

Ah much better, at least functionally.

When I first started, I thought that display: none was always bad for accessibility. But it's not. If something isn't open, nobody should be able to access it, not even screen reader users. So I'm going to change it up a bit.

What I wish I had done:

remove the visually-hidden class
set .lang-menu to display: none and when I append the .open class, change styling to display: block
Change the toggle classList to toggle the class open.

Doing the above steps won't solve the problem entirely, though. Let's talk about progressive enhancements.

Progressive Enhancements that I wish I had done

Unfortunately, neither of these strategies account for progressive enhancement. If JavaScript doesn’t load or loads slowly, we want people to still able to access the navigation menu. Let’s say JS doesn’t load, what happens to our users for this implementation?

If JavaScript doesn't load and the ul element has display: none, nobody can ever see the language menu. That's because there's no way to toggle the menu open without the event listeners.

There are a few things I would do for progressive enhancement.

Add a no-js class
Remove that class as soon as JavaScript loads.
Change up the open/close to focus more on the "close" and load a class in upon JavaScript loading.
Create some default styling with no-js, so it doesn't look unsightly (I'm not going to do that here)
Hide the button visually and from assistive technology, if no-js is present.

Adding context with ARIA

If you've read my Demystifying ARIA blog post you know that I add ARIA only at the end when I need more context. I didn't know anything about ARIA when I first started working as a web developer, so I never added that to the code.

Here are the ARIA attributes that I am going to add:

aria-expanded to indicate to a user whether the menu is open or closed. The value toggles between true and false on the event listener.
aria-haspopup to indicate that the element has a popup context menu or sub-level menu.

To test on macOS:

open up Safari and turn on a screen reader using cmd + F5.
Use VoiceOver Commands to select the button. It should read “Open, Collapsed, Popup button.”
Press enter. The screen reader should read “Open, Expanded, Popup Button.”

See the video below go to the original post.

These aria attributes give direction to a screen reader user about how to interact with the button. It would be even better if I had a more verbose button label with more context telling you what you're opening up, too!

Conclusion

It's really fun seeing how my code has evolved as an accessibility focused web developer. I am going to make a second post about the other main accessibility issue I came up with for this project. This post was starting to get REALLY lengthy! I needed JavaScript to solve these issues. I also needed JavaScript to learn about Progressive Enhancement.

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Be the first to learn about my posts for more accessibility funsies!

Cheers! Have a great week!

Reducing Motion to Improve Accessibility

Lindsey Kopacz — Tue, 20 Aug 2019 10:53:15 +0000

Originally posted on a11ywithlindsey.com.

Hey friends! In this post, I am going to walk you through a newer media query (to me): prefers-reduced-motion.

Quick confession: I know CSS fundamentals, but I am pretty behind on all the new stuff that has been coming out. Because my focus is usually on accessibility, I am focusing far more on HTML and JavaScript. When I focus on CSS, it's ensuring proper color contrast or custom focus states. Sometimes I use CSS to make checkboxes keyboard accessible. I always associated media queries with responsive design. I never thought of media queries as an accessibility enhancement.

In this post, we are updating my blog by:

Adding the prefers-reduced-motion query
Adding a user-controlled setting for reducing motion.

Understanding `prefers-reduced-motion`

Animations, zooming, and panning can be problematic for people who have vestibular disorders. These disorders can cause motion sickness and vertigo. These are uncomfortable feelings that you don't want to deal with ever, let alone on a website. From what I understand, the vestibular system is in your inner ear and helps to control balance.

According to vestibular.org, up to 35% of adults aged 40 years or older in the United States have experienced some form of vestibular dysfunction. So this is not a small problem.

My major takeaways from the web accessibility perspective:

Be careful with your animations.
Be careful with your gifs.
Use prefers-reduced-motion.
Allow a user to control reduce motion.

How you do it

Implementing the query is pretty simple:

@media screen and (prefers-reduced-motion: reduce) {
  /* Reduced Motion Code */
}

There are a few places I have some animations for my links.

First, there are my links where I have a border-bottom that moves down when you hover over it.

Then there is my call to action link that scales 1.1x larger when we hover over it.

I was talking to Andy Bell, and he gave me some suggestions on implementation.

@media screen and (prefers-reduced-motion: reduce) {
  * {
    animation-play-state: paused !important;
    transition: none !important;
    scroll-behavior: auto !important;
  }
}

After implementing the changes, we have the hover effects, but none of the transitions.

This strategy technically works well. However, I want to remove the hover effect altogether and keep the link as an underline. I may also play with the scale.

@media screen and (prefers-reduced-motion: reduce) {
  * {
    animation-play-state: paused !important;
    transition: none !important;
    scroll-behavior: auto !important;
  }

  a {
    padding-bottom: 0;
    border-bottom: none;
    text-decoration: underline;
  }
}

With that change, now all my links are just a simple underline.

Without the transition animation, the call to action links are a bit jarring going from scale(1) to scale(1.1) on hover. So I changed it to scale(1.05).

@media screen and (prefers-reduced-motion: reduce) {
  * {
    animation-play-state: paused !important;
    transition: none !important;
    scroll-behavior: auto !important;
  }

  a {
    padding-bottom: 0;
    border-bottom: none;
    text-decoration: underline;
  }

  .blog__more-link a {
    text-decoration: none;
  }

  .blog__more-link a:hover {
    transform: scale(1.05);
  }

  .hero__cta a {
    text-decoration: none;
  }

  .hero__cta a:hover {
    transform: scale(1.05);
  }
}

How to test on a mac

This setting is primarily available on macOS.

Go to System Preferences
Go to Accessibility
Go to Display
Check "Reduce Motion"

Easy Peasy! As soon as this post is published, you should be able to test this on my blog!

Creating a user controlled option to reduce motion

Andy Bell's dark mode post inspired me to add the user-controlled option. We want to have the user's preferences take priority. We also want to account for people who don't have these settings available to them.

Here's how we are going to do this:

Create a checkbox with the label "reduce motion."
Add a checked state and a method to toggle that state in my Gatsby App.
Use that state to control a data-user-reduced-motion attribute.
Apply the CSS using the above attribute.
Store that in localStorage, so we preserve the user settings.

Creating a `<ReduceToggle />` Component

This component is an HTML checkbox with a label. As a disclaimer, I am using a class component and not hooks. I still like writing classes sometimes, and it was easier for my thought process. Keep an eye out for a hook version!

import React from 'react'

class ReduceToggle extends React.Component {
  render() {
    return (
      <div className="toggle">
        <input id="reduce-motion" type="checkbox" />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

The only thing I've done here is to create a checkbox input with an associated form label. Something you may have noticed is that instead of for, React uses htmlFor.

After that, I place it in my <Header /> component above the menu. I'll worry about styling finesse later; I know it'll break my layout, and that's ok. We are only worried about functionality right now.

Adding in the states

We want to go ahead and add a checked state to our constructor.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  render() {
    return (
      <div className="toggle">
        <input id="reduce-motion" type="checkbox" />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

Now we are going to add that state to the checkbox itself.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  render() {
    const { checked } = this.state

    return (
      <div className="toggle">
        <input
          id="reduce-motion"
          type="checkbox"
          checked={checked}
        />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

Next, we want to add a toggleChecked method for the onChange event.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  toggleChecked = event => {
    this.setState({ checked: event.target.checked })
  }

  render() {
    const { checked } = this.state

    return (
      <div className="toggle">
        <input
          id="reduce-motion"
          type="checkbox"
          checked={checked}
          onChange={this.toggleChecked}
        />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

I always like to double-check that the state is working using React Developer Tools. To do this:

I inspect the element
Go to the React Tab
Find the ReduceToggle component
Ensure the state is working correctly!

Now we know the state is working. Let's toggle the data-user-reduced-motion attribute value on the documentElement. I'm going to add that in the componentDidUpdate lifecycle method.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  componentDidUpdate() {
    const { checked } = this.state

    if (checked) {
      document.documentElement
        .setAttribute('data-user-reduced-motion', true)
    } else {
      document.documentElement
        .setAttribute('data-user-reduced-motion', false)
    }
  }

  toggleChecked = event => {
    this.setState({ checked: event.target.checked })
  }

  render() {
    const { checked } = this.state

    return (
      <div className="toggle">
        <input
          id="reduce-motion"
          type="checkbox"
          checked={checked}
          onChange={this.toggleChecked}
        />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

Adding CSS to the `data-user-reduced-motion`

Word of warning. It's tempting to jump into the CSS and copy and paste all the things. I recommend doing this one step at a time. I made the mistake of trying to do it all at once and spent a lot more time debugging than I wanted to. So first let's go back to the goals of what we want.

We want user preference to rule over system preferences. We'll add the system preferences as a progressive enhancement.

Gatsby is a Static Site Generator, so if JavaScript doesn't load, most of my static site should load. However, if JavaScript doesn't load, we want to fallback on system preferences when the data-user-reduced-motion attribute doesn't exist. So we are going to add a little bit to the query that we did in the first section about the media query itself. So we are using the :not() CSS pseudo-class to do that.

@media screen and (prefers-reduced-motion: reduce) {
  * {
  :root:not([data-user-reduced-motion]) * {
    animation-play-state: paused !important;
    transition: none !important;
    scroll-behavior: auto !important;
  }

  a {
  :root:not([data-user-reduced-motion]) a {
    padding-bottom: 0;
    border-bottom: none;
    text-decoration: underline;
  }

  .blog__more-link a {
  :root:not([data-user-reduced-motion]) .blog__more-link a {
    text-decoration: none;
  }

  .blog__more-link a:hover {
  :root:not([data-user-reduced-motion]) .blog__more-link a:hover {
    transform: scale(1.05);
  }

  .hero__cta a {
  :root:not([data-user-reduced-motion]) .hero__cta a {
    text-decoration: none;
  }

  .hero__cta a:hover {
  :root:not([data-user-reduced-motion]) .hero__cta a:hover {
    transform: scale(1.05);
  }
}

Then we add the CSS outside the query for if the data-user-reduced-motion="true".

:root[data-user-reduced-motion='true'] * {
  animation-play-state: paused !important;
  transition: none !important;
  scroll-behavior: auto !important;
}

:root[data-user-reduced-motion='true'] a {
  padding-bottom: 0;
  border-bottom: none;
  text-decoration: underline;
}

:root[data-user-reduced-motion='true'] .blog__more-link {
  text-decoration: none;
  padding: 12px 14px;
  border: 2px solid;
}

:root[data-user-reduced-motion='true'] .blog__more-link:hover {
  transform: scale(1.05);
}

:root[data-user-reduced-motion='true'] .hero__cta__link {
  text-decoration: none;
  padding: 12px 14px;
  border: 2px solid;
}

:root[data-user-reduced-motion='true'] .hero__cta__link:hover {
  transform: scale(1.05);
}

To test, I did the following:

Turned off any reduce motion settings on macOS
With the Reduce Toggle unchecked, ensure that all animations are still there.
Check the Reduce Toggle Checkbox and see that all the CSS changes to reduce motion are working.
In the element inspector, go to the <html> document and find the data-user-reduced-motion. Remove that attribute. Here we are simulating that that attribute never loaded.
Go to the system preferences and check Reduce Motion. We should have the CSS changes for reduced motion!

Adding `localStorage`

Now that we have that working, we want to start playing with localStorage. We want to preserve the user's preferences for the future. Choosing your settings every time you visit isn't the best user experience. If you don’t know what localStorage is, I would recommend pausing here and glancing over the docs. If you like video examples, take a look at Wes Bos’s JS30 tutorial.

The first thing we are going to do is set the localStorage on the componentDidMount.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  componentDidMount() {
    let reduceMotionOn = localStorage.getItem('reduceMotionOn')
    console.log(reduceMotionOn)
    // if we haven't been to the site before
    // this will return null
  }

  // All other code stuff

  render() {
    return (
      <div className="toggle">
        <input id="reduce-motion" type="checkbox" />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

Now what we want to do is create a default localStorage state for the user if the reduceMotionOn is null. I'm going to set that to false.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  componentDidMount() {
    let reduceMotionOn = localStorage.getItem('reduceMotionOn')

    // Just a way to get around localStorage being
    // stored as a string and not a bool
    if (typeof reduceMotionOn === 'string') {
      reduceMotionOn = JSON.parse(reduceMotionOn)
    }

    if (reduceMotionOn === null) {
      localStorage.setItem('reduceMotionOn', false)
    }
  }

  // All other code stuff

  render() {
    return (
      <div className="toggle">
        <input id="reduce-motion" type="checkbox" />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

The last thing I am going to do upon mounting the component is set the state in the app. I want to ensure that my app's is the same as the localStorage.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  componentDidMount() {
    let reduceMotionOn = localStorage.getItem('reduceMotionOn')

    if (typeof reduceMotionOn === 'string') {
      reduceMotionOn = JSON.parse(reduceMotionOn)
    }

    if (reduceMotionOn === null) {
      localStorage.setItem('reduceMotionOn', false)
    }
    this.setState({ checked: reduceMotionOn })
  }

  // All other code stuff

  render() {
    return (
      <div className="toggle">
        <input id="reduce-motion" type="checkbox" />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

Go to Application > Local Storage in Chrome Dev Tools (Storage > Local Storage in Firefox). Then, clear the reduceMotionOn storage. Upon refresh, you should see that the reduceMotionOn is false. If you go to React Dev Tools and go to the <ReduceToggle /> component, you’ll find that the checked state matches the reduceMotionOn localStorage item.

That's not all! We have to toggle the localStorage in the toggleChecked method in the React component.

import React from 'react'

class ReduceToggle extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      checked: false,
    }
  }

  // All other code stuff

  toggleChecked = event => {
    localStorage.setItem('reduceMotionOn', event.target.checked)
    this.setState({ checked: event.target.checked })
  }

  render() {
    return (
      <div className="toggle">
        <input id="reduce-motion" type="checkbox" />
        <label htmlFor="reduce-motion">Reduce Motion</label>
      </div>
    )
  }
}

export default ReduceToggle

Now if I check Reduce motion and leave the site, my user-controlled preferences are preserved!

Conclusion

Thanks for joining me while I added a progressively enhanced accessibility feature to my blog! I hope you learned something along the way. Shout out to Andy for inspiring me to write this post!

These are the key takeaways from this post, regardless of the framework that you use:

Be careful with what you animate and provide options for those who have vestibular disorders.
User-controlled > System Preferences
Have system preferences for progressive enhancements
Use localStorage to your benefit so that the user settings are preserved!

If you'd like to play around with this, I've made a CodeSandbox for you!

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Be the first to learn about my posts for more accessibility funsies!

Cheers! Have a great week!

Create custom keyboard accessible radio buttons

Lindsey Kopacz — Mon, 05 Aug 2019 19:40:10 +0000

Originally posted on a11ywithlindsey.com.

Hey friends! Today we'll be creating custom keyboard accessible radio buttons! This blog post is a follow-up post from my accessible checkboxes post.

We'll go over:

The markup
Creating a pseudo-element on the label in CSS
Add "selected" styling in CSS
Add focus styling

Starting out

I decided to create a simple group of radio buttons asking what your favorite animal is

<fieldset>
  <legend>What is your favorite Wild Animal?</legend>
  <div class="radio-wrapper">
    <input type="radio" name="animal" id="elephant" />
    <label for="elephant">Elephant</label>
  </div>
  <div class="radio-wrapper">
    <input type="radio" name="animal" id="monkey" />
    <label for="monkey">Monkey</label>
  </div>
  <div class="radio-wrapper">
    <input type="radio" name="animal" id="cheetah" />
    <label for="cheetah">Cheetah</label>
  </div>
  <div class="radio-wrapper">
    <input type="radio" name="animal" id="giraffe" />
    <label for="giraffe">Giraffe</label>
  </div>
</fieldset>

The fieldset groups all the radio buttons together logically. The radios inputs are all options to the question in the legend. Also, remember to associate those form labels with the radio buttons!

I'm going to add some straightforward CSS to clean it up a bit.

@import url('https://fonts.googleapis.com/css?family=Roboto&display=swap');

* {
  font-family: 'Roboto', sans-serif;
}

fieldset {
  border: none;
}

I didn’t do anything much here; I added a font and took away the border from the fieldset.

Now let's get to the fun part! Styling these radio buttons!

Creating a pseudo-element on the label

First thing I am going to do is add a ::before pseudo-element on the label element. I'm going to start with something basic first.

$muted-red: #db3846;

input[type='radio'] {
  + label {
    position: relative;
    cursor: pointer;
    margin-left: 20px; /* This will be adjusted */

    &::before {
      content: '';
      position: absolute;
      left: -22px; /* This will be adjusted */
      width: 20px;
      height: 20px;
      background: $muted-red;
    }
  }
}

The radio buttons won't look like anything much right now. We only want to see the radio buttons to ensure we are replicating the HTML functionality.

I'm going to add a teensy amount of margin on the .radio-wrapper.

$muted-red: #db3846;

+ .radio-wrapper {
+ margin: 0.5rem 0;
+ }

input[type='radio'] {
  + label {
    position: relative;
    cursor: pointer;
    margin-left: 20px; /* This will be adjusted */

    &::before {
      content: '';
      position: absolute;
      left: -24px; /* This will be adjusted */
      width: 18px;
      height: 18px;
      background: $muted-red;
    }
  }
}

Now let's remove that background color and round out the edges.

input[type='radio'] {
  + label {
    position: relative;
    cursor: pointer;
    margin-left: 20px; /* This will be adjusted */

    &::before {
      content: '';
      position: absolute;
      left: -24px; /* This will be adjusted */
+     border-radius: 50%;
+     border: 1px solid #6f686a;
      width: 18px;
      height: 18px;
+     background: transparent;
    }
  }
}

As a note, I am going to leave the standard radio buttons for debugging purposes.

Add `:checked` styling in CSS

If you've read my post on keyboard accessible checkboxes you know about the :checked pseudo-class. First, we need to put add an ::after pseudo-element on the label.

input[type='radio'] {
  + label {
    position: relative;
    cursor: pointer;
    margin-left: 20px; /* This will be adjusted */

    &::before {
      content: '';
      position: absolute;
      left: -24px; /* This will be adjusted */
      border-radius: 50%;
      border: 1px solid #6f686a;
      width: 18px;
      height: 18px;
      background: transparent;
    }

+   &::after {
+     content: '';
+     position: absolute;
+     left: -20px;
+     top: 4px;
+     border-radius: 50%;
+     width: 12px;
+     height: 12px;
+     background: $muted-red;
+   }
  }
}

Now, this is what that looks like:

Now we have the styling in place. Let's only add the background of the ::after pseudo-element when the radio input is :checked.

input[type='radio'] {
  + label {
    &::after {
      content: '';
      position: absolute;
      left: -20px;
      top: 4px;
      border-radius: 50%;
      width: 12px;
      height: 12px;
    }
  }

+ &:checked {
+   + label::after {
+     background: $muted-red;
+   }
+ }
}

So now if I select a radio button, it'll have a background color!

If you notice, though, there is no focus styling. Let's focus on that next (see what I did there)

Add focus styling

If I were to hide the radio button, you would have no idea if I focused on it.

input[type='radio'] {
  &:focus {
    + label::before {
      box-shadow: 0 0px 8px $muted-red;
    }
  }
}

I decided to add a similar muted red for the focus styling.

To finish up, I will:

remove the opacity from the radio button itself (the input)
remove the margin-left from the label!

input[type='radio'] {
  opacity: 0;

  + label {
    position: relative;
    cursor: pointer;
  }
}

And Voilà!

Conclusion

When we make custom radio buttons, we have to make sure we account for the following:

Creating proper HTML structure with associated form labels!
Using pseudo-elements to create the custom-styled element
Accounting for the :checked pseudo-class
Ensuring you can focus on the new radio button
Use opacity: 0 to hide the radio button

If you want to play around with it, here is the finished CodePen!

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Be the first to learn about my posts for more accessibility funsies!

Cheers! Have a great week!

A11y Lessons I Learned when Starting a Podcast

Lindsey Kopacz — Tue, 23 Jul 2019 14:35:20 +0000

Originally posted on a11ywithlindsey.com.

If you haven’t noticed, I haven’t been around! It’s been a month since I posted, and there’s been a good reason for that. Kelly Vaughn, Ali Spittel, Emma Wedekind, and I started the LadyBug Podcast. This podcast came to fruition with much labor. As a result, I’ve been figuring out how to balance this blog with that side project! Don’t worry, though, this isn’t going away. My blog is my passion project!

Now that you know where I’ve been, I’ve learned a lot about podcasting and how it intersects with accessibility. I knew some of these things at a high level, but in this post, we’re going to get a little bit more in-depth.

Transcripts are a MUST

When we started planning this podcast, it was no doubt we wanted to have transcripts. Transcripts can be time and financially expensive, and many people see them as a “nice to have.” However, I’m here to tell you that they are a must-have.

Transcripts have a ton of benefits:

Deaf and hard of hearing folks can access your excellent content.
Some people prefer reading than listening. I cannot tell you how many abled folks have told me they appreciated having transcripts.
It helps those whose first language may not be English.
If people are reading your transcripts, this means they are spending a ton of time on your site. Session duration improves SEO.

Being a content creator means that you try to make your content available to as many people as possible. You don't want to alienate a potential audience member because you decided to ignore their needs.

We went through a few attempts to get transcripts. I wanted to share the options we tried and the pros and cons of each option.

Having someone do it for you

Hiring someone was the first thing we tried because it was the only option we knew. We didn’t have time to go through our entire audio and write it out. So we decided to hire someone who did that for us. We used Fiverr, which I had never tried before. Hiring someone has pros and cons, however.

Pros:

Paying a real person and supporting someone else.
Catches errors in real-time

Cons:

Expensive
Because they are a human, it takes a few days to get them back, which isn’t ideal for a quick turn around.
Language differences.

Using Artificial Intelligence

The other option is to use AI software to parse through your audio and provide a transcript for you. We tried Trint and Otter AI, which are both great tools. AI also has some pros and cons.

Pros:

Get your transcript back in minutes or hours. Otter AI took about 10 minutes.
Cheaper
Gets better as they learn your speakers

Cons:

Especially at first, you have to edit it. We didn't want to have random words in there, so we took some time to listen to the tool as it read the transcript to us.
I feel a little guilty when I use Machine Learning to replace a job that a person could do.

What we ended up doing

Because of the quick turn around we needed, we ended up going with AI. We got a deal with OtterAI and ended up using that one. Do what works best for you in the end, all options are great ones!

A11y Considerations for Custom Podcast Players

As you may or may not know, we used GatsbyJS to build out the LadyBug Podcast site. I took responsibility for making an accessible podcast player. I learned so much about how to use React to create all the audioElement events. Shout out to Syntax.fm for having a player that I could explore. The first thing I did was add a ref to an <audio> element.

class Player extends React.Component {
  render() {
    const { show } = this.props;

    return (
      <audio
        ref={audio => (this.audio = audio)}
        src={show.audio}
      />
    )
  }
}

If I go into the code and add a console.log

class Player extends React.Component {
  render() {
    const { show } = this.props;
    console.log(this.audio)

    return (
      <audio
        ref={audio => (this.audio = audio)}
        src={show.audio}
      />
    )
  }
}

This gives me the ability to access all the methods of the audio. I can use them on my custom player in the form of buttons, radio buttons, and a slider.

In the podcast player, I used the following methods:

HTMLMediaElement.currentTime - This tells you current time in the audio, in seconds.
HTMLMediaElement.playbackRate - This tells you the speed at which you are playing. We can set this property when we press a button to increase the speed!
HTMLMediaElement.volume - This tells you the current volume level.
HTMLMediaElement.play() - This plays the audio.
HTMLMediaElement.pause() - This pauses the audio.
HTMLMediaElement.duration - This tells you the total length of the audio, in seconds.

Once you add the ref to the audio, you can use this.audio to control anything with the audio. You can append the method or property name to this.audio. It’s neat! You can use that as well to control React state 🤯! I won’t be going too much into all the states in this blog post. I recommend you check out our source code as well as the Syntax.fm source code if you want to learn more.

Button Labelling

Button labels are the most critical part of the player being accessible. Remember, we are “hacking” the audio player. We must ensure screen reader, keyboard, and mouse users can access the player. The latter is what abled folks center on, so if you’re doing this, I want to make sure you account for all experiences.

I used the react-icons/fa package to get the icons for our player. We used FaPlay, FaPause, FaUndo, and FaRedo for the play, pause, rewind 15 seconds, and fast-forward 15 seconds buttons. These icons are SVG icons, but I wanted to make sure there was text in the markup. To do this, we ensured the following:

We used the semantic <button> instead of a <div> to support keyboard events. Read my 3 Simple Tips to Improve Keyboard Accessibility post for more information.
We ensured not to use icon fonts, which was already taken care of us through the react-icons library.
We ensured there was actual text inside the buttons, which SVG doesn't do for us. We can visually hide that text using CSS, but it still must be there.

<button class="player__icon">
  <svg>
    <!--paths and things-->
  </svg>
  <span class="sr-only">play</span>
</button>

Creating a slider

I was searching around for an accessible player that shows the slider. I found the Able Player and started observing how they did things. Making this accessible was one of the hardest things I’ve done, and it’s still rather buggy. The code ended up being many divs with aria labels and lots of event handling. The side project conundrum is that done is better than perfect. Looking back, I wish I had made it a slider using the range input. Lessons learned - stay tuned for a future blog post when I update that slider!

For now, I'll go through my thought process of what I wanted to do with the slider. Below is the source code........

<div
  className="player__progress"
  onClick={this.scrub}
  ref={x => (this.progress = x)}
>
  <div className="player__progress-loaded" />
  <div
    className="player__progress-played"
    style={{ width: `${(currentTime / duration + 0.015) * 100}%` }}
  />
  <div
    orientation="horizontal"
    onKeyDown={this.moveSlider}
    tabIndex="0"
    className="player__slider"
    role="slider"
    aria-label="audio timeline"
    aria-valuemin="0"
    aria-valuemax={duration}
    aria-valuetext={renderValueText(currentTime)}
    aria-valuenow={renderValueNow(currentTime)}
    style={{ left: `${(currentTime / duration - 0.01) * 100}%` }}
  />
</div>

I have 3 children divs of the player: .player__progress-loaded, .player__progress-played, and .player__slider. Let's look at what these correspond to:

.player__progress-loaded corresponds to the width of the entire slider. This div has no semantic value to a screen reader user.
.player__progress-played is the visual representation of the total amount played.
.player__slider is the most important element for accessibility. It tells the screen reader user what time it currently is, and allows us to move it with our keyboard.

Now let's take a look at some of the events and style here.

For the onClick event, we want to ensure that we change the currentTime in the audio to be wherever we clicked. If you can, look at the code yourself, fork it, and console log all the things to see what’s happening. If you click anywhere on the .player__progress div, you’ll change the currentTime.

For the .player__progress-played div, we have the styling. The component's width is the percentage of the way through the episode.

Now for the slider itself and then a couple of helper functions, one of which I adapted from Syntax's site.

Holy batman that's a lot of ARIA attributes! Let's dissect this for a second:

role="slider" - This tells the screen reader user that un-semantic div has some meaning!
aria-valuetext - This is the human-readable version of the value of the slider. For example, in the screenshot above - it was "5 minutes, 51 seconds"
aria-valuenow - defines the current value for a range widget (which the slider is)
aria-valuemin - a required attribute that defines the minimum value for a range widget
aria-valuemax - a required attribute that defines the maximum value for a range widget

Below is how VoiceOver on macOS reads the slider:

"5 minutes, 51 seconds, audio timeline, slider". So the aria-valuetext, the aria-label and then the role.

With this.moveSlider, if you press a Left or Right arrow and respectively rewinds or fast-forwards 5 seconds. Take a look at the source code to see how we did that.

How I want to redo the slider

As stated before, this was a little buggy. A few things that are buggy:

Browser support (I got a comment from a listener, but haven't checked it out yet)
I couldn’t figure out dragging the slider with your mouse.

So, for whatever reason, I assumed (don't assume folks, it's dangerous) that you could not custom style a range input.

I was wrong. You totally can.

Conclusions

Starting a podcast has been a very positive experience all around. I’m sure we’ll talk about the more general lessons we learned starting a podcast on the Ladybug podcast!

Two key takeaways from this post:

Always have transcripts. It's worth the time and financial cost to include others. It is not an edge case.
Hack the audio player with caution and ensure that you over-test.

If you're interested in the LadyBug Podcast, be sure to subscribe to have them downloaded!

Stay in touch! If you liked this article:

Let me know on Twitter and share this article with your friends! Also, feel free to tweet me any follow up questions or thoughts.
Support me on patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! I also do a monthly Ask Me Anything Session for all Patrons!
Be the first to learn about my posts for more accessibility funsies!

Cheers! Have a great week!

An Introduction to Accessible Labeling

Lindsey Kopacz — Mon, 24 Jun 2019 14:33:16 +0000

Originally posted on a11ywithlindsey.com. If you'd like to see video examples of how screen readers interpret these, they are at the source!

Last week, I got a decent amount of folks who found the aria states blog post helpful. This week I wanted to continue with that and go over something that took me a long time to understand: labeling. How do you label things? What needs labeling? What is the difference between all the ways to label things?

After this post, you should have a firmer understanding of all things labels.

Form Labels

Lack of form labels is one of the most common places I see accessibility errors. Most people do something like this:

<form>
  <input type="search" placeholder="Search" />
</form>

I’m going to repeat it for those in the back:

Placeholder attributes are not enough to label a field for a screen reader.

To properly label this, we need to ensure that there is a <label> that exists and is also associated with the input. The way to associate it is to give the <input> element an id and to match that value to a for attribute on the label.

<form>
  <label for="search">Search</label>
  <input type="search" placeholder="Search" id="search" />
</form>

Take note that the string in the for attribute matches the id in the input. Matching these strings is how you associate them!

If a designer gives you a mock and there is absolutely no way to tell them to add a label to the design, you’re in luck. You can add a visually-hidden or sr-only (screen reader only) class. I always use this CSS from the a11y project:

.visually-hidden {
  position: absolute !important;
  height: 1px;
  width: 1px;
  overflow: hidden;
  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
  clip: rect(1px, 1px, 1px, 1px);
}

The above code would turn into this:

<form>
  <label class="visually-hidden" for="search">Search</label>
  <input type="search" placeholder="Search" id="search" />
</form>

Pretty simple, this applies to <select> elements as well.

Nesting inputs in labels

I’ve also seen people nest their inputs. Nested inputs aren’t my preferred method, but if I do something like this:

<form>
  <label>
    Search:
    <input type="search" />
  </label>
</form>

This HTML is valid and doesn’t produce any errors with the Wave tool. However, it makes it more difficult to visually hide the label, if that’s what you need to do. So choose your method based on your needs!

Using `aria-label`

As a disclaimer, this is my least favorite way to label things for screen readers. I prefer to label things with elements that exist in the markup. However, sometimes, it is necessary. A few times that I’ve found it necessary:

I had no control of the markup and had to change up the DOM in JavaScript. It’s way easier to setAttribute() than it is to create an entire element and append it.
I was working in an SVG that I couldn’t add <text> elements to

The way you use an aria-label is to put the string in the attribute. For example, I found this on the MDN site:

<svg
  class="icon icon-github"
  xmlns="http://www.w3.org/2000/svg"
  width="24"
  height="28"
  viewBox="0 0 24 28"
  aria-label="GitHub"
  role="img"
  focusable="false"
>
  <!-- all the children -->
</svg>

The aria-label attribute value does not need to match the id of another element.

`aria-describedby` and `aria-labelledby`

aria-describedby and aria-labelledby took awhile to demystify because the two attributes sound like they are the same. So let’s break them down into the literal sense.

Labels are like titles. They tell you what something is. When do we announce a title or a label: before the element.

Let’s take the third example from the MDN docs.

<div id="radio_label">My radio label</div>
<ul role="radiogroup" aria-labelledby="radio_label">
  <li role="radio">Item #1</li>
  <li role="radio">Item #2</li>
  <li role="radio">Item #3</li>
</ul>

When we use VoiceOver to navigate to the radio group, it reads “My radio label, radio group?” The radio label got announced before it told us about the radio group.

Let’s take the same markup from above and add an aria-describedby attribute with a div.

<div id="radio_label">My radio label</div>
<ul
  role="radiogroup"
  aria-labelledby="radio_label"
  aria-describedby="radio_desc"
>
  <li role="radio">Item #1</li>
  <li role="radio">Item #2</li>
  <li role="radio">Item #3</li>
</ul>
<div id="radio_desc">
  A bit more about this radio group. Here are some words.
</div>

The text “A bit more about this radio group. Here are some words” happens after VoiceOver announced after the radio group. It’s a very subtle difference where, in most cases, it won’t matter.

The strings that we put in these attributes are like the form labels above. We want the aria-describedby or aria-labelledby attribute to match the id of the element that we want the screen reader to read.

Conclusion

I hope I helped you understand a bit more about the confusing world of labeling for accessibility! Let me know on Twitter or comment below what you thought or if you have any other questions.

Also, I have a patreon! If you like my work, consider making a $1 monthly pledge. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! Cheers! Have a great week!

An Introduction to ARIA States

Lindsey Kopacz — Mon, 10 Jun 2019 13:40:35 +0000

Originally posted on a11ywithlindsey.com. If you'd like to see video examples of how screen readers interpret these, they are at the source!

Hey friends! Today’s blog post comes to you from my Patreon folks' poll. It’s a follow up from one of my previous posts about Demystifying ARIA. ARIA can be utterly mysterious and daunting, but it’s handy. One of my favorite ways to use it is to communicate state to screen readers.

I’m seeing a positive trend in the a11y community. Instead of using classes to style elements, a11y folks are styling by using ARIA attributes in the CSS. This helps enforce accessibility standards and prevent people from cheating accessibility. The attributes I’ll be going over today are aria-expanded, hidden, aria-hidden, and aria-current.

The `aria-expanded` attribute

aria-expanded is one of the few aria attributes that does not have an HTML5 equivalent. Please tweet me if I am wrong, but at the time of writing, I believe this to be correct. In the Accessible Accordion post, I used aria-expanded to convey the section’s state.

Why is this helpful? Let’s take the accordion example that I went through in the blog post that I linked in the previous paragraph:

Note: I changed the code in the above sample to have the CSS tied more to the attributes and less to CSS classes.

If you go through this on a screen reader, you’ll get something like this: "Section 1, Collapsed, Button." Then when you use the screen reader commands to open it, it will read: "Section 1, Expanded, Button." (If you'd like to see the video sample of this, check out the original blog post.)

Imagine if we took off the aria-expanded attribute which I did in a separate CodePen.

Note: I kept most of the original code in here. That way, I could demonstrate the visual opening and closing. Additionally, it shows how it doesn’t work for a screen reader user.

If you don't add in the aria-expanded attribute, when I press the open up the menu, it doesn't stop reading "Section 1, button" tell me if the accordion is open. The interruption is helpful to understand the space. (If you'd like to see the video sample of this, check out the original blog post.)

Do you notice how when I open the button, it doesn’t communicate whether the section is open or closed? This is critical for a screen reader user to know what is going on. Withholding verbal communication of state is confusing for screen reader users.

Anytime we hide content that expands upon user action, use aria-expanded. When you use JavaScript to toggle it, it becomes a better user experience.

The `hidden` attribute

If you saw my notes above, you may have seen that I changed up the code. Previously, I had the accordion using an aria-hidden attribute (more on that later). Upon the button click, I would toggle the value to be true or false. The reason for that is because hidden is the HTML equivalent of display: none.

When I started with accessibility, the motivation to hide content from screen readers baffled me. Why would I want to exclude them from content?? I used to be resistant to ever using hidden, but the reality is sometimes it’s necessary. With some forms of content, we don’t want to expose content to a user until we interact with it. For example, with modals and accordions, we only want to see what’s inside if they are open.

When to use `aria-hidden`

There's one significant difference between aria-hidden and hidden:

aria-hidden only hides elements from screen readers, while hidden hides from everyone.

I ask myself if there are HTML elements that are primarily for decoration. If so, I might want to use aria-hidden to hide it from screen readers but not from visually-abled users.

One of my favorite reason’s to use aria-hidden is to prevent repetition. This, for example, is the Home button for Twitter:

<a class="js-nav js-tooltip js-dynamic-tooltip">
  <span class="Icon Icon--home Icon--large"></span>
  <span class="Icon Icon--homeFilled Icon--large u-textUserColor"></span>
  <span class="text" aria-hidden="true">Home</span>
  <span class="u-hiddenVisually a11y-inactive-page-text">Home</span>
  <span class="u-hiddenVisually a11y-active-page-text">
    Home, current page.
  </span>
  <span class="u-hiddenVisually hidden-new-items-text">
    New Tweets available.
  </span>
</a>

In this instance, the screen reader announces one of the “a11y page texts” based on the context of the page. I want you to take note of this line of code:

<span class="text" aria-hidden="true">Home</span>

This is the one that is actually on the screen. We have the dynamic options for the screen reader like “Home,” “Home, current page,” and “Load new Tweets.” We don’t need that context on the Home button if we can see the visual cues.

With that being said, my rule is if we are toggling states, I use hidden. If there’s duplicate or unnecessary content, I’ll use aria-hidden.

The `aria-current` attribute

Fun fact, this one is totally new to me. I didn’t learn about this until I saw Eric Bailey’s tweet about the a11y project redesign:

// Detect dark theme var iframe = document.getElementById('tweet-1134863254310797312-703'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1134863254310797312&theme=dark" }

The best part about the web and accessibility practices is I learn something new every day. After seeing this tweet, I found Léonie’s post on aria-current. Something they pointed out is that we predominately use CSS to show the “current” element visually. In my Drupal days, most themes had an .is-active class if you were on a menu item that reflected the current URL.

As Léonie said, the problem with this approach is CSS is mostly visual. Meaning (with an exception) 0 of the styling is exposed to screen readers. Using aria-current helps ensure that we communicate the context to screen reader users. According to WAI-ARIA 1.1, there are a few values that aria-current could take on:

page for a link within a set of pagination links, the current page as represented in the navigation, etc.
step for a step-based process.
date for a current date.
time for a current time.

Additionally, this should be only one element in a set of elements can have an aria-current value. Otherwise, it will confuse the screen reader!

Conclusion

I plan to have more blog posts about ARIA and state in the future. I hope this helped you demystify a few more aria attributes.

Let me know on Twitter what you think! Also, I now have a patreon! If you like my work, consider becoming a patron. You’ll be able to vote on future blog posts if you make a \$5 pledge or higher! Cheers! Have a great week!

My Blogging Editing Process

Lindsey Kopacz — Mon, 03 Jun 2019 17:37:50 +0000

Originally posted on www.a11ywithlindsey.com.

Hej från sverige! I’m writing this from Stockholm Airport! I’m on my way to Copenhagen to visit a friend (although when I publish this, I likely will be back in America). I am coming back into my blogging headspace after a bit of a wild week. I spoke about JavaScript and Accessibility for the Spotify Engineering team! Preparing to speak for my first time internationally was rough. However, I cannot even begin to explain how rewarding this experience has been. It’s a talk I’ve wanted to give for a long time, and for a good reason. It was well received, and I had many folks come up to me afterward.

This post isn’t going to be a talk about speaking. I wanted to give you a glimpse because if you don’t follow me on Twitter, you would have no idea! Onto blogging!

A few weeks ago, I asked people if they had an interest in my blog editing process. I’m very public about my writing process, and the idea popped into my head.

Random question: would people be interested to hear about my editing process?

I have ADHD and I'm a Type A perfectionist. Editing used to be a challenge, but I've gotten way better and shortened my process a ton! https://t.co/3HdXdgHMM1
— Lindsey Kopacz 🐞in Stockholm 🇸🇪 (@LittleKope) May 3, 2019

I had an overwhelming response that said yes. I also asked on my Patreon. While my last post about JavaScript and Accordions won out, this topic was a close second. So here we are!

Starting out

First comes writing the thing. Many people have formats like writing outlines and where their points are. I wish I could say I consistently write outlines...but I don’t. I either look to Patreon, Twitter, or a long list of ideas I have written down and pick a topic and get to writing.

Instead of creating a formal outline, I pull up my Markdown file. In the markdown file, I start creating headings about how I want to group my thoughts. These headings are pseudo outlining, I suppose, but I don’t go through the bullet-pointed list. I tend to add structure during my editing process and let my creative juices flow. I firmly believe that my blog posts are unique because I start this way, then make it more coherent later. That energy is part of who I am, and I also think it helps me relate to people and helps me creatively solve problems.

If you struggle with feeling all over the place, remember you can always edit it out later. I use tools to help me edit my sloppy writing into cohesive sentences. Some of my best writing comes from going with the flow.

My only exception is when I write code-heavy posts, which takes a little more planning.

If I am writing my code-heavy posts

If I am writing a more technical blog post, writing code samples is the most time-consuming part. I try to note when I want to schedule a blog post because writing coding examples from scratch adds time. I should take my advice - I still think I can write these on a Sunday afternoon. Then it ends up taking 3-4 more days than I thought it would.

I tend to be more outlined in these posts than usual because these types of posts follow a step by step nature. I like to organize how I would solve the problem first. My blogging organization for code-heavy posts is about the following:

Come up with a goal of what I want to teach and what type of examples I would want to do.
Create a few CodePen's showing where I want to be at different stages of the code.
Through each step of the code, use the markdown code syntax and diff to show where the code changes.

- some code I am deleted
+ some code I am adding

I try not to overanalyze this part because as I said before, it is the most time-consuming part. The more I overanalyze, the longer it takes me to write my code.

The Editing Process

The editing process has been one of the hardest things for me to learn. I often get distracted, but I also have perfectionist tendencies. The anxiety of leaving an error or typo is challenging to overcome. Logically, I know it is not the end of the world. Editing used to turn into a long process. Every single time I paused or got distracted, I would lose my place and start over.

I’ve refined my process a bit based on tips I’ve received from friends and what works best from me.

Run through Hemingway

When I was researching accessibility and dyslexia, I found the Hemingway App. It quickly became one of my favorite tools. This app lets you know when your sentences are becoming hard to read. It’s a helpful first step for me in narrowing down the creative energy into cohesion. It helps me translate any word vomit into coherent sentences. The app also catches wordiness, useless adverbs, passive voice, etc.

Run it through Grammarly

I love the Grammarly app! I pay for the premium version, but the free version is excellent as well! Grammarly helps me catch many typos, words I use too often, and improper punctuation. With the paid version, it even knows to capitalizes CSS and HTML. These corrections are a feature where you can specify that you are writing something technical (this is for the Premium version).

Run it through VoiceOver

This is my favorite part of the process. I learned the commands of VoiceOver as I learn about accessibility. VoiceOver is the built-in screen reader for MacOS. I had never thought to have it read to me as a way to edit until one of my Twitter followers suggested it!

To have VoiceOver start reading it to me, I will:

Turn on voiceover by pressing cmd + F5.
I will double click on the title header and start pressing ctrl + option + The right arrow.
The screen reader reads it out to me.

Reading something out loud is one of the best ways to learn that something sounds off. However, sometimes, I get so distracted in the process that I’ll start over or get lost. Without using my screen reader, editing takes forever.

Walk through my code samples

If I am writing code for that blog post (which many times I am), I want to go through every single step of the post. I will copy and paste the code from a CodePen into an index.html file. I’ll follow my diffs to make sure that I accounted for every single step.

Going through this step by step ensures:

My code works if someone else were to go through it
I didn't forget to show my readers a crucial step
Catch any assumptions you make.

This last one is important. There were a couple of times where I thought something was working, but it wasn't. Giving my audience code that doesn't work isn't particularly helpful!

Conclusion

I love using tools to help me edit. The anxiety and time that it takes to write and publish a post can be downright daunting. I’ve used this process to cut down the amount of time it takes me to edit, and I hope it helps you as well! Blogging as a developer is very rewarding, and I’m glad I’ve found a process that works for me.

Let me know on Twitter what you think! Also, I now have a patreon! If you like my work, consider becoming a patron. You’ll be able to vote on future blog posts if you make a $5 pledge or higher! Cheers! Have a great week!

7 Ways to make your Tweets more Accessible

Lindsey Kopacz — Wed, 22 May 2019 08:57:22 +0000

Originally posted on www.a11ywithlindsey.com. In that post I've included videos with how it sounds to screen readers, but because they aren't hosted on youtube, I cannot link them here. Check them out on the original blog post!

I wrote a tweet thread a while back where I started talking about ways to keep accessibility in mind on the platforms we use such as Twitter. Sometimes we don’t have control over the platforms we use, and the best we can do is ensure our content is accessible. This tweet thread got a decent amount of attention, but unfortunately, it’s easy for things to get lost in the Twitterverse. I decided to write a blog post elaborating a bit more on each of the critical points I made while also ensuring that you could find them more easily.

Be careful with your emoji use

Thank 👏 you 👏 Kent! (don't do the clap thing either, it's a huge pain in screen readers)
— Marcy Sutton (@marcysutton) January 9, 2019

Marcy pointed out here how the clapping hands are actually a pain for screenreaders.

Here’s what it reads if you turn on your screenreader: “Thank clapping hands you clapping hands Kent.” Can you imagine if it was done between every single word on a longer sentence? I see passionate people do this all the time, particularly when they want to say something regarding social issues. I get torn between two worlds because I know how awful it is for screenreaders, but usually, there is a message behind the tweet that I support.

In general, we should be careful about our emoji use. I created a tweet just for the purposes of this blog post. If we clog an entire tweet with just emojis and no words it sounds like word vomit.

I love emojis, but let's not abuse them. We should use words more!

Don’t use special characters in your handle or your tweets

I’ve already mentioned this tweet in previous posts, but I’ll repeat it:

You 𝘵𝘩𝘪𝘯𝘬 it's 𝒸𝓊𝓉ℯ to 𝘄𝗿𝗶𝘁𝗲 your tweets and usernames 𝖙𝖍𝖎𝖘 𝖜𝖆𝖞. But have you 𝙡𝙞𝙨𝙩𝙚𝙣𝙚𝙙 to what it 𝘴𝘰𝘶𝘯𝘥𝘴 𝘭𝘪𝘬𝘦 with assistive technologies like 𝓥𝓸𝓲𝓬𝓮𝓞𝓿𝓮𝓻? pic.twitter.com/CywCf1b3Lm
— Kent C. Dodds (@kentcdodds) January 9, 2019

If you listen to his video, can you hear how much it doesn’t make any sense? It may not be as cute or as fancy, but it's usually a good idea to not try to use fonts that are unsupported on the platform. Twitter doesn't give you the ability to choose a font, so you shouldn't try without testing to ensure it works for everyone.

Enable Alternative Text on your Tweets

And actually use them! If you’re on your Desktop computer, you can enable them by:

Click on your Profile Picture and go to Settings & Privacy
Go to the Accessibility Section in the left sidebar
Check “Compose image descriptions”

Look, I even recorded it for you!

Once you get this enabled, you should be able to see an “Add Description” on your images. Also, Twitter, why isn't this enabled by default?

Test your Profile’s Page Contrast

Have you ever tested the color contrast on your Twitter Profile theme? After checking the default themes on my Twitter profile, I discovered that they have shockingly poor contrast. I use the Webaim Color Contrast Checker to see what the contrast is. The minimum contrast for Large Text is 3:1 and for small text is 4.5:1. Here are the contrast colors:

Orange Theme - The background color is #FE6A1F on a white foreground color which has a contrast of 2:88:1. (FAIL)
Yellow Theme - The background color is #FAB81D on a white foreground color which has a contrast of 1.76:1. (FAIL)
Light Mint Theme - The background color is #7FDBB6 on a white foreground color which has a contrast of 1.65:1. (FAIL)
Mint Theme - The background color is #19CE86 on white foreground color which has a contrast of 2.06:1. (FAIL)
Periwinkle Theme - The background color is #91D1FA on a white foreground color which has a contrast of 1.65:1. (FAIL)
Blue Theme - The background color is #1A94E0 on a white foreground color which has a contrast of 3.30:1. (PASS large text only)
Gray Theme - The background color is #ABB8C1 on a white foreground color which has a contrast of 2.03:1. (FAIL)
Dark Pink Theme - The background color is #E81C4F on a white foreground color which has a contrast of 4.46:1. (PASS large text only)
Light Pink Theme - The background color is #F58EA7 on a white foreground color which has a contrast of 2.26:1. (FAIL)
Purple Theme - The background color is #981CEB on a white foreground color which has a contrast of 5.67:1. (PASS both large and small text)

So if you count that, out of 10 themes only 1 (!!) has a passing contrast on both large and small text. 2 pass with larger text. The rest fail. This stinks on Twitter's part, but you can also add your own custom HEX Color Code! I just changed mine to have it be one of the colors in my design on my site.

Communicate with words, not symbols making a picture

“Today’s tea” seems to be pretty popular on Twitter, but I can’t stop thinking about what this sounds like on a screen reader.

Today's tea:
(
( ) )
_(_____)____(_____(____(_
\ Grad students /_
\ should be / |
\ paid livable /___|
\ wages for /
\ their hard /
\_ work _/
— Jay Shelat (@jshelat1) February 7, 2019

Because I couldn't stop thinking about it, I found a tweet and turned on my screen reader. I posted a video on my blog about what it sounds like.

So, uh, yeah. Not sure how to fix it aside from not doing it.

Transcribe Memes and Gifs

As of this writing, there is no way to add alt text to gifs. I usually do this by typing in [gif alt: Descriptive phrase] in the body whenever I add a gif. Sometimes I see people respond back to me with a gif message and a gif alt back, and that makes my heart sing. You should do the same with Memes, especially once you have enabled Alternative Text on your photos using the tip above. (Source: Life of a Blind Girl: 6 ways to make your social media posts accessible for people with a visual impairment)

Capitalize the words in your hashtags

This one is new to me, but it makes a lot of sense. Without it, it makes a lot of screen readers mash up the words and sound like a jumbled mess. (Source: Life of a Blind Girl: 6 ways to make your social media posts accessible for people with a visual impairment)

Conclusion

I want to thank people who write blog posts like the one mentioned for the source of the last two sections. If you haven't already, I would read that article because there are items that I wanted to include, but this post was starting to get too long. Even as an accessibility person, I still have a ton to learn about these platforms. I have also learned a lot from great advocates in tech as well, such as Marcy Sutton, Deborah Edwards-Onoro, and Tatiana Mac! Accessibility isn’t just about coding, it’s about real people who use products that have become everyday use and commonplace.

Remember to think before you tweet. Who are you potentially excluding from reading your Twitter content? If you have any thoughts on this post, feel free to reach out to me on, you guessed it, Twitter.

DEV Community: Lindsey Kopacz

Creating an Accessible Range Slider with CSS

Considerations

Starting out

Browser Specific Pseudo Elements

Using linear-gradient

Designing the thumb

Adding custom focus states

When it gets hairy

Conclusion

How Accessibility Taught me to be Better at JavaScript - Part Two

Starting out

How I approached the problem

What I would change now

Conclusion

10 Ways to Help Accessibility at Conferences as a Speaker

Introducing yourself with your pronouns

Creating readable shortened links

Include your slide link at the beginning

Spell out abbreviations, especially for links

Having proper contrast on your slides (and code samples!)

Articulate alt text

Avoid using vague words

Content Warnings before Gifs

Not using too much slide animation

Ensure the conference is accessible

Conclusion

Accessibility in d3 Donut Charts

Starting out

Option 1: Make the tooltips accessible

Option 2: Creating a separate legend

Conclusion

How Accessibility Taught me to be Better at JavaScript - Part One

Background

The requirements

Starting in JavaScript

Accessibility Issues

What I wish I had done:

Progressive Enhancements that I wish I had done

Adding context with ARIA

Conclusion

Reducing Motion to Improve Accessibility

Understanding prefers-reduced-motion

How you do it

How to test on a mac

Creating a user controlled option to reduce motion

Creating a <ReduceToggle /> Component

Adding in the states

Adding CSS to the data-user-reduced-motion

Adding localStorage

Conclusion

Create custom keyboard accessible radio buttons

Starting out

Creating a pseudo-element on the label

Add :checked styling in CSS

Add focus styling

Conclusion

A11y Lessons I Learned when Starting a Podcast

Transcripts are a MUST

Having someone do it for you

Using Artificial Intelligence

What we ended up doing

A11y Considerations for Custom Podcast Players

Button Labelling

Creating a slider

How I want to redo the slider

Conclusions

An Introduction to Accessible Labeling

Form Labels

Nesting inputs in labels

Using aria-label

aria-describedby and aria-labelledby

Conclusion

An Introduction to ARIA States

The aria-expanded attribute

The hidden attribute

When to use aria-hidden

The aria-current attribute

Conclusion

My Blogging Editing Process

Understanding `prefers-reduced-motion`

Creating a `<ReduceToggle />` Component

Adding CSS to the `data-user-reduced-motion`

Adding `localStorage`

Add `:checked` styling in CSS

Using `aria-label`

`aria-describedby` and `aria-labelledby`

The `aria-expanded` attribute

The `hidden` attribute

When to use `aria-hidden`

The `aria-current` attribute