If only this was accessible. All a screen reader will announce is "image" plus the alt text, you cannot navigate any of the text inside the SVG when it's embedded with <img>. I was always surprised that noone ever talks about this with regard to SVG badges in readmes.
You can if it's embedded with <object> or <iframe> though, but GitHub doesn't allow that in markdown (just like they don't allow many useful things like <video>, forcing people to use GIFs instead). <iframe> actually being the more secure option here because you can disallow all scripts using <iframe sandbox> (and GitHub could easily enforce that). <iframes> still can't stretch to the content though without using JS even in 2020.
Accessibility software absolutely could read text from SVGs embedded using img tags. Just because none do so yet doesn't mean that it can't or won't be done.
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.
> 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.
If they are useful for sighted users, they are also useful to non-sighted users. E.g. if it is useful for a sighted user to read the weekly download count of a package to get a sense for how popular it is, to read the latest version, the license, etc (it arguably is) then the same applies to a non-sighted user. They shouldn't be forced to find and collect all that same information elsewhere (if it's available at all).
I think we need to embed accessibility and accessibility audits as a basic and essential aspect of all tooling and standards. It shouldn't be up to diligent people like yourself to notice these issues as a matter of expertise or personal interest, but something we notice by default because it hasn't complied with standards.
SVGs are a minefield for accessibility and tend to be either wrapped in a container with accessibility info or have nothing at all added. It's a mess.
It's totally possible to create accessible SVGs [1], you "just" need to provide a text alternative. The challenge is that there is not the _best_ implementation out there and it might be problematic for large contents wrapped in a single SVG.
For most badges it would probably work to hard-code a size. I think the badge's document could also adjust to the size of the frame (via viewport dimensions) with JavaScript. I'm pretty sure though that GitHub couldn't resize a third-party iframe to its content even with JS because of cross-origin restrictions preventing it from accessing the document.
I think anyone who cares about accessibility and uses this for something serious would instinctively put more information in the README.md, and most people who aren’t even accessibility-minded will too because an SVG is really unlikely to tell the whole story even if all the content is embedded in it (which is almost certainly impractical since it’s not actually scalable).
I imagine the hard part of securing <iframe /> tags isn't the sandbox, but instead maintaining user privacy. GitHub caches and proxies all of the images they render. One of the benefits of this is that a 3rd party can't fingerprint or otherwise log information about the requester. Seems a lot harder to get that right in the <iframe /> case.
It's technically possible to have an iframe with no "src" (not loading from a 3rd party) but still embed html/css inside the frame for sandboxing purposes.
I believe the sandbox attribute would also block javascript / scripts, although not sure what cross browser support on that looks like.
You can still cache an SVG embedded through <iframe> the same way you cache an SVG embedded through <img>. It's just an HTTP exchange. The sandbox attribute and a CSP can make sure no external content is loaded inside the SVG either (not even external images, fonts etc).
I doubt iframes can stretch to the content even with JS.
Maybe for special cases, where the content is from the same domain or is actively messaging the size outwards so you can code some interplay between the outer page and the iframe. But neither side can do it alone.
I'd use <g>roups inside the SVG for grouping contexts with their own <title>s (or references to labels) and ARIA roles and attributes. I didn't suggest having a single string represent a chart.
