Image descriptions are vital to making digital content fully accessible to people who are blind or have low vision. However, as past research has shown, content authors often leave out these descriptions—also known as "alternative text" or "alt text"—for images on the web and on social media, making AI-based vision-to-language services that automatically generate image descriptions particularly important. To learn more about the design requirements for AI systems to create useful descriptions, our research team conducted interviews with 28 people who are blind or have low vision about the types of details they want when encountering digital images and identified ways in which those wants vary depending on where an image is encountered.
Our findings are presented in the paper "'Person, Shoes, Tree. Is the Person Naked?' What People with Vision Impairments Want in Image Descriptions," which was accepted at the ACM CHI Conference on Human Factors in Computing Systems (CHI 2020). [...]
"Though it is well understood that image descriptions are important to convey the purpose of an image, this research showed us that people who are blind or have low vision want image descriptions that are responsive to where they encounter the image," said Stangl. "In other words, people want different content for the same image depending on where they find it."
For example, if a photo of a person appeared in a news story, people might want a description that includes details about the setting of the image to give a sense of place. But if a photo of a person appeared on a social media or dating website, people might want increased details about that person's appearance, including some details that may be subjective and/or sensitive, such as race, perceived gender, and attractiveness. One participant mentioned that knowing the race and gender of people in photos of board members on an employer/employment website might help them understand whether the company values a diverse workplace. These latter examples illustrate practical and ethical challenges for emerging AI systems, such as whether AI systems can—or should—be trained to provide subjective judgments or information about sensitive demographic attributes.
When browsers and screen readers encounter an element, they use semantic markup and ARIA attributes to tell users what it is (
ulis a list) and how it's supposed to work (
role="menu"). But they can't say why it's there without an accessible name.
Aside from the fact that names are required to achieve the most basic level of accessibility compliance, they provide wayfinding assistance, differentiate similar widgets from each other, and inform users of assistive technology how your interface works.
Elements and components on your page that are interactive or contain meaningful content need identifying text in the markup. Screen readers rely on text to create a usable experience. Voice control users need clear text labels that match the underlying code so they can accurately move about the page.
But this doesn't mean we should slap a name on everything. It requires some restraint. Too many names, or names applied incorrectly, and you could end up with noisy or unusable content.
Which elements need explicitly set names? Essentially, the following:
- focusable, interactive elements - links, forms and form elements, custom-built widgets like accordion, carousel, tabs, etc
- non-text elements that require a text equivalent - images, icons, videos, embedded frames
- labeling elements - headings, form labels
- tables, too, via the
Landmarks that require a name
<nav>, especially when multiple exist on a page
<form>- not just a name, but a visible name
region, which by definition is unspecific so it needs a name to clarify its purpose
<main>- not technically required, but I've included it here because it's good practice to associate the H1 element with the main content in your page via
Landmarks that may be named
Names are not required for accessibility compliance, but may provide additional context.
<section>when you want it to act as a
regionlandmark. Out of the box this element is not considered a landmark unless it's assigned
Landmarks that shouldn't be named
Adding names to these could be distracting to screen readers. Instead, let their roles and content do the work.
<header>when it's a direct child of
<footer>when either is a direct child of
applicationconveys information about the interface but is not exposed to screen reader users for navigation
ARIA labeling attributes illustrate why "no ARIA is better than bad ARIA" — they can override an element's text value. Always test how they sound in a screen reader to ensure they accurately identify the element and match any related text/imagery that is visually displayed (that's the gist of WCAG's success criterion 2.5.3, label in name).
Note: Google Developers' ARIA Labels and Relationships provides a clear and concise breakdown of how labeling attributes relate to each other.
The developer modules guide the creation of courses that:
- introduce key accessibility terms for developers
- demonstrate and explain how accessible coding enables people with disabilities to use the Web
- teach accessible markup and coding techniques for:
- page structure, orientation, and navigation
- custom widgets
- rich applications
These modules focus on accessible markup and coding techniques. They are primarily designed for teaching front-end developers.