Guided: Accommodating Images and Media for Web Accessibility

In this guided lab, you will learn about ways to make images and rich media more accessible on the web in order to meet WCAG 2 level AA success criteria.

What to Expect

You will begin with a demo site that contains examples which are inaccessible and work through tasks to make them accessible.

You only need to know basic HTML, CSS, and JavaScript to work through the lab.

info> This lab is a companion for the Accommodating Images and Media for Web Accessibility course. You'll get hands-on with the concepts and techniques shown in the course.

info> Stuck on a task? Click the "Task Solution" after attempting a task to see a hint of the solution. You can also reference the full solutions in the solutions/ folder in the workspace. Each folder and file corresponds to the step number. Solution filenames are prefixed with the step-task number and path to the associated demo file. For example, 5.1~gift.html corresponds to Step 5, Task 1, for the demo/gift.html file.

What are the WCAG?

The Web Content Accessibility Guidelines (WCAG) provide a standardized framework for web sites to accommodate the needs of people that have disabilities or impairments while browsing. It is an internationally recognized standard put together by the W3C under their Web Accessbility Initiative (WAI) project.

The WCAG follows a well-defined structure: each Guideline is accompanied by Success Criteria, which can be satisfied using various Techniques.

There are three levels of Success Criteria: A, AA, and AAA, corresponding to successive levels of conformance.

info> The focus of this lab will be to provide examples that conform up to level AA, which is a balanced set of success criteria.

Impact of Rich Media On Web Accessibility

Rich media like images or videos tends to affect users that have hearing or vision impairments.

For many of these users, they rely on screen readers on their device to browse a website. Screen readers can only read text, which means that most of the accommodation for images and media relies on providing text alternatives for any non-text content.

These are covered by Guidelines 1.1 (Text Alternatives) and 1.2 (Time-based Media).

Following Along With a Screen Reader

The best way to test whether your app is accessible is by using assistive technology the same way your users would. Since this a lab environment, tasks are not verified with assistive technology and are only verified based on syntax. You are encouraged to explore the demo tasks before/after with a screen reader like NVDA or Mac VoiceOver.

info> Don't know how to use a screen reader? Check out the Pluralsight course Accessibility: Testing and Screen Reader Use

Throughout the lab, actual screen reader text is provided for context using the Mac VoiceOver utility, using this kind of blockquote call-out:

VO: "The Mac VoiceOver speech caption."

The WCAG 1.1.1 (Level A) success criteria lays out the guidelines for providing non-text alternatives.

It distinguishes between two types of images: decorative and functional.

• A decorative image serves only an aesthetic purpose, provides no meaningful information, and should be ignored by assistive technology because it is distracting and may confuse the user.

• A functional image serves an informational purpose and without it the user may not understand what the content means. These are required to have a text alternative that assistive technology can read.

Deciding Which is Which

One of the first steps to accommodating images for web accessibility is to determine at the element level which type of image is being used, which dictates the approach.

Here are some common decorative images:

• Profile picture
• Background art
• Icon (with label)
• Stock photo

And some functional images:

• Image button
• Icon (without label)
• Promotional ad
• Infographic or chart

A rule of thumb when deciding whether an image is decorative or functional is to ask:

If this image is described, does it increase understanding of the context or detract from it?

Context is key.

Alternative Text for HTML Images

An HTML image element supports the alt attribute to provide alternative text content for the src image.

For example, a user avatar that is displayed using the HTML <img> tag might look like this:

<img src="avatars/user/ac34s45.jpg" width="16" height="16">
<span>Pluralsight User</span>

Without an accompanying visual, just looking at the code you have no idea what may be in this user avatar -- but if you did, would it matter? In this case, the user avatar image doesn't serve an informational purpose therefore it should be considered a decorative image.

Decorative Images Should Be Ignored

What may not be obvious is that by default, without an alt attribute set, a screen reader will attempt to read this image out loud.

"VO: slash a-c-3-4-s-4-5 dot j-p-g, Unlabeled image. Pluralsight user"

This is not helpful for the screen reader user and the decorative image should be ignored.

You can do that by setting the image element alt tag to an empty value:

<img alt="" src="avatars/user/ac34s45.jpg" width="16" height="16">
<span>Pluralsight User</span>

This means the absence of an alt tag is not the same as setting it to an empty value.

info> You should also avoid adding a title attribute if you want assistive technology to ignore the element, as it is used as a fallback if alt is empty. Before the screen reader would read the "John Doe" alt text out loud, which was repetitive and confusing.

