1.1.1 Non-text Content
- Level A
- Perceivable
- Since WCAG 2.0
Summary
Anything conveyed only in pixels is invisible to someone who cannot see the screen. Text alternatives let screen reader users hear what an image shows, let braille display users read it, and keep the meaning available when images fail to load. The criterion is Level A and dates from WCAG 2.0, so it applies to every conformance target you will ever audit.
Grading turns on a three-way distinction, and most disputes come from mixing the categories up. Decorative content (flourishes, spacer graphics, an icon that repeats adjacent text) must be hidden from assistive technology entirely; describing it is itself a defect. Meaningful non-interactive images (product photos, diagrams, infographics) need a text alternative that serves the same purpose as the image. Controls and inputs rendered as images (icon buttons, image links) need a name that describes their purpose, not their appearance: "Search", not "magnifying glass". That last category overlaps SC 4.1.2, and the exceptions for CAPTCHA, tests, sensory experiences, and time-based media only soften the requirement to descriptive identification; nothing interactive or meaningful is exempt outright.
Official wording
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
EN 301 549 mapping
- Web pages
- Clause 9.1.1.1
- Software and native apps
- Clause 11.1.1.1
- Closed functionality (kiosks, terminals)
On closed systems (kiosks, terminals), the requirement becomes built-in speech output for non-text content under clause 5.1.3.6.
Clause 9.1.1.1 applies this criterion to web pages unchanged. Clause 11.1.1.1 applies it to software that supports assistive technologies; where the system is closed to them, clause 5.1.3.6 requires built-in speech output instead.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Every img element needs an alt attribute, with no exceptions: meaningful images get a description that does the image's job, and decorative images get an empty alt="" so screen readers skip them. A missing attribute is worse than an empty one, because most screen readers fall back to announcing the filename or URL. Hearing "IMG underscore 4032 dot JPEG" mid-page is the classic 1.1.1 fail.
Beyond img, check the less obvious carriers. CSS background images are ignored by assistive technology, which is correct for decoration but a failure when the background carries meaning with no text equivalent. Inline SVG needs an explicit name (role="img" plus a title element or aria-label) when meaningful, or aria-hidden="true" when decorative. Icon fonts and emoji used as content need the same treatment.
The fastest way to verify all of this is the accessibility tree in browser developer tools: inspect the element and read its computed name and role. If a meaningful image has no accessible name, or a decorative one still appears in the tree, you have your finding without guessing at the markup.
iOS
Test with VoiceOver running and swipe right through the whole screen, element by element. Every stop should make sense in audio alone. A meaningful image should announce a description set through accessibilityLabel (or the label parameter of Image in SwiftUI). If VoiceOver announces a filename, an asset name, or just "image" with nothing else, that image has no usable alternative and fails.
Decorative images should not be stops at all. In UIKit that means isAccessibilityElement = false; in SwiftUI, use the Image(decorative:) initialiser or .accessibilityHidden(true). If your swipe-through lands on a divider graphic or a background flourish, describing the decoration does not fix it: hiding it does.
Icon-only buttons deserve their own pass. VoiceOver should announce a purpose and a role, for example "Add to basket, button". A control that announces only "button", or the symbol name ("cart dot fill, button"), fails: the user knows something is pressable but not what it does.
Android
Test with TalkBack and swipe through the screen the same way. Meaningful images need a contentDescription (the same-named parameter on Image in Compose). TalkBack's tell-tale failure announcement is "unlabelled, button" on an ImageButton or icon control: reachable but nameless, which fails here and under SC 4.1.2 simultaneously.
Decorative images are silenced by setting contentDescription to null, or android:importantForAccessibility="no" in views. In Compose, pass contentDescription = null for decorative images, or use Modifier.clearAndSetSemantics { } to strip a decorative subtree from the accessibility tree altogether. An empty-string description is worse than null because it still creates a silent, confusing stop.
For controls, grade the announced name against the control's purpose. "Menu", "Delete item", and "Play" pass; "Image", a drawable resource name, or silence all fail. Platform tooling will surface missing labels quickly, but the swipe-through with TalkBack is what tells you whether the name actually describes the purpose.
Pass and fail examples
Passes:
- A product photo with
alt="Blue ceramic teapot, 1.2 litre": the alternative does the image's job for a non-visual user. - A decorative wave divider with
alt=""and no accessible name: assistive technology skips it entirely. - An icon-only search button announced by VoiceOver as "Search, button": the name describes the purpose.
- A bar chart image whose alternative reads "Bar chart of quarterly sales; figures are listed below", with the data available as text on the page: identification plus an equivalent elsewhere.
- A CAPTCHA image labelled "Type the characters shown in the image", offered alongside an audio alternative: identified, described, and available in more than one sensory mode.
Fails:
- A screen reader announces "DSC underscore 0231 dot JPEG": the fallback filename is not a text alternative.
- A meaningful infographic with
alt="infographic": the alternative identifies the format, not the content, so a non-visual user gets none of the information. - A decorative flourish with
alt="decorative swirl graphic": decoration must be hidden, not described; it adds noise to every read-through. - An icon-only delete control that TalkBack announces as "unlabelled, button": reachable but nameless.
- Promotional text baked into a CSS background hero image with no text equivalent: the message simply does not exist for assistive technology.
Not a fail under this criterion:
- A video without captions: time-based media only needs descriptive identification here (a title or label saying what it is); captions and audio description are graded under the 1.2.x media criteria.
- An icon button whose accessible name does not match its visible text label: that mismatch belongs to Label in Name, provided a purposeful name exists at all.
- An ambient background soundscape labelled "Rainfall audio": content intended primarily as a sensory experience only needs descriptive identification, which the label provides.
Commonly confused with
- 4.1.2 Name, Role, Value. The name of an icon-only control sits near both criteria. File by element type: controls whose visual is an image element (an img inside a link or button, or an image input) are 1.1.1 findings via the W3C's documented failure for missing alternatives on those elements; controls drawn with icon fonts, SVG, or CSS that lack a name are 4.1.2 findings. One finding, one criterion; never double-count.
- 2.5.3 Label in Name. 1.1.1 asks whether a name exists and describes the purpose. 2.5.3 asks whether the accessible name of a control contains its visible text label, so speech input users can say what they see. A button named "Submit form data" under a visible label "Send" passes 1.1.1 and fails 2.5.3.
- The 1.2.x media criteria. For video and audio, 1.1.1 only requires descriptive identification of the media itself. Captions, transcripts, and audio description are separate requirements under Guideline 1.2, at their own levels. Do not fail an uncaptioned video under 1.1.1.
- 1.4.5 Images of Text. A screenshot of a paragraph with a faithful alt text passes 1.1.1 yet still fails 1.4.5, because the text should have been real text in the first place. Complex charts sit near the same boundary: a chart is legitimate non-text content, but its alternative must convey the underlying information, not just say "chart".
How AUDITSU tests this
AUDITSU's audit walkthrough covers non-text content on every screen you review, with a screen reader running as you answer. The questions grade the three categories separately: are decorative images hidden from assistive technology, do meaningful images carry an alternative that serves the same purpose, and does every icon-only control announce a name that describes what it does? Each question records a pass, fail, or not applicable result per screen, with evidence attached, so a bare "unlabelled, button" lands in your report tied to the exact screen and control that produced it.
The criterion maps directly into the European standard for web and software audits. On closed systems such as self-service kiosks, where users cannot attach their own assistive technology, the European standard instead mandates built-in speech output, and the walkthrough grades against that.
For the full guided workflow, see the audit platform.