Should SVG be role="graphics-document" in all cases?

[jasonkiss]

From @stevefaulkner on April 25, 2016 13:10

as per SVG spec, SVG element is role=group
https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics

Copied from original issue: w3c/aria#347

[jasonkiss]

From @AmeliaBR on April 25, 2016 13:21

Added info: role="group" is not ideal, as noted in the SVG-AAM.

We (SVG Accessibility TF) are looking at the platform-specific mappings currently in the HTML-AAM to see if they are an improvement. Once we have good mappings and a stable spec to cross reference, the preferred ARIA role would be graphics-doc.

To keep the specs synchronized, it may be easier for HTML-AAM to cross-reference SVG-AAM, although we'll need to keep an eye on publication schedules.

[jasonkiss]

From @richschwer on April 25, 2016 13:54

Good point. I updated the SVG spec. to be the graphics-doc role for the SVG element. We are pushing for feature freeze of the ARIA spec as a pseudo last call in June. We should do the same with our graphics spec.

We should switch to the graphics-doc role now and then work on the mappings. So, please change the issue to say graphics-doc vs. group and refer to the SVG graphics spec. for the definition of the role value.

[jasonkiss]

From @joanmarie on April 25, 2016 17:3

For SVG elements inside HTML, the group role is not bad if there are children. If there are not children, however, it becomes problematic for reasons discussed in WebKit bug 156774.

For the childless SVG inside an HTML document, I have suggested the mapping be to the platforms' image role. (SVG elements which are not inside an HTML document, graphics-doc makes sense.)

[jasonkiss]

From @fredesch on April 25, 2016 19:10

Joanie,

A childless SVG element would not appear on the screen and if you wanted to
give it a role - none or presentation makes more sense.

 Regards,                                                 

Fred Esch                                                 

Watson, IBM, W3C
Accessibility

[jasonkiss]

From @AmeliaBR on April 25, 2016 19:25

As Fred notes, "childless" SVG in the DOM isn't relevant. However, the issue is more a "childless in the accessibility tree" sense: if none of the SVG's child elements have their own alt text or roles, they will be excluded from the accessibility tree, leaving an apparently-empty "group" for AT users.

If an accessibility API already has a role that conveys graphic/image, but also supports child elements, that would be preferable. We'll be trying to identify (or encourage the creation of) such roles with the new graphics mappings.

For the general case, I am intrigued by Joanie's idea of having a switch in the mappings: use the group mapping if there are meaningful child elements, or the image mapping otherwise. I'd be interested in other feedback about whether this is a practical solution for implementers.

[jasonkiss]

From @fredesch on April 25, 2016 19:46

Joanie,

In another email I suggested that a better role for an SVG element without
children would be none or presentation since it wouldn't be seen. But I
don't see why group isn't an acceptable role for a SVG element with no
children? The group role does not require an element to have children. In
ARIA 1.1 the group role says it can be used for logical collections.
Collections of size zero are acceptable.

For instance, if you have 3 interactive SVG diagrams and a kid can choose
which diagram to move a coin to, would you want the role of the diagram to
change as a child moves coins in or out?

[jasonkiss]

From @joanmarie on April 25, 2016 20:18

@fredesch You make a good point about the case of empty set size. Maybe we need to change things at the AT level after all....

[jasonkiss]

From @LJWatson on April 26, 2016 7:40

@AmeliaBR
"As Fred notes, "childless" SVG in the DOM isn't relevant. However, the issue is more a "childless in the accessibility tree" sense: if none of the SVG's child elements have their own alt text or roles, they will be excluded from the accessibility tree, leaving an apparently-empty "group" for AT users."

The same thought that occured to @fredesch occured to me - wouldn't this make the <svg> effectively presentational?

"If an accessibility API already has a role that conveys graphic/image, but also supports child elements, that would be preferable. We'll be trying to identify (or encourage the creation of) such roles with the new graphics mappings."

+1

"For the general case, I am intrigued by Joanie's idea of having a switch in the mappings: use the group mapping if there are meaningful child elements, or the image mapping otherwise. I'd be interested in other feedback about whether this is a practical solution for implementers."

I can see the implementation logic, but it feels a bit existentialist from the user's point of view. When is an image not an image? When it's a group...

[jasonkiss]

