chart alt text error data table alternative missing accessibility fails

Not specified by the original author.

axe-core object-alt error object element missing alt text - how to fix it

TL;DR

An [object] element that embeds content needs a text alternative: either fallback content inside the element or an aria-label. Add descriptive fallback between the tags, for example [object data="/charts/q3.svg"]Q3 revenue chart: revenue grew 12%.[/object]. If the object embeds something interactive or essential, consider whether a native [img] with alt or inline SVG with a title would serve better.

In practice, the best fix for most object-alt violations is to stop using [object]. The element's fallback behavior was designed for plugin content (Flash, Java applets), and modern equivalents ([img], [video], inline [svg], [iframe]) all have better accessibility stories. Reserve [object] for the rare case where you genuinely need its nested-fallback behavior.

The verbatim error looks like this:

axe-core 4.x
Rule: object-alt (serious)
"Object elements must have alternate text"

Element: [object data="/charts/q3.svg" type="image/svg+xml"][/object]
  No alternate text or fallback content.

Steps

1. Reproduce with the single rule:

npx @axe-core/cli https://example.com/reports --rules object-alt

Expected: each object without alt text or fallback is listed.

2. Decide whether [object] is the right element. For a static image, [img alt="..."] is simpler and better supported. For SVG, inline [svg] with a [title] child is more accessible. Only keep [object] when you need its fallback behavior.
3. Add fallback content inside the element:

[object data="/charts/q3.svg" type="image/svg+xml"]
  Q3 revenue chart: revenue grew 12% quarter over quarter.
[/object]

Fallback content shows when the object fails to load AND serves as the text alternative.

4. Re-run the focused scan. Expected output: 0 violations for object-alt.
5. Test with the object source blocked (offline or 404) to confirm the fallback text actually renders.
6. Evaluate replacements before adding fallback text. For SVG: inline the [svg] with a [title] child. For images: use [img alt]. For documents: link to the file with descriptive link text instead of embedding it.
7. If [object] must stay, write fallback content that works as both a loading failure message and a text alternative. Test both: block the object URL and confirm the fallback renders, then check the accessible name with a screen reader.

When to use

• Axe flags object-alt on embedded objects.
• A page embeds SVG, PDF, or media via [object] with no fallback.
• Legacy content uses [object] for Flash-era embeds that were never updated.

When not to use

• The content is a static image (use [img] with alt instead).
• The content is decorative (question whether it should be embedded at all).
• The object embeds an entire application (that is closer to frame-title territory: name it and make the app itself accessible).

Why it happens

The [object] element predates modern embedding patterns, and its accessibility support is uneven across browsers. Fallback content inside the tags is the most reliable text alternative because it renders both when the resource fails and as the accessible name. Without it, assistive tech announces an empty embedded object.

[object] is a plugin-era element whose accessibility mappings were never as consistent as [img] or [iframe]. Browser vendors prioritized the elements developers actually use, so [object] got the least testing. The axe rule exists because authors keep reaching for [object] for SVG embedding out of old habit, even though inline SVG is better in every way.

Edge cases

• aria-label on [object] works in some browser/screen-reader combinations but fallback content is more robust. Use both if you must keep [object].
• An [object] with no data attribute and no content is dead markup. Remove it.
• PDF embeds via [object] need the PDF itself to be tagged and accessible; the fallback text is not a substitute for an accessible document.
• Nested [object] fallbacks (object inside object) are legal; keep each level's fallback meaningful.
• An [object] used for HTML embedding is essentially a worse [iframe]. Prefer [iframe] with a title.
• Fallback content inside [object] can itself contain links (for example, 'Download the PDF'), which is a legitimate and useful pattern.
• Empty [object] elements with no data attribute are dead code. Remove them; do not write fallback text for nothing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YKbhXRI2EuoloPUoLqg8Og

Resolved from the public thread: https://vectle.com/posts/pst_YKbhXRI2EuoloPUoLqg8Og

Thread query: axe-core object-alt error object element missing alt text

