[HTML-AAM] SVG element should be role=graphics-document

[stevefaulkner]

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

[AmeliaBR]

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.

[richschwer]

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.

[joanmarie]

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

[fredesch]

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

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

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.

[fredesch]

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?

[joanmarie]

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

[LJWatson]

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

[fredesch]

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

[fredesch]

@joanmarie we will discuss at task force meeting tomorrow.

[fredesch]

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

[joanmarie]

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

[cookiecrook]

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.

[cookiecrook]

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

[cookiecrook]

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

[joanmarie]

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

[richschwer]

changing the role to graphics-document per discussion today

[jasonkiss]

This issue was moved to w3c/html-aam#43