Add support for SVG images

[dylanb]

We do not handle SVG images correctly at the moment, need to be able to calculate the accessible name correctly for inline SVG and report when not present.

[dsturley]

I remember looking into this a while ago; there did not seem to be a consensus as to the proper or recommended way to add alt-text to inline SVG images.

Needs research and specification.

[dsturley]

@dylanb Can you define some requirements for this? Browser support is flaky and I didn't see a definite answer from the specifications.

[dylanb]

deferring until better browser support

[dylanb]

Looking for help to document what portions of the accessible name calculation work properly for svg images (both inline and referenced via a src attribute on an <img> element.

Platforms that need to be supported are:

1. NVDA and FF on Windows (7 or 10)
2. JAWS and IE on Windows (7 or 10)
3. Safari VO on OS X latest
4. Safari and VO on iOS latest
5. Firefox and Talkback on Android
6. Chrome and Talkback on Android

[StommePoes]

http://www.stommepoes.nl/work/firefox_svg.html This is a bit special because it's using a sprite and they're not nested. Would be great if mobile users could test these (I don't own an Android nor an iThing).

[dylanb]

@StommePoes could you add a failing example to that page? There are two types we need:

1. An inline SVG image without any alt,
2. An <img> element that references an SVG image

[StommePoes]

Yes.

[dylanb]

This page has interesting data about support http://simplyaccessible.com/article/7-solutions-svgs/

[StommePoes]

Re that link ^ for Windows High Contrast, we've been avoiding inline fill colours and instead have set it that the SVGs fill in CSS equals "currentColor" and that it must have a parent wrapped around it with a set color: someAccessibleColor. When our text colours change on WHC settings, the SVG should follow suit.
Setting a background for when we cannot do that is a good idea though.

[dylanb]

@StommePoes example pretty please...

[StommePoes]

Of using currentColor? Sure.

[goodwitch]

Southwest Airlines uses svg for images sometimes. See example in footer of the Southwest Cargo logo/link on www.southwest.com of /assets/images/globalnav/logos/swa_footer_logo_swa_cargo.svg

[dylanb]

@goodwitch That example clearly shows how SVG is currently not supported.

I have created this variant of the code http://dylanb.github.io/SVG/southwest.html There are two almost identical markups - except in the one instance the role="img" is attached to the <svg> element and in the other case, to the enclosing <div>.

In the case of the <svg> element, the role is completely ignored by Safari (iOS and OS X), in the case of the <div> it is correctly exposed.

[dylanb]

Good examples of SVG with notes on current support by browsers https://weboverhauls.github.io/demos/svg/ Thanks to @weboverhauls

[jacksleight]

Paciello Group have a good article on this:
https://www.paciellogroup.com/blog/2013/12/using-aria-enhance-svg-accessibility/

The "ARIA enhanced SVG accessibility" method appears to have full browser/screen reader support:

<svg xmlns=http://www.w3.org/2000/svg role="img" aria-labelledby="title  desc">
   <title id="title">Circle</title>
   <desc id="desc">Large red circle with a black border</desc>
   <circle role="presentation" cy="60" r="55" stroke="black" stroke-width="2" 
   fill="red" />
</svg>

[StommePoes]

Jack: except with JAWS on *FF, I never hear these. EDIT (It was FF, not IE, where I could not hear otherwise properly written SVGs even with the aria-labellebdy hack)

Dylan (had forgotten about this):

[dylanb]

@jacksleight That example is exactly the same as one of the ones that @weboverhauls has on his test page that is shown not to work properly with VO

[jacksleight]

@dylanb @weboverhauls Ah OK, my mistake. Saw the compatibility table on paciellogroup.com and assumed it was right (don't have a Windows box to test on currently). Never mind.

[weboverhauls]

Well, the example by @StommePoes is within a button element so results may vary, who knows! I'll need to add button use cases to my test page.

[chaals]

OK, I have a Rule, and a dozen integration tests. The rule determines whether an SVG (e.g. inline or standalone) provides an alternative for the image as a whole. The checks pass if any of the following are true:

• There is atitle element as a direct child of the svg element, which may have no text content as an equivalent to alt="". A title descendant, that is a child of something else deeper in the tree does not cause the test to pass, since that might be a deeper explorable structure.
• There is an aria-labelledby attribute that points to something (re-uses the existing check for this).
• There is role="none" or role="presentation" on the svg element (using existing checks).
• The svg element has an aria-label attribute - which can have an empty value.
• There is a single text element as a descendant of the svg . tspan children of the text element have no impact on the outcome.

I have integration tests for these, and I am working them into the right shape.

So,

1. Should I continue down this path to a Pull Request for an SVG-specific test? (In the medium-term I think it makes sense to refactor the rules for text alternatives, but that can be done later using the checks, and trying them on reality for a while isn't a bad first step IMHO)
2. Is there a test I should do differently for real-world compat?

[dylanb]

@chaals in order to pass any rule, we must show that it passes markup that is "accessibility supported", to do this we have to validate that the same markup works in all the combinations listed here: https://github.com/dequelabs/axe-core/blob/develop/doc/accessibility-supported.md

Have you validated that all of the above work in all these combinations?

[chaals]

Not yet, since I am still working from memory of what actually works, and checking whether the rough approach seems OK before sinking a whole lot more time into it.

When I next have some time I'll set up the tests properly (I has them, but I'm busy this week).

[weboverhauls]

FYI: Updated my test page with TalkBack/Chrome & latest NVDA/FFX https://weboverhauls.github.io/demos/svg/

[dylanb]

@weboverhauls Why did you fail the VO with Chrome on this markup

<p><img src="checkmark.svg" width="50" alt="checkmark"></p>

For me it reads the alt attribute but gets the role wrong. I would count this as minimally passing on the alt text at least.

Update: does not work on iOS with VoiceOver - could you add operating system to your test matrix?

[weboverhauls]

Can you check again Dylan? VO testing thus far is only on Safari 11.

[dylanb]

@weboverhauls sorry - check what?

[weboverhauls]

There should be no test results for VO with Chrome so far.
PS: added JAWS 18/IE 11 results--all pass, as did TalkBack/Chrome!

[dylanb]

are you testing VO on iOS?

[weboverhauls]

On OSX. Will work to add iOS and clarify OS.

[dylanb]

There is new work in the WAI-ARIA group that relates to this, we need to track support for this https://www.w3.org/TR/graphics-aria-1.0/

[jeankaplansky]

rule help infrastructure in place 1/27/2020

[jeankaplansky]

Release notes and rule content in place 2/03/2020

[padmavemulapati]

"svg-img-alt" rule checking the svg elements with role=graphics-document, role=img and role=graphics-symbol through ARIA label, the title attribute or by having a non-empty child title element.

This rule limits the role-img-alt rule to elements in the HTML namespace to avoid overlap with the svg-img-alt rule.

[devniel]

Hello, I have a related problem like the last message, the axe extension is returning error for nodes with role="graphics-document", I'm getting the ARIA roles used must conform to valid values issue. Is it something not supported ?. Thank you.

[StommePoes]

Hi @devniel that role does not appear to be an authorable role. If I go by this list: https://www.w3.org/WAI/PF/aria/roles notice it's not listed. So I think it makes sense that aXe would complain; this doesn't look like a valid role --for web developers to use--.

graphics-document appears to be an internal AAM-used role for browsers to know where to expose things. SVGs have been voted to be graphics-document by default, which I read in a Github issue is considered to be a type of document, while in a webkit ticket I saw Apple was committing to eventually exposing at least inline SVGs as images (Apple exposed them as "group"). Firefox exposed SVGs as "diagram" for years but I saw on an old ticket that they've changed this too?

If you want your SVGs to expose themselves as images to AT esp for (older) Safari, use role="img" if they're inside image tags (<img src="foo.svg" alt="foo">) otherwise, for inline SVG (<svg.../>) leave it with no specified role.

[weboverhauls]

Here's the graphics-document role from the WAI-ARIA Graphics Module specification (Oct 2018), which has very limited browser/AT support as far as I know.
https://www.w3.org/TR/graphics-aria-1.0/#role_definitions

[StommePoes]

While I've been quick to roll my eyes at developers complaining that "accessibility is hard", I'm absolutely willing to go to bat for developers who try to look up a list of roles only to miss completely that there are other lists of roles elsewhere that they would never have thought to go looking for. That whole "role" section appears to list all roles:

Roles are categorized as follows:

1. Abstract Roles
2. Widget Roles
3. Document Structure Roles
4. Landmark Roles
5. Live Region Roles
6. Window Roles

...with no mention of a separate "graphics roles" list.

Not aXe's fault and not the place to complain about it, but it's pretty frustrating.