WCAG 1.1.1: Non-text Content

What This Rule Means

WCAG Success Criterion 1.1.1 Non-text Content is a Level A requirement under the Perceivable principle. It states that all non-text content presented to the user must have a text alternative that serves the equivalent purpose. "Non-text content" is defined broadly: it encompasses raster images (JPEG, PNG, GIF, WebP), vector graphics (SVG), image-based buttons and form inputs, image maps, canvas elements, audio clips, video, animations, CAPTCHAs, and decorative flourishes.

A text alternative can take several forms depending on the element type: an alt attribute on an <img> element, an aria-label or aria-labelledby on an SVG or role-bearing element, a title element inside an <object>, or a <figcaption> associated with a figure. The key requirement is that the alternative text communicates the same information or function as the visual content itself — it is not simply a file name or a generic placeholder.

The criterion defines several specific cases that determine what an adequate text alternative looks like:

• Controls and inputs: If the non-text content is a control or accepts user input (such as an image button or an image used as a link), the text alternative must describe its purpose or function, not just its appearance.
• Time-based media: Audio-only or video-only content used as a standalone presentation requires at minimum a descriptive label identifying it; full transcripts and captions are addressed by later criteria (1.2.x).
• Tests and sensory experiences: If the content is a test or exercise that cannot be presented in text without defeating its purpose (such as a visual puzzle), the text alternative need only identify and describe the non-text content.
• CAPTCHAs: Text alternatives must describe the purpose of the CAPTCHA, and an alternative form of CAPTCHA using a different sensory modality must be provided.
• Decoration, formatting, and invisible content: If an image is purely decorative, used for spacing, or is not presented to users, it should be implemented so that it can be ignored by assistive technology — typically via an empty alt="" attribute or role="presentation".

A pass is achieved when every meaningful non-text element either exposes a programmatic text alternative that equivalently conveys its purpose, or is explicitly marked as decorative so that assistive technologies can skip it. A fail occurs when an image has no alt attribute at all, when the alt value is the filename (e.g., alt="img_header_logo_v2.png"), when an SVG used as meaningful content has neither a <title> element nor an accessible label, or when a decorative image incorrectly has descriptive alt text that adds noise for screen reader users.

Why It Matters

According to the World Health Organization, approximately 2.2 billion people worldwide have some form of vision impairment or blindness. Screen reader users — who rely on synthesized speech or refreshable Braille displays to consume digital content — depend entirely on text alternatives to understand images, icons, charts, and graphical controls. Without accurate alt text, a product page on an e-commerce site is reduced to a list of prices with no visual context; a bank's logo-laden navigation becomes a row of unlabeled buttons; a hospital's symptom-checker diagram is invisible to the user trying to self-triage.

Consider a concrete scenario: a user who is blind visits a Turkish e-commerce platform to purchase a jacket. The product carousel contains six images showing different angles and color variants of the jacket. If none of those images have meaningful alt text, the user's screen reader announces only "image, image, image" — six times. They cannot determine which variant is navy blue versus black, cannot understand which image shows the rear pocket, and may abandon the purchase entirely. A sighted colleague with the same product link completes the purchase in under two minutes. This gap is both an accessibility failure and a business loss.

Beyond blindness, this criterion also benefits users with cognitive disabilities who rely on text-to-speech tools to supplement reading, users with motor impairments who navigate by keyboard and voice and need clear labels on interactive controls, and low-bandwidth users for whom images may not load — in those cases, the alt text serves as a functional fallback. Additionally, well-crafted alt text improves search engine indexing because crawlers treat image alt attributes as relevant textual signals, directly supporting SEO outcomes.

Related Axe-core Rules

The axe-core accessibility engine enforces WCAG 1.1.1 through seven distinct automated rules. Understanding what each rule checks — and where its limits lie — is essential for a complete testing strategy.

