Object element has no text alternative

What is this issue?

An <object> element, typically used to embed a PDF or other browser-renderable resource via its data attribute, has no accessible name and no usable fallback. Unlike <img>, <object> supports genuine fallback content: anything placed between <object> and </object> renders only when the browser can’t display the embedded resource, and that same content is also what assistive technology reads as the element’s text alternative.

This element has neither: no aria-label or aria-labelledby naming it, and nothing between its tags for a browser or screen reader to fall back to if the embed itself fails.

Why does this matter?

When an <object> has no fallback and the embedded resource can’t be rendered or interpreted (a PDF viewer plugin that isn’t installed, a browser that blocks the content type, a screen reader that reads DOM structure rather than rendering the embed visually), the user gets nothing at that point on the page. No error message, no alternative way to reach the content, no indication anything was even supposed to be there.

A quarterly report embedded as a PDF through <object> with no fallback content leaves a screen reader user with a silent gap where a sighted user sees (or downloads) the report directly. There’s no link to the file, no description of what it contains, nothing to interact with: the content the <object> was meant to deliver simply isn’t available through any path.

Who is affected?

• Screen reader users: reach a silent gap in the page where embedded content should be, with no fallback text, description, or alternative link to the same resource.

What users experience

Malik uses NVDA on Windows to review a supplier’s product specifications, published as a PDF embedded directly in the page with <object data="specs.pdf" type="application/pdf"></object> and no fallback content. NVDA reaches the object and announces nothing usable: no name, no description, no link. Malik has no way to know a specifications document even exists at that point on the page, let alone open it, so he emails the supplier to ask for information that was already published, just inaccessibly.

How do I fix it?

Add fallback content between the <object>’s opening and closing tags, at minimum a direct link to the same file the <object> is trying to embed. This works because fallback content serves two purposes at once: it’s what the browser displays if the embed itself fails to render, and it’s what assistive technology reads as the element’s accessible content if no aria-label is present, so one fix covers both failure modes simultaneously.

For a simple case where a full fallback isn’t practical, aria-label alone at least gives the element a name, though it won’t help a user whose browser genuinely can’t render the embedded resource; pairing a short aria-label with real fallback content between the tags covers both the naming gap and the rendering gap in one fix.

Code Examples

<object data="/reports/q3-specs.pdf" type="application/pdf"></object>

<object data="/reports/q3-specs.pdf" type="application/pdf">
  <p>
    Your browser can't display this PDF directly.
    <a href="/reports/q3-specs.pdf">Download the Q3 product specifications (PDF)</a>.
  </p>
</object>

The fallback paragraph gives every user a working path to the same content, regardless of whether their browser or assistive technology can render the embed itself: a sighted user whose PDF plugin fails sees the same link a screen reader user hears, so nobody depends on the embed succeeding to reach the document.

Common Mistakes

Mistake: “The type attribute already tells the browser what this is, so no fallback is needed.” The type attribute helps the browser decide how to render the resource; it provides nothing to a user or assistive technology if that rendering fails or if the content is entirely inaccessible to screen readers reading DOM structure rather than a rendered plugin view. Fallback content is a separate, necessary safeguard.

Mistake: “aria-label alone is a complete fix.” An aria-label gives the element a name, but it doesn’t help a user whose browser can’t actually render the embedded resource at all: they’d hear or see a labelled-but-empty element with no way to reach the content it names. Pairing aria-label (or visible fallback text) with a genuine fallback link covers both problems.

Mistake: “Embedding a PDF this way is basically the same as linking to it.” A linked PDF opens or downloads through the browser’s normal navigation, which assistive technology handles like any other link. An embedded, unlabelled <object> with no fallback bypasses that entirely: it’s neither a working embed nor a working link, just a gap.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. This page’s ruleId, redflag-object-alt, is a docs-only alias: src/lib/wcagData.js’s DOCS_URL_MAP redirects the underlying axe-core rule object-alt to this redflag-prefixed docs slug so the extension’s “View docs” link resolves correctly. The detection logic itself is unmodified, stock axe-core. axe-core calls the check as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set, and inspects every <object> element for a non-empty accessible name via aria-label, aria-labelledby, or visible fallback content between its tags.

False negative: axe-core confirms some fallback or name exists; it cannot judge whether that fallback actually gives the user a working path to the embedded content, such as a real download link versus a vague, unhelpful sentence. False positive: none typical for this check, since resolving to non-empty fallback content or an accessible name is a binary condition axe-core evaluates reliably. Manual step: confirm the fallback content actually provides a usable alternative (ideally a direct link to the embedded resource), not just placeholder text that satisfies the check without helping anyone.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Navigate to the <object> element’s location on the page.
3. Listen to what’s announced: it should describe what’s embedded and, ideally, offer a way to reach the same content directly, not silence or a bare generic role.
4. Disable the relevant browser plugin or PDF viewer, if practical, and reload the page to confirm the fallback content actually displays and remains usable.
5. If nothing is announced and no fallback link appears, the check fails.

Related WCAG Success Criteria

1.1.1 Non-text Content: All non-text content must have a text alternative that serves the equivalent purpose. An <object> with no accessible name and no fallback content fails this criterion directly.

Related Issues

Image is missing alt text is the equivalent missing-text-alternative failure on a plain <img> rather than an embedded object.

Image map area element is missing alt text and Image input is missing alt text cover the same naming failure on two other non-text element types axe-core checks separately.

Alt text is a filename or placeholder covers the equivalent quality problem when text does exist but conveys nothing useful, the next failure mode past this one.

Alt text repeats adjacent visible text covers a subtler quality issue on the same missing-text-alternative family of rules, where the text exists and is accurate but duplicates something already on the page.

References

• W3C Understanding 1.1.1: Non-text Content
• MDN: object element
• WebAIM: Alternative Text