Can you identify other decorative images that exist on the Carved Rock Fitness homepage? You may have seen other <img> elements on the page that look to serve a purpose for the user, such as the logo and social icons.

These are functional images and they are currently missing alternative text.

Functional images are required to provide a text alternative for assistive technology.

Functional HTML Images

You've already seen how to provide alt text to HTML image elements and setting it to an empty string causes the image to be skipped.

You can guess that providing an alt text will cause it to be read out loud. ## Use Clear Labels

A common mistake is when developers provide alt text or other alternative content that "describes" the non-text content. Instead, the text should convey the same information.

In other words, if you swapped out the image or media with the alternative text, would it be materially the same? ## HTML Images vs. CSS Images

If you view the homepage in the browser, and you are a sighted user, you will see that the hero section is showing a promotion:

Get a grip
20% off throughout the season

Except, this text is not actually in the HTML, it's embedded within an image. And that image is not provided by an <img> tag, which is why you may have missed it when only looking at the code.

It is provided using the CSS background-image property (or background shorthand):

.crf-hero {
  background-image: url("../img/img-hero-promo.jpg");
}

If you are a user using a screen reader, you would completely miss the fact there's an ongoing promotion.

For functional images, WCAG advises always including them using the HTML <img> tag instead of relying on CSS images, which should only be used for decorative images.

You can then take advantage of the alt tag to provide alternative text. If you take a look at {{localhost}}/demo/home.html you will see that the change you made has resulted in an image that no longer stretches across the screen.

Not only does this not look as good, it still isn't ideal for accessibility because the image has embedded text in it.

Avoid Embedded Text

What would be better is to keep the background photo of the climber as a decorative image with CSS but move the text out of the image.

Images should not contain functional text and there are many benefits to extracting it:

• Ability to offer translations or localization
• Ability to adjust to user's screen size or font preferences (DPI, contrast, etc.)
• Sharper legibility with native font rendering
• Easier for you to maintain and update
• Accessible to assistive technology
• Makes the image become decorative

Now try opening {{localhost}}/demo/home.html in a new browser tab and resizing the window.

By changing the CSS image to one without text and adding it to the HTML instead, the jumbotron adjusts to your viewport size to ensure the text remains readable at all sizes.

You've not only made the promotion more accessible to impaired users, you've improved the user experience for everyone.

Remember: improving accessibility often improves the experience for all users!

If you scroll down the homepage, there is another promotion for a "couple's retreat weekend."

The promotional text reads:

Couples retreat weekend. Save an extra 20% when you buy 2 pairs of boots.

In this lab the HTML is static but imagine that this promotional image is dynamically fetched from a content management system (CMS). Despite your concerns, for whatever reason there is no way to change the system to allow embedding text as markup as you did previously.

When it is not possible to extract embedded text in an image, you can use ARIA attributes to provide alternative content.

ARIA attributes start with aria-* and provide many different ways to specify accessible metadata. This lab will only cover a small subset that relate to images and media.

ARIA Labels

If you need to provide non-visible text labels, you can provide an accessible label for an element using the aria-label attribute:

<div aria-label="Sponsored ads.">
  <img src="https://ads.pluralsight.com/x/s/1.png" 
    alt="20% off Black Friday sale">
<div>

The screen reader voice over for this example will read the aria-label before the image's alt text, providing additional context to the user:

VO: "Sponsored ads, group. 20% off Black Friday sale, image."

This can be useful when needing to provide non-visible labels for groups of media or when the media itself doesn't provide enough context. Now that the couple's retreat promo has an aria-label, how does the screen reader treat it?

VO: "Link. Couple's retreat weekend. Save an extra 20% off when you buy two pairs of boots."

Great! But... there's a problem.

It did not read out the link to navigate to the sale page. This is because the aria-label overrode the default handling of the link role assigned by default to an <a> element.

ARIA Roles

Every element has a role by default in ARIA. For example, a <button> element has a button role. A <a> element has a role link.

These roles will dictate how a screen reader treats an element and influences how it gets read out loud.

Depending on the role, text will be read from an aria-label attribute, aria-labelledby reference element, or, like in this case, the inner text of the element.

Since the <a> element is styled to provide the CSS background image, providing link text would overlap on top of the image. Yet, since it has an ARIA role of link, the screen reader will attempt to read the inner text and will ignore the aria-label attribute.

