Having a11y tools read svg's in img's as a part of the dom tree seems like it goes against the spec which says "An img element represents an image", and in basically all other places of the spec an image either has a proper alternate representation (the alt attribute) or is not parsed for a11y purposes.

This is a hack to be able to embed design within a tool that was never meant for graphic design. If github readmes where meant to be both accessible and designable they would not be just markdown/rst.

Your suggestion means a11y software having a hack that goes against the spec to enable a hack that was used to circumvent a platform that knowingly crippled it's document representation because they thought it would be used for mostly unstyled info.

If your accessibility software gives up when it sees an image without an alt attribute, then I see that as an opportunity for improvement.

It's almost 2021. Accessibility software can use ML and OCR to provide a semblance of navigable semantics for visual-first media like images. See Project Naptha [1] for one such example of adding OCR-powered text detection to images encountered in your browser.

In the specific case of SVG, the text can already be fully semantically extracted with very little work.

1. https://projectnaptha.com/

> Accessibility software can use ML and OCR to provide a semblance of navigable semantics for visual-first media like images. See Project Naptha [1] for one such example of adding OCR-powered text detection to images encountered in your browser.

Hey, if we really work at it, I'm sure we can make it impossible for anyone to use the Web without sending all of their information to an untrusted third party who has every incentive to violate your privacy, but won't, because they say they won't.

> It's almost 2021.

Indeed. We should have gone a lot further down this slippery slope by now.

Just because the parent's example of in-browser OCR involves a SaaS API, doesn't mean in-browser OCR inherently has to involve a SaaS API. OCR runs just as well on your own computer. Heck, phones could run the original realtime WordLens software just fine, and that was 10 years ago.

(Offline) OCR models should really be everywhere now, just like offline speech-to-text models are. It's kind of surprising that it's not just "a thing" built into every OS.

This is not just about "text extraction", my whole point was that an alt text is not enough. An SVG document has a DOM and a navigatable accessibility tree just like HTML documents (including ARIA attributes etc). There is more that happens for sighted users too - text becomes selectable in the SVG, links are clickable, etc. All that probably needs the context of a browsing context and DOM created in an <iframe> or <object> and not in an <img> and is specced in detail. I really don't blame browsers for implementing the spec.

SVGs can also be referenced with object tags at which part they become part of the DOM. This is required if you want SVGs with embedded hyperlinks to work.

Yeah, my point was having them as a11y objects in img tags, which is how they have to be used within the github readmes. felixfbecker's parent comment talked about object/iframes for SVG's.

That will run scripts inside the SVG though. <iframe> can be set to disallow that using `sandbox` and/or `csp`.

The pattern I've noticed is:

1) New technology exists

2) Accessibility nerds tell everyone not to use it, because it's not supported by screen readers

3) Everyone uses it anyways

4) Screen readers support it

5) GOTO 1

It seems very similar to people who think they can fix climate change by yelling at enough people not to buy certain things.