• image-alt: Checks that every <img> element has an alt attribute (which may be empty for decorative images) or an accessible name provided via aria-label, aria-labelledby, or title. It flags images that have no alt attribute whatsoever, since the browser then exposes the file path as the accessible name.
• input-image-alt: Checks that <input type="image"> elements have a non-empty alt attribute. Image inputs act as submit buttons and must convey their function, not just their visual appearance. A missing or empty alt on an image input renders the button effectively unusable with a screen reader.
• area-alt: Checks that every <area> element within an image map has a non-empty text alternative via alt, aria-label, or aria-labelledby. Image maps are a legacy pattern still used in some enterprise applications and public-sector portals, and each hotspot must independently describe its link destination or function.
• object-alt: Checks that <object> elements have an accessible name. The <object> element is historically used to embed Flash content, PDFs, or other media; without a label, screen readers have no way to identify the embedded content.
• svg-img-alt: Checks that inline <svg> elements with role="img" have an accessible name, typically provided by a child <title> element (with a matching aria-labelledby) or an aria-label attribute on the SVG root. Modern UIs use SVG extensively for icons and illustrations; this rule catches unlabeled SVGs that carry meaning.
• role-img-alt: Checks that any element with role="img" — which can be applied to non-SVG elements such as <div> or <span> used as image containers — has an accessible name. This pattern is common in custom icon systems and CSS-background-image implementations where no native image element is used.
• image-redundant-alt: Flags situations where an image's alt text duplicates adjacent visible text, typically when an image appears inside an anchor alongside a text label. While not a hard failure, redundant alt text causes screen readers to announce the same information twice, degrading the listening experience. This rule requires human judgment to resolve correctly because only a person can determine whether the duplication is genuinely redundant or intentionally additive.

It is important to note that automated tools including axe-core cannot evaluate the quality of alt text — only its presence and basic structure. A rule may pass for an image with alt="photo" or alt="decorative border" even though neither is meaningful. Manual review is therefore always required alongside automated scanning to confirm that alt text accurately describes the content and purpose of each image.

How to Test

1. Automated scan with axe DevTools or Lighthouse: Install the axe DevTools browser extension (available for Chrome and Firefox). Open the page under test, activate the extension, and run a full-page analysis. Filter results by the rule IDs listed above: image-alt, input-image-alt, area-alt, object-alt, svg-img-alt, role-img-alt, and image-redundant-alt. For each flagged element, the tool highlights the offending node in the DOM and explains the violation. Lighthouse (built into Chrome DevTools under the Accessibility audit) also surfaces image-alt violations with element-level detail. Record all violations with their element selectors and surrounding context for developer handoff.
2. Manual DOM inspection: Open the browser DevTools Elements panel and search for all <img>, <input type="image">, <area>, <object>, and <svg> tags. For each, verify that an appropriate alt attribute or ARIA label is present and that its value is meaningful in context. Pay particular attention to images loaded dynamically via JavaScript frameworks such as React or Vue, which may not appear in a static HTML snapshot.
3. Screen reader testing with NVDA and Firefox: Launch NVDA (free, Windows) and open the page in Firefox. Navigate using the G key to jump between graphics. NVDA announces each image's accessible name; listen for announcements of file paths, "image", or empty announcements — all of which indicate a failure. For image buttons and links, use the Tab key to reach each control and verify that the spoken label conveys the action the control performs.
4. Screen reader testing with VoiceOver and Safari (macOS/iOS): Enable VoiceOver (Command+F5 on macOS). Use VO+Right Arrow to move through content element by element, or open the Item Chooser (VO+U) and select Images from the rotor to see a list of all images and their labels at once. On iOS, swipe right through the page and listen for how each image is announced.
5. Screen reader testing with JAWS and Chrome: In JAWS, press G to navigate by graphic. Each image should produce a clear, meaningful description. Use the JAWS virtual viewer (Insert+F1) to see the computed accessible name and role for any element in question.
6. Verify decorative image treatment: For images you believe are decorative, confirm they have alt="" and no title attribute or ARIA label that would re-expose them. With a screen reader, navigate to those elements and confirm they are skipped entirely in the reading order.

How to Fix

Informative image with missing alt — Incorrect

<!-- Image conveys product information but has no alt attribute -->
<img src='jacket-navy-front.jpg'>

Informative image with missing alt — Correct

<!-- alt text describes the visual content and its purpose in context -->
<img src='jacket-navy-front.jpg' alt='Navy blue wool jacket, front view, with double-breasted buttons'>

Decorative image incorrectly labeled — Incorrect

<!-- Decorative divider image exposes a descriptive alt that adds noise -->
<img src='divider-ornament.png' alt='Decorative ornamental divider with scrollwork pattern'>

Decorative image correctly hidden from assistive technology — Correct

<!-- Empty alt tells screen readers to skip this image entirely -->
<img src='divider-ornament.png' alt=''>

SVG icon without accessible name — Incorrect

