Ignores "alt" text on <object> element

[lukeed]

Provide the steps to reproduce

1. Run LH on https://pwa.cafe

What is the current behavior?

It fails, saying that <object> elements do not have [alt] text, put prints the failing element showing that it does indeed have an alt attribute with text.

https://twitter.com/lukeed05/status/1046462007841447936

Second Picture

What is the expected behavior?

It should be able to parse the alt text correctly since it exists.

Environment Information

• Affected Channels: Chrome Extension
• Lighthouse version: 3.2.0
• Node.js version: N/A
• Operating System: OSX

[patrickhulce]

I'm not an expert on the object element (as you note it's rarely used these days 😉), but the linked axe docs from Lighthouse have this to say...

Add alternative text to all embedded object elements using either inner text, title attributes, aria-label or aria-labelledby.

It seems like screen readers expect alt text somewhere other than the alt attribute for the object element. If you think this is wrong, feel free to file an issue over in axe-core. We'll pickup anything they change in the next version :)

[paulirish]

Aye. I'd say this flagged a pretty worthwhile issue.

The <object> tag on pwa.cafe is important content and certainly deserves an alt attribute to describe what a screenreader user is missing out on.

@lukeed btw which tool generated the SVG? (edit: ah.. termtosvg.)

[lukeed]

Thank you both @patrickhulce and @paulirish

I'll move the text within the tag body if that's the expected behavior. TBH, I'm not an expert on object either, but I did expect it to warrant an alt tag. I'm a little confused if this is a valid issue or if I should move the content within the tags.

FWIW I'm only using it because Chrome inconsistently renders the SVG text/fonts when used with an <img> tag. Only the monospace font is used btw.

@paulirish Yeah, that one 😆 After a lot of fiddling and customization of the final animation. Overall pretty impressed with it though!

[paulirish]

I'm a little confused if this is a valid issue or if I should move the content within the tags.

not totally sure what you mean. afaik you have a few options with this svg

1. <img src="file.svg">
2. <img src="data:base64encodedsvg">
3. css background-image
4. <object data=file.svg>
5. inline SVG right inside the HTML

the and options all require an alt attribute.

Personally I feel like inline SVG is the right semantic call here. it carries with it some other accessibility responsibilities (these probably?), but you're luckily in that axe-core currently doesn't inspect SVG, so it won't be flagging things.. for now. :)

[lukeed]

Thanks~! I agree that inline SVG is the best choice here, but I'll have to circle back to that. It poses a slight challenge during development due to how webpack wants to base64 the SVGs but extract them for production builds.

Gotta play with the defaults for @pwa/core regarding this 🤔

Anyway, I moved the alt text within the object tags & am now back at full 100s – feel free to close this.

Apologies, but thank you both for the help!

[chrisgraham]

This issue needs reopening. Upstream has determined there is no bug, so there is a lighthouse documentation problem on:
https://web.dev/object-alt/?utm_source=lighthouse&utm_medium=devtools

It specifically shows examples for the case that axe has determined to not work with access tools, and hence fails on.

It also talks about an alt attribute which does not exist (there is no alt attribute on the object element).

[tunetheweb]

Copying this extra useful (IMHO) info from the closed duplicate issue: #11649 (comment)

Just hit the same issue and did some investigating and think that Lighthouse (well axe) is correct to flag this, but documentation could certainly do with flagging this, reasonably common, use-case of using <object> for loading SVGs.

This is fine:

<object>
This is visible text
</object>

However this is not fine:

<object type="image/svg+xml">
This text is not exposed to the accessibility tree
</object>

and neither is this:

<object data="example.svg">
This text is also not exposed to the accessibility tree
</object>

In effect, setting the type or data of the object means anything in the element as it is no longer able to treated it as plain text and so can't be used as the accessible name. You can see this is the case by looking at the Accessibility tree in Chrome Dev Tool.

Therefore the last two examples do need an accessible name (unless it's switched to being presentational with either role="presentation" or aria-hidden="true"), which should be provided by the aria-label, aria-labelled-by or title (note you cannot use the alt attribute on an object element). I can confirm when adding these the audit no longer fails.

@midzer it looks like you've updated your object to be aria-hidden on your site:

<object data="/svg/map.svg" type="image/svg+xml" id="world" alt="World map" aria-hidden="true"></object>

However it probably should be this:

<object data="/svg/map.svg" type="image/svg+xml" id="world" aria-label="World map"></object>

[midzer]

@tunetheweb Thanks for information. I've updated my site.

[adamraine]

Docs have been update, but changes are not published as of writing this