What 1.1.1 requires
All non-text content shown to users needs a text alternative that serves the same purpose. What the alternative says depends on what the element is for: a photo in an article needs a description of what matters about it, an icon button needs the name of its action, and a chart needs its key finding somewhere in text. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 1.1.1 (opens in a new tab) [1][2].
Exceptions and scope:
- Controls and inputs: the text alternative is the control's name, describing its purpose (in practice, 4.1.2 applies too).
- Time-based media, tests, and sensory experiences: at least a descriptive identification is required.
- CAPTCHA: describe its purpose and offer an alternative form for other senses.
- Decoration, formatting, invisible content: implement it so assistive technology can ignore it (for example
alt="").
Why it matters
A screen reader can't see an image. It reads whatever the code provides: the alt text, an ARIA label, or, if nothing is there, often the file name or nothing at all. An icon-only "cart" button with no name is announced as just "button", and the person has to guess. Missing alternative text for images was detected on 53.1% of the top million home pages in WebAIM's 2026 analysis [4].
Common failures
Image with no alt attribute
Many screen readers fall back to the file name.
<!-- Fails -->
<img src="IMG_4471.jpg">
<!-- Better -->
<img src="IMG_4471.jpg" alt="Navy wool coat, front view">Icon button with no accessible name
The SVG has no title, and the button has no text or label.
<!-- Fails -->
<button><svg>…</svg></button>
<!-- Better -->
<button aria-label="Open cart"><svg aria-hidden="true">…</svg></button>Decorative image announced as content
A divider or background flourish with alt text adds noise to every visit.
<!-- Fails -->
<img src="swoosh.png" alt="swoosh">
<!-- Better -->
<img src="swoosh.png" alt="">Alt text that duplicates nearby text
A product card whose image alt repeats the product name heading means the name is heard twice.
<!-- Fails -->
<img alt="Navy wool coat"> <h3>Navy wool coat</h3>
<!-- Better -->
<img alt=""> <h3>Navy wool coat</h3> (when the image adds nothing beyond the name)Can automated testing check 1.1.1?
Partly. Automation can find a missing alternative. It can't tell whether an alternative is right.
| axe-core 4.13.0 rule | What it checks |
|---|---|
image-alt | <img> elements have alternative text or a role of none/presentation |
input-image-alt | <input type="image"> has alternative text |
object-alt | <object> elements have alternative text |
role-img-alt | elements with role="img" have alternative text |
svg-img-alt | SVGs with an img role have a text alternative |
aria-meter-name, aria-progressbar-name | meters and progress bars have accessible names |
What automation can't decide: Whether alt="photo" describes anything; whether an image marked decorative actually carries information; whether a chart's key finding is available in text. (axe-core's image-redundant-alt best-practice rule flags alt text repeated in adjacent text, but it isn't mapped to 1.1.1.)
A clean automated result is never proof that 1.1.1 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- List every image, icon, SVG and canvas on the page (a browser extension or the accessibility tree helps).
- For each one, ask: what is it for here? Informative, functional (inside a link or button), or decorative?
- Read the alternative out of context. Would someone who can't see the image get the same information or know what the control does?
- Check that decorative images are actually hidden (
alt="",aria-hidden="true"or CSS background). - Run a screen reader over the page (see our screen-reader testing guide) and listen for file names, "image", "graphic" or "button" with no name.
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Scanning runs the axe-core rules above on every URL on a paid plan, so missing alternatives are found sitewide, not just on the pages someone remembered to check. In a journey, the report records what was announced at each step, so an icon-only control the task depends on, such as an unnamed "add to cart" or "next" button, shows up at the step where it blocked the task. The free page check and the assistant tools (screen reader transcript) list what each element announces on one page.
Where it stops: Whether an alternative is meaningful is a human judgment. Accessible can show you what is announced, but deciding if it's the right description is up to you. No automated tool, ours included, can certify that a criterion is met.
Related criteria
- 1.3.1 Info and Relationships
- 2.4.4 Link Purpose (In Context)
- 4.1.2 Name, Role, Value
- WCAG 2.2 success criteria checklist
Sources
- Understanding Success Criterion 1.1.1: Non-text Content (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.1.1 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
- The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages (opens in a new tab). WebAIM, 2026. WAVE-detected errors on home pages only. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.