<!-- SVG used as a meaningful icon has role="img" but no label -->
<svg role='img' xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'>
  <path d='M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2z'/>
</svg>

SVG icon with accessible name — Correct

<!-- title element provides the accessible name; aria-labelledby associates it -->
<svg role='img' aria-labelledby='icon-account-title' xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'>
  <title id='icon-account-title'>My Account</title>
  <path d='M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2z'/>
</svg>

Image input button with missing alt — Incorrect

<!-- Image submit button has no alt; screen reader announces only "image" -->
<input type='image' src='btn-search.png'>

Image input button with descriptive alt — Correct

<!-- alt describes the button's function, not its appearance -->
<input type='image' src='btn-search.png' alt='Search'>

Common Mistakes

• Using the filename as alt text: Writing alt="hero_banner_v3_final.jpg" exposes the file path to screen readers with no meaningful content. Always write alt text that describes what the image shows or what purpose it serves.
• Setting alt text to "image" or "photo": Generic values such as alt="image" or alt="photo" pass automated checks because they are non-empty, but they convey no information. Screen readers already announce the element role as "image", so repeating that word wastes the user's time.
• Forgetting alt on dynamically injected images: Images inserted into the DOM via JavaScript (e.g., a product carousel built with React) may lack alt attributes in the initial HTML. Ensure that the JavaScript component renders the alt attribute at the same time it renders the src.
• Applying role="presentation" to meaningful images: Using role="presentation" or role="none" on images that carry content removes them from the accessibility tree entirely. This is appropriate only for purely decorative images; using it on informative images causes a complete content loss for screen reader users.
• Omitting the alt attribute entirely on CSS background images using role="img": When a <div> is styled with a background image and given role="img", developers sometimes forget to add aria-label. Without a label, the element is in the accessibility tree as an image with no name — equally as bad as a missing alt.
• Writing alt text that describes appearance rather than meaning: For a chart, writing alt="A blue bar chart" describes the visual style but not the data. The alt text should convey the key insight, such as alt="Bar chart showing Q3 revenue grew 18% year-over-year".
• Duplicate alt text across multiple images in a set: When a product listing shows six thumbnail images of the same item, assigning all of them the same alt text (e.g., alt="Running shoe") fails to distinguish between them. Each image in a set should describe its unique content or angle.
• Missing alt on <area> elements in image maps: Developers who use image maps often add alt text to the parent <img> but forget that each <area> hotspot also requires its own alt attribute describing that specific link destination.
• Using tooltip text as a substitute for alt text: The title attribute produces a visual tooltip and is read by some screen readers, but browser support is inconsistent and it is not exposed in all accessibility contexts. It should supplement, not replace, a proper alt attribute.
• Failing to test SVG icons delivered via sprite sheets or <use> elements: SVG sprites referenced via <use href="#icon-id"> may not expose their internal <title> to all screen readers due to shadow DOM boundaries. Always test sprite-based icons with real screen readers and supplement with aria-label on the outer <svg> element when necessary.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory digital accessibility requirements for a broad range of public and private entities operating in Turkey. The circular references WCAG 2.2 as its technical standard, making all Level A success criteria — including WCAG 1.1.1 Non-text Content — legally enforceable obligations rather than best-practice recommendations.

The covered entities include: all public institutions and government bodies, banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, e-commerce platforms, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE). For public institutions, compliance must be achieved within one year of the circular's effective date. Private sector entities are given a two-year implementation window.

WCAG 1.1.1 is particularly relevant in the Turkish digital landscape because many high-traffic sectors covered by the circular — including e-commerce marketplaces, banking portals, and government service platforms — are heavily image-dependent. Product photographs on e-commerce sites, infographic-based public announcements on government portals, chart-heavy financial dashboards in banking applications, and form-based interfaces in hospital patient portals all fall squarely within the scope of this criterion.

Non-compliance with Level A requirements under the circular exposes covered entities to regulatory scrutiny and potential sanctions. Because WCAG 1.1.1 is one of the most frequently violated and most easily tested criteria — detectable through both automated tooling and basic screen reader walkthroughs — it is likely to feature prominently in compliance audits. Organizations subject to the circular should treat the remediation of all image-alt violations as an immediate, high-priority action item, not a deferred enhancement. Deploying an accessibility overlay SDK such as Accsible can assist in surfacing and partially remediating missing text alternatives in real time, but a full remediation at the source code level remains the most robust and durable path to compliance.