From @fredesch on April 26, 2016 13:32

@LJWatson
When I read the SVG AAM, it appears an SVG element will always be included in the accessibility tree (as the AAM does not say it is subject to inclusion/exclusion rules). A lot of SVG can be interactive and mutable, so I would not like to see the representation in the accessibility tree change based on an SVG having a child or not.

[jasonkiss]

From @fredesch on April 26, 2016 14:21

@joanmarie we will discuss at task force meeting tomorrow.

[jasonkiss]

From @fredesch on April 27, 2016 18:51

@joanmarie we are going to use the graphics-doc role for the SVG element. The graphics-doc role is defined in the Graphics Module and the SVG 2 spec will use the graphics-doc role. HTML will reference the SVG spec. Amelia will be putting this in the SVG 2 spec this week.

[jasonkiss]

From @joanmarie on April 28, 2016 15:15

Ok. I just looked at the mappings for my platform. The mapping will need to be conditional.

If the svg element is not the top-level object, e.g. it's the child of the body or a div or any other HTML element, the mapping should be to ROLE_PANEL (with the object attribute used to indicate it's a graphics document). The ROLE_DOCUMENT_FRAME is for top-level objects (it corresponds to body).

(Comment edited to update the mappings link.)

[jasonkiss]

From @cookiecrook on April 28, 2016 21:6

Clarifying some points of discussion: ARIA's role="group" is not a 1-to-1 mapping with some of the platform accessibility API container roles such as AXGroup on OS X.

It seems to me like most are in agreement that a labeled SVG with no accessible descendants can and should be exposed as an image on the platforms where empty generic groups are ignored by default. @joanmarie first proposed this, and I echoed it later independently (sorry for missing your first comment, Joanie)...

Also:

• If the SVG has accessible contents, one of the platform container roles should be used.
• If an image role with descendants also works, that is preferred.

So, on the OS X implementation:

• unlabeled SVG without accessible descendants will be ignored.
• labeled SVG without accessible descendants will be exposed as a labeled AXImage.
• unlabeled SVG with accessible descendants will have the descendants exposed directly.
• labeled SVG with accessible descendants will be exposed as an AXGroup (not equiv to role=group).

Is this a fair representation of the discussion across multiple bug trackers? Please correct me if I've missed some conflicting viewpoint. Thanks.

[jasonkiss]

From @cookiecrook on April 28, 2016 21:13

@joanmarie Can you double-check the mappings link? It's 404 for me.

[jasonkiss]

From @cookiecrook on April 28, 2016 21:16

Also, a link to the SVG meeting minutes would help.

[jasonkiss]

From @joanmarie on April 28, 2016 22:19

@cookiecrook. Sorry. Try this one: https://rawgit.com/w3c/aria/master/graphics-aam/graphics-aam.html#mapping_role_table

[jasonkiss]

From @richschwer on May 4, 2016 18:12

changing the role to graphics-document per discussion today

[jasonkiss]

What's the consensus on this question? Does svg element in an HTML document always map to the graphics-document role, or is it contingent on labelling or contents of the svg element? @AmeliaBR, @fredesch, @joanmarie, @cookiecrook? Thanks.

[jasonkiss]

In the hope of making (forcing?) progress on this, I've updated the mapping for svg to use the graphics-document role in all cases. I suspect this isn't accurate, so am renaming this issue and moving it to AAM v2.

[LJWatson]

Ping @IanPouncey for relevance/dependancy on the SVG AAM?

[AmeliaBR]

I cross-posted this on the SVG-AAM repo: w3c/svg-aam#12
(This came up on Twitter and I couldn't find the issue because it was on HTML-AAM instead of SVG-AAM.)

I'd like some feedback from implementers if they see any problem with having an element's role depend on it's child tree. If it seems feasible to include that check, then I agree that we should use the img role for simple SVG icons/drawings, and reserving the graphics-document role for cases where there is accessible child content.

Either way, it's probably best if the HTML-AAM just links to the SVG-AAM. But I know that the SVG-AAM has been kind of inactive lately, so I'm OK with keeping this discussion alive here where more people will see it.

[AmeliaBR]

Also worth mentioning that it looks like the resolution to the WebKit bug was to use the image role, so they've figured out the implementation issues on that side. Should try to get it standardized.

[cookiecrook]

Also #290