An Alt Attribute Is Not an Accessibility Strategy: Write Image Alternatives That Match the Context

An automated check finds an image without an alt attribute. You add alt="image", run the check again, and the warning disappears.

The HTML changed. The experience barely improved.

Presence is easy to check. Whether an alternative communicates the right information requires understanding why the image exists on that page.

The same photo can be informative in a product gallery, redundant inside a product link with a clear label, and decorative in a background composition. A useful alternative belongs to the image's use, not just to the image file.

This article is a practical review workflow for developers and content teams. It does not claim that an image scanner can determine accessibility compliance from an attribute count.

1. Missing, empty, and descriptive are different states

Consider three examples:

<img src="bag.jpg">
<img src="bag.jpg" alt="">
<img src="bag.jpg" alt="Forest-green handbag with a gold clasp">

They should not be treated as interchangeable.

An absent attribute leaves the text alternative unspecified. An empty value can intentionally omit a decorative image from the reading experience. A descriptive value can communicate information that matters in context.

For a decorative image, adding descriptive prose can create noise rather than remove a barrier. W3C's decorative-image guidance explains why an empty alternative is appropriate and why leaving the attribute out is a different decision.

An audit that tests only hasAttribute("alt") can identify missing attributes. It cannot infer that every empty value is correct or that every nonempty value is useful.

That limitation should shape the report language: “missing alternative” and “requires contextual review” are more defensible than “all images accessible.”

2. Ask what the reader would lose

Before writing anything, ask:

If this image were unavailable, what information or action would the reader lose?

Suppose a catalog page already says “Forest-green leather handbag” beside a photo. On that page, repeating those exact words may add little. In a detail gallery, another view might reveal the clasp, strap, or internal compartments.

The alternative for that second view could communicate its distinct purpose:

<img
  src="bag-interior.jpg"
  alt="Open handbag showing two compartments and a zipped inner pocket"
>

The wording should match what the image actually shows. Do not infer materials, dimensions, authenticity, or hidden features from a thumbnail.

W3C's informative-image tutorial focuses on conveying the relevant meaning, rather than mechanically describing every visible detail.

My editorial rule is to identify the one reason this image deserves to be on this page. Start there. Add detail only when it helps someone make the same decision that the visual is supporting.

3. Functional images need a destination or action

An image can supply the label for a link or control.

This link has an alternative, but the label is not very helpful:

<a href="/downloads/catalog.pdf">
  <img src="download-icon.png" alt="Downward arrow">
</a>

The important information is what activating it does:

<a href="/downloads/catalog.pdf">
  <img src="download-icon.png" alt="Download the product catalog PDF">
</a>

If the link already contains visible text, the icon can instead have an empty alternative:

<a href="/downloads/catalog.pdf">
  <img src="download-icon.png" alt="">
  Download the product catalog PDF
</a>

These are simple cases, not a complete treatment of accessible-name computation. Inspect the rendered control when labels are assembled through nested elements or ARIA attributes.

The W3C functional-image guidance is a good reference for deciding when the alternative should describe the action instead of the appearance.

For image-only controls, include an explicit label requirement in component review. Do not let an unlabeled control pass merely because its icon is attractive.

4. Do not force an entire chart into one sentence

A chart can contain a conclusion and the evidence behind it. A brief alternative may communicate the chart's identity or key message, but it often cannot carry every data point.

For example, a chart comparing monthly image bytes should have a nearby textual explanation and, where useful, a data table. The visual should not be the only place the numbers exist.

An illustrative structure is:

<figure>
  <img
    src="monthly-image-bytes.png"
    alt="Monthly image transfer totals; explanation and data table follow"
  >
  <figcaption>
    Image-transfer totals for the sampled pages, January to March.
  </figcaption>
</figure>

<p>The totals declined each month for this sample.</p>
<!-- Include the actual accessible data table here. -->

The table must contain the real data and clear headings. The comment above is only a placement marker, not a substitute for it.

W3C's complex-image guidance covers alternatives that provide both a short identification and more complete information.

For engineering teams, this becomes a publishing contract: whoever exports the chart also delivers its underlying data or a meaningful narrative. A designer should not have to reconstruct the numbers from pixels.

5. Build context into the asset workflow

A filename such as IMG_1042.jpg is a poor starting label. So is automatically turning a slug into a sentence.

My suggested content record contains separate fields:

A single reusable “default alt” can be a helpful draft. It should not prevent a different value at a different placement.

For product galleries, use placement records to distinguish a front view, back view, detail, and interior view. Do not invent different wording merely to make strings unique. The distinction should reflect information the images actually contribute.

This is a proposed content model, not a claim about BatchSet's current storage schema.

6. Treat generated descriptions as drafts

An image-description model may identify a bag and a clasp. It does not necessarily know that the image is functioning as a download button, that adjacent text already explains it, or that the page is teaching users how to identify a manufacturing defect.

The strongest review prompt starts with the intended use, not just the pixels:

Placement: Product detail gallery
Purpose: Show how the inner compartments are arranged
Already stated nearby: Product name and exterior color
Required review: Confirm visible details; do not infer measurements

That record helps a human reviewer as much as it helps a model.

For a small team, I would prioritize consequential images first: controls, diagrams that explain a process, product details needed to compare choices, and screenshots that contain essential instructions.

Then review repetitive decoration and redundant card images. The goal is understandable content, not the longest possible description for every asset.

7. Give automated checks a narrow, honest job

In a browser console, a small inventory can collect candidates:

const imageInventory = [...document.querySelectorAll("img")].map(img => ({
  source: img.currentSrc || img.src,
  hasAlt: img.hasAttribute("alt"),
  alt: img.getAttribute("alt"),
  inLinkOrButton: Boolean(img.closest("a, button")),
}));

console.table(imageInventory);

This code does not compute accessible names, examine CSS backgrounds, inspect every shadow root, or understand the image's purpose. It creates a review list from the current document.

I would use three queues:

• Missing attributes to investigate.
• Empty attributes to confirm against the intended role.
• Existing descriptions to check for usefulness and accuracy.

Do not automatically classify the second and third queues as failures. They contain context-dependent decisions.

When a scan cannot inspect the required markup, mark the check unavailable. That is a measurement limitation, not evidence that the page passed.

8. Review the experience, not only the markup

A practical acceptance pass should include:

1. Inspecting labels on image links and buttons.
2. Reading product-card content in its actual order.
3. Checking whether charts still make sense without seeing them.
4. Verifying that decorative elements do not create repetitive announcements.
5. Testing important flows with a screen reader and keyboard.

Images are only one part of accessibility. Focus order, interaction behavior, form labels, structure, and many other details still matter.

A successful image review does not certify the whole site. It improves one specific part of the experience with evidence you can explain.

Start with discovery, then add judgment

If you need a starting inventory, BatchSet's Website Image Auditor can flag missing alt attributes among the images it analyzes when the necessary markup is available.

It is an image-focused audit, not an accessibility certification. Unmeasurable images and fallback scans have coverage limitations, so review the report's analyzed set and availability indicators.

Use the findings to locate work. Use the page's purpose to decide what the alternative should say.