WCAG 1.1.1 Non-text Content: What It Means and How to Make Images Accessible

WCAG 1.1.1 Non-text Content requires that every image, icon, audio, video, applet, canvas or other non-text element has a text alternative that serves the same purpose. This is a Level A success criterion in WCAG 2.0 and it is retained in later WCAG 2.x versions. The goal is simple: if a person cannot perceive the non-text content, they must get the same information or function through text.

What WCAG 1.1.1 actually requires

The requirement is: provide a text alternative that conveys the content or function of the non-text item. The alternative must be available to assistive technologies and to people who cannot see or hear. The text alternative can be short or long. It must match the purpose of the item, not just describe pixels.

What counts as non-text content

• Images used for information, decoration, or navigation
• Icons and pictograms
• Images used as controls (for example image buttons)
• Charts, diagrams and infographics
• Audio, video, and animations
• Canvas, SVG and programmatic graphics
• Embedded objects such as applets or plug-ins
• CAPTCHAs and other media used to test users

How to provide text alternatives (practical methods)

Choose the simplest technique that gives users the same information or control. Common methods are:

• alt attribute on <img> for short alternatives
• aria-label or aria-labelledby for decorative or programmatic elements such as SVG or elements with role=img
• Visible captions or <figcaption> for images that need short context on the page
• Long descriptions provided on the same page or on a linked page for complex graphics
• Transcripts and captions for audio and video

Do not rely only on an image filename or nearby CSS to convey the alternative. The accessible name must be available to assistive technologies through the DOM or ARIA.

Decision framework: pick the right alternative

Use this four-step check before writing alt text.

1. Identify the purpose: is the image informative, decorative, functional or complex?
2. If decorative, use an empty alt attribute alt=“” or hide it from the accessibility tree with aria-hidden=“true” if appropriate.
3. If functional (link or button), the text alternative must describe the function, for example alt=“Search” for a search icon.
4. If informative or complex, provide a concise alt plus a longer description on the page or a linked page. The concise alt should summarise the main point.

Concrete examples and suggested alt text

• Decorative photo: alt=“” (so screen readers skip it)
• Logo that links to the homepage: alt=“Acme Ltd” (company name)
• Button with magnifying glass icon: alt=“Search” or use aria-label=“Search”
• Chart showing quarterly revenue rising: alt=“Quarterly revenue, increasing” plus a linked description with numbers and axis details
• Image containing important text: alt must include the same text shown visually

Complex images: charts, maps and infographics

Complex visuals need two layers of alternative text. First provide a short alt that states the point. Then supply a longer description that gives the data, trends and any labels not obvious from the short alt.

Ways to give the longer description include a nearby visible summary, a linked page that explains the graphic, or an aria-describedby reference to a longer text block on the same page. Avoid relying solely on the deprecated longdesc attribute since support varies.

Controls, input images and image-only links

When an image is a control, the accessible name must describe the control action. For an <input type=“image”> use alt. For clickable SVGs or background-image buttons provide an accessible name via aria-label or aria-labelledby. Test that keyboard users can focus the control and that screen readers announce its name and role.

CSS background images, SVG and canvas

Background images added purely by CSS are not part of the DOM. If they convey important content, do not use a CSS background. Instead place a semantic element with an appropriate alt or visible text. For SVG, include a title element or use role and accessible name with aria-label or aria-labelledby. For canvas, provide equivalent textual content elsewhere or an accessible fallback.

Time-based media and CAPTCHAs

Audio and video need captions, transcripts or audio descriptions when the content is essential. CAPTCHAs often fail accessibility requirements. Prefer accessible alternatives such as device-based verification or accessible challenge methods. WCAG has separate success criteria that cover time-based media and interactive tests — check those when you assess media and CAPTCHAs.

Testing: manual and automated checks

• Automated tools catch missing alt attributes and empty alt where not appropriate. Tools include browser extensions and Lighthouse. Automated tools do not prove quality of descriptive text.
• Manual checks must include keyboard-only navigation and at least one screen reader such as NVDA, VoiceOver or TalkBack. Verify the name announced matches the purpose.
• Use browser devtools to inspect the computed accessible name. Check aria attributes, alt and aria-hidden usage.

Common mistakes

• Leaving alt out entirely rather than using alt=“” for decorative images
• Writing alt text that only repeats the nearby caption or filenames
• Using images of text instead of real text without providing the same text in the alt
• Hiding meaningful images with aria-hidden so assistive tech cannot reach them
• Relying on automated checks alone to verify the quality of alt text

Quick WCAG 1.1.1 checklist

• Every non-text item has an accessible text equivalent.
• Decorative items use alt=“” or are removed from the accessibility tree.
• Functional images provide a name that describes the action.
• Complex images have a short alt and a longer description nearby or linked.
• SVG, canvas and CSS content expose their accessible name via the DOM or ARIA.
• Test with a real screen reader and keyboard users, not only automated tools.

Where to learn more

Read the WCAG success criterion text and the WAI documentation for techniques and examples. Also check guidance on WAI-ARIA for naming and roles when you must use programmatic graphics.