Insights Der Joomla , HTML, CSS &Webdesign-Blog

As AI-generated images become more widespread, a new accessibility question arises: how do you label an AI-generated image so that the information is understandable both for sighted people and for screen reader users?

The EU AI Act (Regulation (EU) 2024/1689) sets out transparency obligations in Article 50 for certain AI-generated or manipulated content. For providers of AI systems that generate synthetic image, audio, video, or text content, Article 50(2) requires, among other things, marking in a machine-readable format. For certain content generated or manipulated by deployers — in particular so-called deepfakes — there is also a duty to disclose that the content was artificially generated or manipulated.

Teniel, Angie, and AI-generated

Particularly relevant for accessibility here is Article 50(5): the corresponding information must be provided clearly and distinguishably, and must comply with applicable accessibility requirements. This creates a direct link between AI transparency and digital accessibility.

A label that is visible to sighted people is not automatically accessible to people using a screen reader. Conversely, having alt text doesn't automatically mean it's the right place for every piece of information about an image.

This is exactly where the requirements of the EU AI Act meet the principles of the Web Content Accessibility Guidelines (WCAG):

  • What information does the image convey? Is it informative or decorative?
  • Is it part of a link?
  • And how can the "AI-generated" information be provided in a way that remains understandable without visual perception?


The classic image with alt text

For an informative image, the alt text serves as a text alternative for the image.

<img src="/image.jpg" alt="Man working on a laptop">

A screen reader can read this roughly as: "Man working on a laptop, graphic."

This is the use case for WCAG 1.1.1 – Non-text Content, Level A. Informative non-text content needs an appropriate text alternative.


What happens with a decorative image?

If an image is purely decorative, an empty alt text is normally used:

<img src="/image.jpg" alt="">

An empty alt tells the screen reader: the image itself does not convey any relevant information. The image is normally not announced as a standalone image. For a genuinely decorative image, this is correct and follows the logic of WCAG 1.1.1.


AI labeling

Now assume an image is decorative but still needs to be labeled as AI-generated.

<figure>
  <img src="/image.jpg" alt="">
  <figcaption>AI-generated image</figcaption>
</figure>

For a sighted user, the situation is clear: they see the image and, next to it, the label "AI-generated image." For a screen reader user, the situation is different. Because of the empty alt text, the image is not announced as a standalone image. The user then hears only: "AI-generated image." This raises the question: what does "image" refer to? The user hasn't actually perceived an image.


Why "AI-generated image" alone isn't always enough

The problem isn't that the screen reader reads the text aloud. The real problem is the missing context.

A sighted user sees:

Image → AI-generated image

A screen reader user may hear only:

"AI-generated image."

The visual relationship between the label and the image must therefore also be meaningfully conveyed in the accessible structure.


The image and the label are different pieces of information

An image can contain different kinds of information:

  • Image content: "Man working on a laptop"
  • Link destination: "AI in web design"
  • Provenance: "AI-generated image"

These pieces of information serve different functions and shouldn't automatically be crammed into a single string.

  • The alt text answers the question: What relevant information does the image convey?
  • The link text answers the question: Where does the link lead?
  • The AI label answers the question: How was the image created?


Linked images make things even more interesting

<figure>
  <a href="/article">
    <img src="/image.jpg" alt="Man working on a laptop">
    <span>AI in web design</span>
  </a>
  <figcaption>Image: AI-generated.</figcaption>
</figure>

There are three pieces of information here:

  • "Man working on a laptop" – image description
  • "AI in web design" – link destination
  • "Image: AI-generated." – provenance of the image

This separation makes sense because each piece of information serves a different purpose.


Why alt text isn't just the link destination

For a linked image, it's sometimes assumed that the alt text must always describe the link destination. That's too broad a rule. If the image is the link's only content, its accessible name naturally has to convey the link's purpose:

<a href="/article">
  <img src="/image.jpg" alt="AI in web design">
</a>

The situation is different when the image and text are linked together:

<a href="/article">
  <img src="/image.jpg" alt="Man working on a laptop">
  <span>AI in web design</span>
</a>

Here, there is already visible text that conveys the link's purpose. This is relevant for WCAG 2.4.4 – Link Purpose (In Context), Level A.


But what if the image is informative?

An informative image must not simply be given an empty alt text just because it sits inside a link.

<a href="/article">
  <img
    src="/chart.jpg"
    alt="Share of AI-generated designs rose from 20 to 45 percent">
  <span>AI in web design</span>