The solution is to introduce another element to act as the label. This element can be empty but can provide an aria-label. Now when the screen reader encounters the promotion area, it reads both the deal text and announces the link to the sale:

VO: "Link. Couple's retreat weekend. Save an extra 20% off when you buy two pairs of boots. Visit sale page."

Often with accessibility work, you'll need to go back and forth with the HTML and screen reader to get it just right.

info> Real life can be messy. Ideally, the text would have been extracted from the image as you did previously but if this can't be avoided, ARIA labels provide a way to accommodate alternative content. The WCAG success criteria can often be met in multiple ways to accommodate real-world quirks like this.

Labeling HTML/CSS Visuals

In the Carved Rock Fitness homepage, on mobile screens, a "hamburger" menu button is shown to toggle the navigation:

This is not using an image tag or CSS background image, instead it is using HTML markup and CSS styling to create the "icon".

ARIA labels can be useful for these type of visuals that don't rely on an img tag or CSS backgrounds. Now when the user uses their keyboard to focus on the button, assistive technology will read out the label so they know to toggle the navigation menu.

Sometimes you will need to deal with hiding images and media from assistive technology to avoid confusion.

There are three main ways to hide content from assistive technologies:

• Use the display: none CSS property
• Use the hidden HTML attribute
• Use aria-hidden attribute

When should you use each one?

Hiding Using CSS

The display: none CSS property will hide an element completely from both sighted users and screen readers.

It is useful in situations where the media may only be used for non-human interactions, such as tracking pixels, scripting, or when it duplicates some other media nearby.

In the lab, the hidden CSS class is made available through the Bootstrap framework which applies display: none like this:

.hidden { display: none !important; }

The !important! CSS flag will override inline styles and prevent conflicts so the element is always hidden. Now on the gift page, the summary thank you section is hidden by default until the message is submitted.

The class is removed using the JavaScript code:

function showSummary() {
  const summarySection = document.getElementById('summary-section');
  summarySection.classList.remove('hidden-element');
}

This will work but there is another method to hide elements that works better with scripting.

Using the Hidden Attribute

For HTML elements, the hidden attribute is effectively the same as the display: none value.

In the previous task, you needed to update a CSS class to target the element. Sometimes, you may not easily have access to the CSS styles, or your markup is more dynamic.

While it's possible to use inline CSS styles, using the hidden attribute may be clearer:

<div hidden>
Do not show me yet
</div>

You also can set the hidden attribute using JavaScript code:

const el = document.getElementById('my-el');
el.hidden = true;

A boolean value is much easier to set than trying to dynamically modify the display CSS value or CSS class name list. ## Using the aria-hidden Attribute

Both the previous approaches hide the element from both sighted and non-sighted users.

Sometimes you may only want to hide an element from assistive technology but let it remain visible for sighted users.

In this case, setting the aria-hidden attribute will cause it to be ignored by assistive technology.

