Image accessibility

Definition and scope

Image accessibility focuses on making the meaning, function, and context of images available through programmatic names and descriptions so that assistive technologies can present equivalent information. It spans the full range of image use on the web: editorial photos, charts and diagrams, icons and logos, product imagery, maps, and UI graphics, across raster formats (JPEG, PNG, WebP, AVIF) and vector formats (SVG).

The axis of concern is not only blindness or low vision. People benefit when images have the right text alternative if they experience cognitive load, motion sensitivity, temporary impairments, language differences, or blocked images due to bandwidth, privacy tools, or corporate proxies. Clear semantics also support search indexing and machine interpretation, making images discoverable and meaningful in non-visual contexts.

Scope

In practice, scope includes how images are authored, how CMS workflows enforce text alternatives, and how front-end code conveys roles and relationships. It considers decorative graphics (which should be ignored by assistive tech), functional images that act as controls or links, informative images that complement surrounding copy, and complex graphics that require structured summaries or data equivalents.

Scope also extends across responsive image patterns and delivery strategies. The alternative text for an <img> applies regardless of which source is chosen via <picture> or srcset, so it must fit all art-directed variants. Lazy-loading and placeholder techniques must avoid announcing meaningless placeholders while ensuring the final image remains correctly named in the accessibility tree when it appears.

Overview

Browsers expose images to assistive technologies via the accessibility tree using the HTML semantics of <img>, <svg>, and related elements. The accessible name is most often taken from the alt attribute for <img>, or from aria-label/aria-labelledby for other elements. An empty alt (alt="") intentionally hides decorative images from screen readers; omitting alt entirely often results in an unhelpful announcement such as “image” or a file name, which is a failure for informative or functional images.

<figure> and <figcaption> can establish a semantic relationship between an image and its visible caption. Captions complement, but do not replace, the image’s accessible name. For complex graphics, authors typically provide a concise alt for identity and state, and reference a longer description in nearby text or a linked data table. Background images applied via CSS are ignored by assistive technologies by default; if the content is meaningful, it should not be a CSS background.

Core web standards governing image accessibility

WCAG success criteria

WCAG 2.x sets the normative bar: 1.1.1 Non-text Content requires text alternatives for non-decorative images; 1.4.5 Images of Text discourages images used to display text; and 1.3.1 Info and Relationships, 1.4.11 Non-text Contrast (for icons in controls), and 2.4.x navigability criteria often apply. Complex images intersect with 1.3.1 and 1.4.x because information encoded in visuals must also be available structurally or textually.

HTML, ARIA, and SVG

The HTML Living Standard defines <img> semantics and the alt attribute. ARIA provides aria-label, aria-labelledby, and aria-describedby for accessible names and descriptions when native semantics are insufficient; it also includes presentational roles (role="presentation" or aria-hidden="true") to hide purely decorative images. SVG supports <title> and <desc> for labelling, usually referenced via aria-labelledby for reliable cross-AT support. ARIA should not override correct HTML; prefer native semantics first.

User agent and AT behaviour

Accessibility APIs on each platform (AX, UIA, ATK/AT-SPI) consume the DOM and ARIA to present images to screen readers. The accessible name computation governs precedence (e.g., aria-labelledby over aria-label over alt in some contexts for non-<img> elements). Support nuances exist across NVDA, JAWS, VoiceOver, and TalkBack, particularly for inline SVG and role handling, so cross-device testing is advised for critical UI imagery.

Testing and validation

Automated checks

Automated tooling catches common failures quickly. Popular options include axe DevTools/axe-core, Lighthouse Accessibility, WAVE, and Pa11y, which flag missing or suspicious alt attributes, images of text, and contrast issues for iconography. CI integration helps prevent regressions when content editors upload new assets or when templates change image roles and labels.

Manual and assistive tech testing

Human verification is essential. Navigate with a screen reader (NVDA/JAWS on Windows, VoiceOver on macOS/iOS, TalkBack on Android) to confirm that images have appropriate names, that decorative images are skipped, and that linked images make sense out of context. Keyboard-only navigation should reveal focusable images and buttons with clear labels, and captions must be discoverable in reading order.

