Skip to content

Accessibility: appropriate alt text, naming elements, etc.

  • 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 (ul is 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 caption element
  • Landmarks that require a name

    • navigation or <nav>, especially when multiple exist on a page
    • form or <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 or <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 aria-labelledby
  • Landmarks that may be named

    Names are not required for accessibility compliance, but may provide additional context.

    • complementary or <aside>
    • search
    • <section> when you want it to act as a region landmark. Out of the box this element is not considered a landmark unless it's assigned aria-label, aria-labelledby, or title.
  • 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.

    • banner, or <header> when it's a direct child of <body> (has implied banner role)
    • contentinfo or <footer> when either is a direct child of <body>
    • application conveys 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
      • menus
      • images
      • tables
      • forms
      • custom widgets
      • rich applications

    These modules focus on accessible markup and coding techniques. They are primarily designed for teaching front-end developers.