Lighthouse: Ignores "alt" text on <object> element

Created on 30 Sep 2018  路  5Comments  路  Source: GoogleChrome/lighthouse

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
pending-close

Most helpful comment

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 :)

All 5 comments

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 :)

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.)

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!

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. :)

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 鈥撀爁eel free to close this.

Apologies, but thank you both for the help!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

workjalexanderfox picture workjalexanderfox  路  3Comments

mbparvezme picture mbparvezme  路  3Comments

johnfrancisli picture johnfrancisli  路  3Comments

codepodu picture codepodu  路  3Comments

mjara74 picture mjara74  路  3Comments