Repository navigation
Should SVG be role="graphics-document" in all cases? #43
Description
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
Activity
jasonkiss commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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.
Watson, IBM, W3C
Accessibility
jasonkiss commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
From @fredesch on April 26, 2016 14:21
@joanmarie we will discuss at task force meeting tomorrow.
jasonkiss commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
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
svgelement is not the top-level object, e.g. it's the child of thebodyor adivor 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 tobody).(Comment edited to update the mappings link.)
jasonkiss commentedon Oct 12, 2016
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:
So, on the OS X implementation:
Is this a fair representation of the discussion across multiple bug trackers? Please correct me if I've missed some conflicting viewpoint. Thanks.
jasonkiss commentedon Oct 12, 2016
From @cookiecrook on April 28, 2016 21:13
@joanmarie Can you double-check the mappings link? It's 404 for me.
1 remaining item
jasonkiss commentedon Oct 12, 2016
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 commentedon Oct 12, 2016
From @richschwer on May 4, 2016 18:12
changing the role to graphics-document per discussion today
jasonkiss commentedon Jan 22, 2018
What's the consensus on this question? Does
svgelement in an HTML document always map to the graphics-document role, or is it contingent on labelling or contents of thesvgelement? @AmeliaBR, @fredesch, @joanmarie, @cookiecrook? Thanks.svg mappings / issue #43
[-][HTML-AAM] SVG element should be role=graphics-document[/-][+]Should SVG be role="graphics-document" in all cases?[/+]jasonkiss commentedon Feb 7, 2018
In the hope of making (forcing?) progress on this, I've updated the mapping for
svgto 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 commentedon Feb 7, 2018
Ping @IanPouncey for relevance/dependancy on the SVG AAM?
AmeliaBR commentedon Feb 3, 2020
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 commentedon Feb 3, 2020
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 commentedon May 21, 2020
Also #290