<span aria-hidden="true">Ignored by screen readers</span>
``` Could you have also used an empty alt text or switched it to a CSS background? Yes, but you don't always control how an image is included on the page or developers may forget to add alt text. Explicitly setting `aria-hidden="true"` will avoid any possibility of the image being detected by a screen reader even if the `alt` tag isn't properly implemented.

Consider information-rich images like diagrams, infographics, or data visualizations. Data is presented in a visually appealing way but there still needs to be a way for assistive technology to present that data effectively to users.

The challenge is that describing complex images is beyond the capability of a simple alt or aria-label attribute.

Visible Long Descriptions

The simplest solution for complex images that meets the WCAG success criteria is to provide a text alternative immediately following the graphic.

There is no additional work needed if the explanation can be shown to all users. This is called a "visible long description."

<img src="infographic.jpg" 
  alt="Infographic: A title. Summarized below.">

<p>A longer explanation of the graphic above...</p>

When providing a long description, the image alt text is a short description and you can use it to specify what the image is (e.g. an infographic) and that the summary is after the image. ## Invisible Long Descriptions

There are times where the extra description doesn't need to be shown visually and should only be kept for assistive technology.

In this case, you can use an "invisible" ARIA description with the aria-describedby attribute and hiding the content visually using CSS.

The aria-describedby ARIA attribute allows you to "link" an element to another element that will be used by assistive technology to describe the source content:

<img 
  src="infographic.png" 
  alt="Infographic: A diagram representing how internet browsing works. Summarized below." 
  aria-describedby="infographic-flow-explanation">

<details id="infographic-flow-explanation" class="sr-obly">
  <summary>Infographic: How Internet Browsing Works</summary>

  A user's laptop initiates an HTTP request to a server on the public internet...
</details>

Here the image is described by the infographic-flow-explanation element which uses an HTML details element.

The linked element can be any valid HTML structure, which allows for more expressive long-form alternative content.

The sr-only CSS class is a utility class that hides content visually but maintains it for assistive technology. In this lab, the CSS comes from the Bootstrap framework. The aria-describedby attribute is useful for images or media that can be explained through long-form text but what about data?

Charts, graphs, or data visualizations may use rich media to display data with an image or JavaScript that requires a simpler alternative for assistive technology users to consume.

Choosing Accessible Libraries

It's important when dynamically displaying data, you choose libraries or frameworks that make it easy to provide alternative content for assistive technology users.

The Highcharts library is an example of a charting library that provides many features that make your charts accessible.

Using Data Tables

Whichever method you choose for displaying charts or graphics, to accommodate them for web accessibility you will need to use data tables (WCAG Technique H51) which can be implemented with the <table> element.

HTML data tables require some additional setup to work well for assistive technology.

Here is a basic HTML data table for example:

<table>
  <tr>
    <td>Quarter</td>
    <td>Sales</td>
  </tr>
  <tr>
    <td>Q1 2024</td>
    <td>$50,000</td>
  </tr>
</table>

When the screen reader encounters this, it's informative to listen to how it reads each row and column:

VO: "Quarter, group. Sales, group. Q1 2024, group. Q1 2024. $50,000, group. $50,000. (...)"

It is repeating the contents of the cell, which isn't a great experience.

Describing the Dataset

The first step is to clearly describe the dataset so the user knows what to expect. This can be done by the <caption> element and it must be the first child element of a table.

<table>
  <caption>Quarterly Sales in USD</caption>
</table>

After the caption, you can declare the table header columns using both the <thead> and <th> elements, like this:

<table>
  <caption>Quarterly Sales in USD</caption>
  <thead>
    <tr>
      <th>Quarter</th>
      <th>Sales</th>
    </tr>
  </thead>
</table>

The data itself will be part of the table body using the tbody tag:

<table>
  <caption>Quarterly Sales in USD</caption>
  <thead>
    <tr>
      <th>Quarter</th>
      <th>Sales</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Q1</td>
      <td>$50,000</td>
    </tr>
	</tbody>
</table>
``` If you listen to how Mac VoiceOver reads the table, you'll hear:

> VO: "Row 1 of 6, column 1 of 2, Destination. Row 1 of 6, column 2 of 2, popularity percentage. Row 2 of 6, column 1 of 2, Australia. Row 2 of 7,  column 2 of 2, 35%"

This is somewhat better, at least it's not repeating the cell values but it still isn't ideal.

With very big data sets, by the time a user is a few rows in, they've already forgotten what each column represents and they numbering announcement is very repetitive and distracting.

## Specifying the Scope

