Axe-core: 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.

[StommePoes]

For me it's the same for all icons, it's just that at my job they're almost always inside buttons, otherwise they're decorative. Silent with JAWS on FF but I could hear with NVDA in FF, I did file a bug on the button not getting the acc name from the SVG as it should and so have been using aria-label, but I'm not using aria-label on the SVGs that are "loose" (I guess I could since we're giving them the img role, but I'd rather be able to just use the <title> like we're supposed to).
I can't tell if it's a JAWS thing or an FF thing.

[weboverhauls]

Thanks for the info @StommePoes. I added test cases for buttons with SVG content to my test page. I believe it reproduces the issue with JAWS you mentioned (see second test under Buttons).
https://weboverhauls.github.io/demos/svg/#buttons

[StommePoes]

Thanks @weboverhauls yeah we have some QA testers with more versions of JAWS and they're still getting it too (I'd been hoping it was maybe a JAWS thing and that 18 would fix this... Jamie from NVDA said he's not diving into the DOM for SVGs in buttons despite the Firefox bug being an actual bug). I'm starting to think I should just have all our devs not follow my code but use aria-label all over the place since icon-buttons are designers' fave things around here :/

[paulirish]

We have a bug about this down in Lighthouse: https://github.com/GoogleChrome/lighthouse/issues/2425

Should we just exclude SVGs from the results for now? (Or should you?)

[WilcoFiers]

@paulirish There is some test data in this thread that suggests svg titles isn't fully supported yet. I don't know about svg alt. If you can provide data showing otherwise we can certainly add it to aXe. We generally don't add things to axe-core until they are well supported, so without evidence to the contrary, I think aXe should keep treating this as an error.

[sgregson]

Would it be possible to get #683 cherry-picked into the stable aXe extension channel as a patch version? The current experience seems rather broken as the issue citation isn't internally consistent with the markup cited.

Example

Stable aXe extension run against https://codepen.io/sgregson/full/jZzNqa/

[marcysutton]

@sgregson the alt attribute doesn't expose an accessible name on an SVG element even with role="img", so that markup won't ever work. However, the change you're referencing was released as part of axe-core 3.0.0-beta.1 today. You'll have to wait for an extension release.

[sgregson]

sorry for the delay, thanks for the feedback @marcysutton !

[chaals]

I've been working on a test for this - but until my outstanding editorial PR is dealt with, hopefully today, I won't publish. (I wasn't thinking carefully and mixed two branches. I don't think it is worth trying to disentangle it all properly, since just waiting half a day or so should save that work at no appreciable cost).

At the moment it looks at inline SVG (where the img element is used to bring in an SVG, the normal tests for that element apply). The test warns of a problem unless it finds one of:

• A title child of the svg itself
• aria-labelledby (using an existing test)
• role="presentation" on the svg element, under the assumption that means no alternative is needed
• a single text element, under the assumption that while multiple text elements means there is something else to understand, a single one represents a styling effect, e.g. for a button, and the content of text elements is exposed.

In any event it most obviously needs to check for an aria-label attribute. It also makes sense to fit the rule, or the checks, into one that tests if the image is inside a figure that has a figcaption.

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