5 ms·

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 embedd

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.

firloop 6y ago
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.
- cj 6y ago
  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.
- felixfbecker 6y ago
  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).
TooCreative 6y ago
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.
- matt_kantor 6y ago
  I'm on mobile and can't double check this right now, but couldn't you resize the frame until it no longer scrolls?
- bacondude3 6y ago
  There are projects such as iFrame Resizer [0] for this, and you're correct that it does require cooperation from the iframe source. [0]: https://davidjbradshaw.github.io/iframe-resizer/ https://davidjbradshaw.github.io/iframe-resizer/
ancarda 6y ago
Aren't SVG badges meant to be non-essential? Just display some stats to show-off? Edit: To clarify, I'd love to see SVGs become more accessible, but I would hope the lack of support today isn't a problem as far as README shields.
- felixfbecker 6y ago
  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).
- deleted 6y ago
  [deleted]
Sephr 6y ago
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.
- SahAssar 6y ago
  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.
  - kevin_thibedeau 6y ago
    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.
    - SahAssar 6y ago
      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.
    - felixfbecker 6y ago
      That will run scripts inside the SVG though. <iframe> can be set to disallow that using `sandbox` and/or `csp`.
  - Sephr 6y ago
    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/ https://projectnaptha.com/
eyelidlessness 6y ago
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).
shirakawasuna 6y ago
Your comment is 100% correct and valuable. 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.
t0astbread 6y ago
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.
darekkay 6y ago
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. [1] https://www.deque.com/blog/creating-accessible-svgs/ https://www.deque.com/blog/creating-accessible-svgs/
JxLS-cpgbe0 6y ago
What about 1. Use of AIRA tags on the <img> like `aria-label` 2. `aria-labelled-by` pointing to a <desc> within the SVG? 3. Using the <title> element within the SVG 4. Adding role="group" to make the SVG traversable 5. role attributes on each <g>roup. JAWS and NVDA will announce this.
- felixfbecker 6y ago
  How are you going to express a whole chart in an aria-label string? SVGs have an accessibility tree. An alt string is not enough.
  - JxLS-cpgbe0 6y ago
    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.

firloop 6y ago

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.

cj 6y ago
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.
felixfbecker 6y ago
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).

TooCreative 6y ago

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.

matt_kantor 6y ago
I'm on mobile and can't double check this right now, but couldn't you resize the frame until it no longer scrolls?
bacondude3 6y ago
There are projects such as iFrame Resizer [0] for this, and you're correct that it does require cooperation from the iframe source. [0]: https://davidjbradshaw.github.io/iframe-resizer/ https://davidjbradshaw.github.io/iframe-resizer/

ancarda 6y ago

Aren't SVG badges meant to be non-essential? Just display some stats to show-off? Edit: To clarify, I'd love to see SVGs become more accessible, but I would hope the lack of support today isn't a problem as far as README shields.

felixfbecker 6y ago
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).
deleted 6y ago
[deleted]

Sephr 6y ago

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.

SahAssar 6y ago
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.
- kevin_thibedeau 6y ago
  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.
  - SahAssar 6y ago
    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.
  - felixfbecker 6y ago
    That will run scripts inside the SVG though. <iframe> can be set to disallow that using `sandbox` and/or `csp`.
- Sephr 6y ago
  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/ https://projectnaptha.com/

eyelidlessness 6y ago

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

shirakawasuna 6y ago

Your comment is 100% correct and valuable. 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.

t0astbread 6y ago

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.

darekkay 6y ago

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. [1] https://www.deque.com/blog/creating-accessible-svgs/ https://www.deque.com/blog/creating-accessible-svgs/

JxLS-cpgbe0 6y ago

What about 1. Use of AIRA tags on the <img> like `aria-label` 2. `aria-labelled-by` pointing to a <desc> within the SVG? 3. Using the <title> element within the SVG 4. Adding role="group" to make the SVG traversable 5. role attributes on each <g>roup. JAWS and NVDA will announce this.

felixfbecker 6y ago
How are you going to express a whole chart in an aria-label string? SVGs have an accessibility tree. An alt string is not enough.
- JxLS-cpgbe0 6y ago
  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.