By using the HTML `scope` attribute, you can declare to the assistive technology at what level to [associate the data](https://www.w3.org/WAI/WCAG22/Techniques/html/H63) (WCAG Technique H63) in the cell.

For example, the first column is usually the "row header" which can be specified using the `th` element and `scope` attribute set to `row`:

```html
<table>
  <caption>Quarterly Sales</caption>
  <thead>
    <tr>
      <th>Quarter</th>
      <th>Sales</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Q1</th>
      <td>$50,000</td>
    </tr>
  </tbody>
</table>

Assistive technology will then be able to associate the Q1 row header value with the table heading in the same column position (Quarter). Using a screen reader to navigate the table now, you'll hear it announce the row headers for context:

VO: "Row 2 of 7, Destination, Australia. You are in a row header." (navigate to next cell)
VO: "Column 2 of 2, Popularity percentage, 35%."

Note how it does not re-announce the row or header when you're on a secondary column. By associating the destination with the scope row and marking as a th, screen readers treat it as a row header.

Providing alternative content for audio depends on whether it is live or pre-recorded. For pre-recorded audio, you can provide a text alternative that presents equivalent information (WCAG Guideline 1.2.1).

Providing a Transcript

For prerecorded audio-only content, the technique is to use aria-describedby and provide a full long description of the content (WCAG Technique G158). This can be provided inline on the page or as a link.

A long description for audio is usually called the transcript.

Writing a Transcript

There are no standards defining how to write a transcript, but typically it would follow a format like this:

[Intro Music]

[Podcast Announcer: In a world...]

Ruth (Host): Hello everyone! Welcome to the Carved Rock Fitness podcast. I'm your host Ruth and I'd like to welcome today's guest, Dalilah, thanks for being here.

Dalilah (Guest): Oh, yes, thanks Ruth, happy to be here.

[Promotional interstitial: Are your shoes wearing down too quickly? ...]

Music, sound effects, or non-critical audio might be put into brackets or parenthesis to separate them from the main content. Speakers are labeled. The script represents what is said exactly, including filler words or phrases if they convey meaning. The transcript is now provided as a linked document for the podcast episode.

Assistive technology will understand the link and allow users to quickly navigate to the transcript if they want.

Ensuring Accuracy

If the audio was produced with a script, this is a good place to start but it is not sufficient to pass the WCAG success criteria.

This is because a transcript must represent the exact dialogue used (which can differ from the original script) as well as provide descriptions for background audio or noises.

Verbatim or Not?

Natural speech patterns often:

• Contain filler words like "um", "uh", or "like"
• Have interrupted words or phrases ("No, I wouldn't--well--yes.")
• Emphasizes different words ("I wouldn't do that." vs. I wouldn't do that.")
• Use incorrect grammar
• Use regional dialect or casual words ("gonna" vs. "going to")
• Use different tones to convey (e.g. angrily, excitedly)

The guidelines for alternative time-based media do not explicitly say whether transcripts should be verbatim or to what extent the content can be edited but Section 508 provides advice for captions and transcripts.

Ultimately, the intent of the guideline is that consuming the alternative text should convey the exact same meaning and information as listening to the audio.

Therefore, whether to keep or remove words depends on their context.

• If a filler word conveys meaning (like uncertainty), keep it.
• If a speaker coveys anger by saying something angrily, note it explicitly (e.g. [Angrily] "No!").
• If a word is emphasized, use emphasis.

Videos are one of the most complex media types to accommodate for accessibility. This is because a video involves both audio and visuals and both need to be accounted for.

Decorative Videos

Background videos or animations are decorative, and like decorative images, don't require an alternate description.

Providing an Audio Description

Pre-recorded video with an audio track must provide an audio description to meet level AA success criteria (WCAG SC 1.2.5, Audio Description (Pre-recorded)).

An audio description adds important details about actions, characters, scene changes, and on-screen text during pauses in dialogue, helping to explain the video content when it’s not visible.

To provide an audio description alternative for a pre-recorded video, it is common to link to it as an alternative format for users to access. In more sophisticated video players, you could also use scripting to dynamically enable or disable a separate audio track. If you listen to the linked audio description in your browser, you can hear brief descriptions of the video shown on the page.

Providing an audio description conforms to level AA WCAG success criteria but as you can tell, it does require extra production to edit the original audio track.

Providing Captions

To meet WCAG 2 Level A success criteria, it is more common to provide captions. You may also hear the term "subtitles" but these are not the same thing:

• Subtitles are used for translating the original spoken word to different languages for multi-lingual users.
• Captions include subtitles but also describe sound effects, music, and what is being shown in the video similar to audio descriptions for hearing impaired users.

Since providing translations through subtitles is more related to internationalization and localization, you can think of captions as a superset that encompasses translation plus provides accessible text for hearing impaired users.

For web-based media, you can use the WebVTT API to provide caption files to video elements. This is done using the <track> element:

<video src="...">
  <track 
    kind="captions" 
    src="captions.vtt" 
    srclang="en" 
    label="English" 
    default>
</video>

In this example, a captions.vtt WebVTT file is used to provide English-language captions as the default.

WebVTT files are a plain text file that uses timestamps to show captions:

WEBVTT

00:00:00.000 --> 00:00:06.228
Welcome back to the Carved Rock podcast #187. I'm your host, Kleiman Carl, and today's

00:00:06.228 --> 00:00:12.461
episode of the podcast is brought to you by Carved Rock Fitness Footwear. Head to CarvedRockFitness.com

Many video and audio editing software today can generate captions for you but this only provides a starting point. You will need to edit captions to ensure accuracy as well as add sound effect, music, or other audio descriptions to the captions manually.

info> You may encounter another cross-platform captions format, .srt, and you can easily convert these files to WebVTT using online converters. ## Providing a Text Alternative for Video-only Content

Transcriptions may not be applicable to all videos, such as videos that don't have any audio. For video-only media, it is possible to conform up to WCAG 2 level AAA, as long as the text alternative is materially the same content (WCAG Technique G159).

A text alternative can be content that covers the same concepts shown in the video using prose, such as writing an accompanying blog post outlining all the features for a product announcement video. In fact, the blog post can go into more detail than the video, making it useful for all users. In this case, the video is a product spotlight of a backpack. Since there is no narration, a text alternative is provided as a long description following the video that conveys the same material.

There are several guidelines to follow to prevent accessibility issues with web media beyond providing alternatives.

Avoid Autoplay

In general, it's best not to automatically play media on a webpage unless the entire purpose of the page is to watch a video or play audio (such as a YouTube video page).

This means avoiding the use of the autoplay feature of audio or video elements. There are cases, such as sound effects that react to a user interaction, where it can be permissible or expected to play a sound.

A rule of thumb you can follow is when media is greater than 3 seconds in length, it should be able to be paused or the volume should be controlled by the user separately.

Modern browsers prevent automatic playback from media that have unmuted audio tracks but they will allow programmatic playback as soon as the user interacts with a page.

Try viewing the {{localhost}}/demo/autoplay.html and accepting the cookie policy to see what can happen if you're not careful.

info> If you open demo/autoplay.html in the Web Browser tab within the lab and you've watched Pluralsight content before, the audio will automatically begin playing when the page loads since you've been interacting with the lab, and iframes will inherit the site's media engagement index.

Not only does the media automatically start playing after you click "Accept", it plays BOTH the video and audio embedded on the page.

Even worse, the media is hidden visually from the user, preventing them from turning it off.

This is completely inaccessible and needs to be avoided. Technically, there is nothing preventing you from playing media automatically once the user interacts with your page but it is an easy way to ensure users don't visit your site again.

Ensure Keyboard Accessibility

When testing for accessibility, a best practice is to follow keyboard-first navigation. This means using your keyboard without a mouse to navigate and test your site's accessibility.

For media controls, keyboard navigation must be allowed so users can control playback.

When using the native HTML audio and video elements without a custom player, you should use the controls attribute. Custom players may hide native controls but must provide keyboard-accessible navigation controls instead. On the {{localhost}}/demo/controls.html page, you can press the Play button and pause playback using the native controls since the custom "Play" button doesn't provide a way.

Respect Reduced Motion Preferences

When designing web-based animation in CSS, you should ensure your code respects the prefers-reduced-motion media query to disable animations or reduce movement.

For example, this CSS snippet will disable all animation and motion on the site if this preference is set:

@media (prefers-reduced-motion) {
  /* Disable animations */
  * {
    animation: none !important;
    transition: none !important;
    scroll-behavior: auto !important;
  }
}

This user preference is set at the browser level and may be set for users prone to motion sickness.

Avoid Excessive Flashing

Similarly, when videos or animations flash excessively, this can cause problems for sighted users prone to migraines, headaches, or even epileptic seizures.

Images and media should flash no more than 3 times within one second. If it does, there must be a disclaimer before showing the media that users must accept to proceed.

When you avoid autoplay, providing media controls allows the user to choose their experience. For web animations or effects, respecting reduced motion preference lessens the chance of flashing content.

What Was Covered

This lab focused on two WCAG 2 guidelines:

• 1.1 - Text Alternatives
• 1.2 - Time-Based Media

Within those two guidelines, you learned how to accommodate multiple success criteria up to level AA:

• 1.2.1 Audio-only and Video-only (Prerecorded)
• 1.2.2 Captions (Prerecorded)
• 1.2.3 Audio Description or Media Alternative (Prerecorded)
• 1.2.5 Audio Description (Prerecorded)
• 1.2.8 Media Alternative (Prerecorded)

While it would be hard to cover every possible technique, common techniques to accommodate these success criteria were covered.

What You Learned

There are some of the important takeaways of this lab:

• Recognizing decorative vs. functional images is key to understanding what requires accommodation
• It's best (and simpler) to use CSS for decorative images and accessible img elements for functional images
• Extracting text from images turns them into decorations which lessens the need for accommodation
• Providing long-form equivalent text can satisfy many of the success criteria for both complex images and time-based media
• Complex charts should have accessible HTML data tables
• There are many different ways to hide and label elements to accommodate assistive technology depending on what you want to achieve
• Making web pages more accessible often leads to an overall improved user experience

From here, you can dive deeper into other WCAG 2 guidelines and accessibility topics.