Review content against editorial guidelines: does the alt convey the same purpose or outcome as the image without redundant phrasing like “image of”? For complex visuals, ensure there is a proximate long description or data alternative. Where localisation applies, validate that alt text language matches the page or has appropriate lang annotations for mixed-language content.

Common pitfalls and edge cases

Several recurring issues undermine image accessibility. Linked images without alt fail both usability and WCAG 1.1.1 because the link has no accessible name. Decorative flourish images often include non-empty alt and become noise. CSS background images are used to present meaningful content but remain invisible to assistive technologies. Icon fonts can render as empty squares or be misread; SVG or <img> with proper names is more robust.

Other edge cases include images of text (which scale poorly and are not selectable or translatable), charts and infographics that lack data equivalents, CAPTCHA images without alternative modalities, and avatars or logos used as links without conveying destination. Lazy-loading placeholders may be announced if given alt text; placeholders should be hidden from AT, while the final image retains the correct alt. For art-directed responsive images, alt should describe the subject or purpose common to all variants.

• Decorative imagery: use alt="" or aria-hidden="true"; never omit alt on <img>.
• Functional images: alt should state the action or destination (e.g., “Search”, “Download PDF”).
• Complex graphics: provide a succinct alt and a nearby long description or data table.
• Inline SVG: prefer aria-labelledby referencing <title>/<desc> for consistent labelling.

Practical impact

Well-implemented image accessibility improves task completion, reduces cognitive load, and lowers support friction for users who cannot perceive or load images. It supports legal compliance in many jurisdictions and boosts accessibility scores in audits and procurement. From an SEO perspective, descriptive alt text and relevant captions provide strong signals for image indexing and clarify on-page context, which can enhance click-through from image search results and augment topical relevance alongside surrounding copy.

There is negligible performance cost to alternative text, and accessible patterns often align with performance best practice: using SVG for crisp UI icons, avoiding images of text, and eliminating redundant decorative assets. Cleaner semantics can also reduce DOM noise and prevent unnecessary reflows from visually hidden, screen-reader-visible hacks. Overall, accessible images strengthen UX and discoverability without trade-offs in load time when combined with standard optimisation techniques.

FAQs

How long should alt text be?

Aim for concise, purpose-driven phrasing—often a short clause or one sentence (roughly 5–15 words) for informative images. Convey what the image adds that is not already obvious from surrounding text. For complex graphics, provide a succinct alt for identification and state, and offer an extended description or a data table nearby rather than trying to encode everything in the alt.

When should alt be empty (alt="")?

Use an empty alt when an image is purely decorative or redundant with nearby text, and the information loss is zero if it is skipped by assistive technologies. Examples include ornamental separators, background textures promoted into <img> for performance, or a duplicated logo when the organisation name is already adjacent in text. Do not omit the alt attribute entirely on <img>; an explicit empty alt is the correct signal.

Should keywords be included in alt text for SEO?

Only if they are natural to an honest description. Alt text is for equivalence, not for stuffing. Describe the image’s purpose in context, and relevant terms will naturally appear. Over-optimised alt text can harm accessibility by adding noise and may be treated as low-quality by search engines. Captions and nearby body copy are better places for additional context.

Are SVGs accessible by default?

Inline SVGs have no automatic accessible name. Provide one using aria-label or, preferably, aria-labelledby that references a <title> (and optionally <desc>) inside the SVG. For purely decorative SVGs, hide them with aria-hidden="true" or presentational roles. When SVGs are used as <img src>, the alt attribute on <img> supplies the accessible name, and the internal <title> is not exposed.

What about CSS background images used for content?

Assistive technologies ignore CSS backgrounds, so any image that conveys meaning or acts as a control should be marked up as HTML content (e.g., <img> or inline SVG) with an appropriate accessible name. Reserve CSS backgrounds for decoration only. If a background image must remain for technical reasons, include equivalent text in the DOM for the same control or section, then hide the decorative background from AT.