</a>

Here, the alt text and the link text serve different purposes: the alt text conveys the information in the chart, while the link text describes the link destination.


The particular difficulty with decorative AI images

Now assume the image really is decorative:

<img src="/image.jpg" alt="">

The image does not exist for the screen reader. Yet relevant information should still be conveyed:

"AI-generated"

This is where the real dilemma arises: the image itself is not announced, but information about its origin should still be accessible. So one shouldn't conclude from "the image is decorative" that all information about the image is therefore irrelevant.


The label should be phrased unambiguously

One possible implementation is:

<figure>
  <img src="/image.jpg" alt="">
  <figcaption>Image: AI-generated.</figcaption>
</figure>

This phrases the information as a self-contained statement. A screen reader can read this roughly as: "Image: AI-generated." This makes the information easier to understand than if "AI-generated image" alone were announced with no further context.


Can small be used for the AI label?

The HTML element small can also be used to label an AI-generated image. The AI label can, for example, appear as supplementary information within a figcaption:

<figure>
  <img src="/image.jpg" alt="Man working on a laptop">
  <figcaption>
    <small>AI-generated image</small>
  </figcaption>
</figure>

Each of these elements has a different role:

  • figure groups the image together with its associated information.
  • figcaption provides the caption, or supplementary information, for the image.
  • small marks the content as supplementary or subordinate information.

It's important to note: small does not mean the information is unimportant for screen reader users, or that it shouldn't be read aloud. The content remains ordinary text and can be perceived by assistive technologies.

The smaller rendering that browsers apply by default to small is only the visual implementation. The semantic meaning of small lies in marking the content as a so-called "side comment," i.e. supplementary or subordinate information.

This structure can also be used with a decorative image:

<figure>
  <img src="/image.jpg" alt="">
  <figcaption>
    <small>AI-generated image</small>
  </figcaption>
</figure>

Here, the image itself remains decorative for the screen reader. The information about the image's origin, however, is provided as its own piece of text. This means the "AI-generated" information doesn't need to be artificially stuffed into the alt text.

This separation is particularly interesting from an accessibility standpoint: the alt text describes the image content where needed, while the caption can hold additional information about the image. The AI label can be marked up within this caption using small as supplementary information.


The label must not exist only technically

When it comes to AI transparency, a distinction must be made between a machine-readable label and a label that is perceivable by people. A technical label can, for example, contain information indicating that content was AI-generated. But that doesn't automatically mean a screen reader user can perceive this information. A visible label such as "AI-generated image" must therefore also be accessible to users of assistive technology where needed.


WCAG 4.1.2 – Name, Role, Value

Another relevant criterion is WCAG 4.1.2 – Name, Role, Value.

This becomes especially important when an image alone is used as a link:

<a href="/article">
  <img src="/image.jpg" alt="">
</a>

In this case, the link may be missing a meaningful accessible name.

The situation is different when meaningful text is used inside the link:

<a href="/article">
  <img src="/image.jpg" alt="">
  <span>AI in web design</span>
</a>


The actual dilemma

This creates two competing requirements:

  • The image is decorative → an empty alt text
  • The "AI-generated" information is relevant → the information must be accessible.

The solution, therefore, is not to write everything into the alt text. Instead, image description, link destination, and AI label should be treated as distinct pieces of information.


What happens with an aria-label on the link?

Another important edge case arises when the entire figure sits inside a link and that link is given an aria-label:

<a href="/article" aria-label="Target AI in Web Design">
  <figure>
    <img src="/image.jpg" alt="Man working on a laptop">
    <figcaption>AI-generated image</figcaption>
  </figure>
</a>

The aria-label determines the link's accessible name. The screen reader therefore bases its announcement of the link on "Target AI in Web Design." The information from the image and the caption does not automatically become part of the link's accessible name as a result.

For a sighted user, on the other hand, several pieces of information are present at once:

  • the image,
  • the image description, or the visual image content,
  • the caption "AI-generated image,"
  • and the link.

For a screen reader user, however, the link is essentially announced as "Target AI in Web Design, link." The "AI-generated image" text does not become part of the link's name simply by appearing as a caption inside the link.

This is an important distinction: an aria-label is not simply additional information. It sets the accessible name of the element and can thereby override the name computed from the existing content. For this reason, an aria-label should not be used if doing so pushes out relevant information that would otherwise be present in the accessible context.


