Important Audio Description Tips:
Techniques to Make Visuals Heard
People may only hear your meeting and video’s visuals
By Jennie Delisi, Accessibility Analyst
Imagine you are participating in a meeting. Half of the participants are together in a room. You are one of the online participants. The camera shows the speaker and the presentation slides. Suddenly, everyone in the room laughs, but nothing funny is onscreen. You reread the slide, but don’t get the joke. What happened?
We often communicate with a blend of audio and visual information. But there are times when only one of these communication channels are available. When communicating visual information we can take steps to ensure all of our audience receives the important information, even if they cannot see or understand the visual content. For videos this includes:
- Important graphics.
- Onscreen text.
- Visuals that advance the plot.
- Visual jokes.
People Who Use Audio Description
Many people use audio description. This includes:
- People who are blind or have vision limitations (also known as “low vision”).
- People who are deafblind.
- Some people with cognitive disabilities find information about what is onscreen helpful to support understanding. They may not know which visuals onscreen are important, or what some of them mean.
This month we explore (for both videos and meetings):
- Types of audio description.
- Benefits of each approach.
- Planning needed for each type.
Best of all? Engaging examples! Check them out in Important Audio Description Tips: Techniques to Make Visuals Heard.
Buying Accessible IT: Who is Responsible?
A brief introduction to how Minnesota builds accessibility into the buying process
By Jay Wyant, Chief Information Accessibility Officer
In 2009, the State of Minnesota convened a task force to write and implement a digital accessibility standard as directed by law (16E.03, subd. 9). In addition to publishing and updating the standard (PDF), the task force spent a great deal of time working out a decision matrix for state employees to use when buying digital content and technology. That’s because, like many governments, the state buys much more of its technology than it builds.
The digital accessibility standard applies to all digital systems, websites, applications, and content. It references both:
The state is obligated to follow the standard. Since it buys much of its technology and digital services from the private sector, we often hear the question: who is responsible for accessibility? The state or the vendor selling to the state? This article will help answer that question.
The short answer is both: it's the state’s responsibility to set expectations, and the vendors’ responsibility to meet them.
And, Wyant discusses, "if we order a pair of slacks online and it turns out to be the wrong size or a flawed product, we can return it and get our money back. Why can’t we do the same for digital technology?"
He shares his answer, and how the state of Minnesota reviews the accessibility of potential purchases, in: Buying Accessible IT: Who is Responsible?
Tech Tip: Code snippets, language, and WCAG 2.x
Sometimes you want an example of something that works as expected. You want an example of code that passes the Web Content Accessibility Guidelines (WCAG) for a specific success criteria. The ACT Rules can help. They “describe how to test conformance of accessibility standards such as WCAG and WAI-ARIA (from About ACT Rules). The authors and reviewers are members of the W3C Accessibility Guidelines Working Group – the people that write WCAG.
The ACT Rules can also help people who want to:
- Write accessible HTML code.
- Manually validate code.
- Reference a sample that follows a particular success criteria’s requirements.
Here’s an example:
WCAG 3.1.2 Language of Parts is important when sections of a webpage are in different languages. An example is a webpage with English as the primary language. Within the page may be information in other languages, about availability of documents and webpages translated into that language. The Understanding Document for 3.1.2 shares how the language code associated with the specific section of text improves accessibility:
“This makes it possible for user agents and assistive technologies to present content according to the presentation and pronunciation rules for that language.”
The ACT rule: Element with lang attribute has valid language tag shares the specifics related to a test you can use as part of validating 3.1.2. The Test Cases section has examples that pass, and some that fail. The failing examples include an explanation of why they fail. And, if you want to know why some subtags are passing even when they are invalid, this section is for you!
Explore the ACT rules as part of your 15 minutes a week accessibility improvement time! Learn more in How to Make Short Weekly Learning Time = Digital Accessibility Wins.
|