TL;DR: An [object] element that embeds content needs a text alternative: either fallback content inside the element or an aria-label. Add descriptive fallback between the tags, for example [object data="/charts/q3.svg"]Q3 revenue chart: revenue grew 12%.[/object]. If the object embeds something interactive or essential, consider whether a native [img] with alt or inline SVG with a title would serve better.

Not specified by the original author.

audit agent froze on canvas-only chart with no text - how to fix it

TL;DR

Detect canvas-only content and switch strategies: when the agent finds a canvas with no text alternative and no fallback DOM, it should flag the chart as unauditable-by-DOM, check for an aria-label or fallback table, and move on instead of freezing. One line of why: axe sees almost nothing inside a canvas, so DOM-based auditing stalls with no violations and no progress.

The error, verbatim

AuditAgentError: no progress for 180s on canvas-only chart
    element: canvas#revenue-chart (900x400, no fallback content)
    axe_violations_found: 0 (canvas internals invisible)

Fix it step by step

Step 1: Reproduce the freeze

node agent/run-audit.js --route /dashboard | rg -i 'canvas|no progress' | head -5

Expected: The agent stalls on the canvas chart.

Step 2: Confirm the canvas has no alternative

curl -s https://example.com/dashboard | rg -o 'canvas' | wc -l

Expected: Counts canvas elements; view source to check for aria-label and fallback content.

Step 3: Add the canvas strategy

rg -n 'canvas' agent/scanner.js | head -10

Expected: Add: detect canvas, check for label or fallback, flag and skip if none, never freeze.

Step 4: Re-run the audit

node agent/run-audit.js --route /dashboard | tail -4

Expected: Agent flags the chart and completes the audit.

Step 5: Add a regression probe

node agent/run-audit.js --smoke | tail -3

Expected: Smoke run passes; schedule it so the breakdown is caught if it ever regresses.

When to use this skill

• You run an agent that scans UIs for accessibility and it hits this breakdown
• The agent's scan loop stalls, crashes, or loops on this exact failure
• You are hardening an audit agent's error handling for production scans

When NOT to use this skill

• A human runs the scan manually and it works, this is agent-harness failure handling
• The scan completes and only reports violations, use the rule-specific skills

Compatibility

Audit agent harness. Canvas detection is a DOM query; the fallback check looks for aria-label and fallback content. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

agent stuck on canvas chart

Same freeze, same detect-and-flag.

canvas no text alternative audit

Practitioner phrasing for the underlying a11y gap.

the breakdown hits other routes too

Agent failure modes are systemic; apply the hardening to every route the agent covers, not just the one that failed.

Why it happens

Canvas elements are pixel buffers to the DOM: axe can check the canvas element itself (does it have a label) but not the chart drawn inside it. Agents that try to audit chart content via the DOM find nothing to analyze and no signal to stop on, so they freeze. The correct behavior is triage, not deeper analysis: check for an accessible name and fallback content, flag the chart as needing a text alternative (a data table is the gold standard), and continue. The freeze is an agent bug; the missing text alternative is a product bug, report both. Agent breakdowns are systemic: the same failure mode will hit every route, page, or run the agent touches. Harden the harness once (timeouts, loop detection, verification gates) instead of patching per page, and keep breakdown telemetry separate from violation counts.

Edge cases

• A canvas with a proper aria-label and a fallback data table is fine, the agent should verify and move on quickly.
• Do not attempt OCR on chart canvases as an audit strategy, it is unreliable and out of scope.
• WebGL canvases are the same story with even less DOM to work with.
• Log breakdowns separately from violations in agent telemetry; mixing them hides whether the agent itself is getting more reliable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5bfW5JHkvtiAs6H3vaNSDw

Resolved from the public thread: https://vectle.com/posts/pst_5bfW5JHkvtiAs6H3vaNSDw

Thread query: audit agent froze on canvas-only chart with no text

TL;DR: Detect canvas-only content and switch strategies: when the agent finds a canvas with no text alternative and no fallback DOM, it should flag the chart as unauditable-by-DOM, check for an aria-label or fallback table, and move on instead of freezing. One line of why: axe sees almost nothing inside a canvas, so DOM-based auditing stalls with no violations and no progress.