But what about a linked figure?

The situation also gets interesting with a linked figure that has no additional aria-label:

<a href="/article">
  <figure>
    <img src="/image.jpg" alt="Man working on a laptop">
    <figcaption>AI-generated image</figcaption>
  </figure>
</a>

Here too, one shouldn't simply assume that all visible content automatically becomes a meaningful link name. The image alternative, the caption, and the purpose of the link are different pieces of information. So it's worth first considering what information the link itself needs, and what information belongs to the image in addition.

A figure is, first and foremost, a semantic grouping of an image and its associated caption. It doesn't automatically follow that the caption becomes part of the accessible name of a surrounding link.

This distinction matters especially for AI labeling: the "AI-generated image" text can be a standalone piece of information about the image and doesn't necessarily have to become part of the link name.


One possible consequence: visible text instead of a caption

Another possible structure is to output the label as visible text inside the link itself:

<a href="/article" aria-label="Target AI in Web Design">
  <img src="/image.jpg" alt="">
  <span>AI-generated image</span>
</a>

Even here, though, the aria-label problem remains: the explicit label fixes the link's accessible name at "Target AI in Web Design." The text "AI-generated image" does not automatically become part of that link name as a result.

If the label is relevant to screen reader users, one shouldn't simply trust that visible text inside a link with an aria-label will be announced automatically. This example shows why aria-label deserves close scrutiny regarding which information remains available to assistive technologies afterward.


What should you take away from this?

The key question, then, is not only: "Where do I put 'AI-generated'?" but also: "Which element does this information belong to, and how is it made accessible to assistive technologies?"

If "AI-generated image" is relevant information, it shouldn't accidentally be pushed out of the screen-reader-accessible context by an aria-label on a surrounding link.

That argues for using aria-label sparingly, and first checking whether the visible content already provides a sufficient accessible name for the link.


Best-practice example: decorative image

<figure>
  <a href="/article">
    <img
      src="/image.jpg"
      alt="">
    <span>AI in web design</span>
  </a>

  <figcaption>
    Image: AI-generated.
  </figcaption>
</figure>

Here, each element has a clearly separate role:

  • The empty alt text: the image itself is decorative and is not announced as image content by the screen reader.
  • AI in web design: the visible link text describes the link destination.
  • Image: AI-generated.: the relevant information about the image's origin remains available as accessible text.


Best-practice example: informative image

<figure>
  <a href="/article">
    <img
      src="/image.jpg"
      alt="Man working on a laptop">
    <span>AI in web design</span>
  </a>

  <figcaption>
    Image: AI-generated.
  </figcaption>
</figure>

Again, three distinct pieces of information are present:

  • "Man working on a laptop" – image alternative
  • "AI in web design" – link destination
  • "Image: AI-generated." – provenance, or label


Key WCAG criteria at a glance

WCAG criterionMeaning
1.1.1 Non-text Content Informative images need an appropriate text alternative. Decorative images can use an empty alt text.
2.4.4 Link Purpose (In Context) The purpose of a link must be identifiable to the user.
4.1.2 Name, Role, Value Especially relevant when an image alone serves as a link and therefore has to supply the link's accessible name.


Conclusion

Labeling AI-generated images makes it very clear why alt text, link text, and additional image information are not the same thing. Alt text is not a general-purpose container for everything a sighted user perceives from an image and its surrounding context.

Instead, you should ask:

  • What is the function of the image?
  • What is the link destination?
  • What additional information needs to be conveyed about the image?
  • Which of this information must be part of the link's accessible name?
  • Which information should be accessible to screen reader users independently of that?

For an informative image, the alt text can, for example, describe the image content. For a decorative image, the alt text stays empty. That doesn't mean, however, that a relevant label such as "Image: AI-generated." may disappear as well.

Especially with linked images, you also need to watch whether an aria-label on the link pushes existing information out of the accessible name. An aria-label, then, shouldn't be treated as a simple addition — it's a deliberate declaration of the accessible name.

The challenge is to make the AI label understandable without relying on visual perception, while cleanly separating image information from link purpose.

The key best practice, then, is:

Describe the image if it's informative. Make the link destination accessible via the link text. Label the AI origin as its own standalone, understandable, and accessible piece of information. And use aria-label only when the accessible name it sets actually matches the intended link purpose.

I use cookies,
but only technically necessary session cookies
Ok