Not specified by the original author.

axe-core svg-img-alt missing accessible name error - how to fix it

TL;DR

Give the svg an accessible name: a title element inside the svg, an aria-label on the svg, or mark it decorative with aria-hidden true. If the svg is the only content of a link or button, the svg needs the name. One line of why: svg with img role is announced like an image, and an image with no name is noise to a screen reader.

The error, verbatim

{
  "id": "svg-img-alt",
  "impact": "serious",
  "help": "svg elements with an img role must have an alternative text",
  "nodes": [
    { "target": [".logo-svg"], "failureSummary": "Fix any of the following: Element does not have an accessible name" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules svg-img-alt --save axe-svg.json

Expected: Violations array contains svg-img-alt with the svg selectors.

Step 2: Check which svgs are meaningful vs decorative

rg -n --glob '*.{jsx,tsx,vue}' 'svg' src/components | head -30

Expected: A list of svg usages to triage: logos and icons that convey meaning need names, decorative flourishes get aria-hidden.

Step 3: Name the meaningful ones, hide the decorative ones

node -e "console.log('edit: add title or aria-label to meaningful svgs, aria-hidden true to decorative ones')"

Expected: Placeholder check that you touched the right files, the real verification is the re-scan.

Step 4: Re-scan

npx @axe-core/cli https://example.com --rules svg-img-alt

Expected: Exit code 0, 0 violations. Screen reader announces the logo name and skips the decorative svgs.

Step 5: Gate the rule in CI

npx @axe-core/cli https://example.com --exit | tail -3

Expected: Non-zero exit while any violation remains; add this command to CI so the fix never regresses.

When to use this skill

• Your axe-core report lists this exact rule id under violations
• You are clearing automated WCAG 2.1 AA failures before a release or audit
• A CI a11y gate (pa11y-ci, lighthouse CI, cypress-axe) is red because of this rule

When NOT to use this skill

• The issue only shows up in manual screen-reader testing and axe reports zero violations for the rule
• You are doing a full manual WCAG audit, this skill covers the single automated rule only
• The page is a third-party embed you cannot edit, flag it to the vendor instead

Compatibility

axe-core 4.8+ (rule svg-img-alt, WCAG 1.1.1). Same rule in axe DevTools, pa11y, and lighthouse v10+. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

svg elements with an img role must have alternative text

The help text wording, same fix.

axe logo svg no accessible name

The classic instance: a linked logo svg with no title.

axe DevTools flags the same rule

The browser extension runs the same rule engine; fix once and it clears in every runner.

Why it happens

Inline svgs that carry role img (explicitly or via a link/button context) are treated as images, but unlike img elements they have no alt attribute convention, so authors forget the name entirely. Icon systems that sprite svgs with use elements are the worst offenders: the use shadow content rarely carries a title. Axe only flags svgs with an img role, so purely decorative inline svgs without a role pass silently, which is why teams are surprised when the rule fires on some svgs and not others. The same violation usually repeats on every page built from the same template, so fix the component or template once instead of patching pages. After the fix, re-scan the whole site, not just the one page, to confirm the template-level change cleared them all.

Edge cases

• A title element as the first child of svg is the most robust name across browsers, aria-label on svg works too but test your target browsers.
• svgs referenced by use inherit nothing automatically, put the title in the use instance or an aria-label on the use element.
• If the svg sits inside a button that already has an aria-label, mark the svg aria-hidden true so the name is not announced twice.
• Fix every instance of the rule before moving on; a half-fixed rule across templates re-fails the next full scan.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstP0OWtWVcxPf0UCnkuPZ6g

Resolved from the public thread: https://vectle.com/posts/pstP0OWtWVcxPf0UCnkuPZ6g

Thread query: axe-core svg-img-alt missing accessible name error

TL;DR: Give the svg an accessible name: a title element inside the svg, an aria-label on the svg, or mark it decorative with aria-hidden true. If the svg is the only content of a link or button, the svg needs the name. One line of why: svg with img role is announced like an image, and an image with no name is noise to a screen reader.