Should more mappings be based on Graphics ARIA roles rather than Core ARIA roles?

[joanmarie]

Most of the mappings in the SVG AAM, for elements which should be exposed via accessibility APIs, state the following:

$GRAPHICS_ARIA_ROLE role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; otherwise, no accessible object created

There are exceptions, of course, for instance when there is no corresponding Graphics ARIA role. With this in mind:

The image element currently states:

img role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; otherwise, no accessible object created

Is that intentional? I ask because [Graphics ARIA does have a graphics-symbol role (https://rawgit.com/w3c/graphics-aria/master/#graphics-symbol). And the Graphics AAM mapping for graphics-symbol is essentially the same as the Core AAM maping for img. Are implementations and ATs supposed to treat image like img or like graphics-symbol?

BTW, by filing this issue, I'm not saying a change should be made necessarily. But I'm working on the implementation of Graphics ARIA roles in WebKit at the moment. And now that the SVG AAM contains mappings stated in terms of Graphics ARIA roles, I think the WebKit SVG accessibility implementation should have a similar change (i.e. so the code jives with the spec). What I do for SVG image will depend on if it should be img or graphics-symbol.

[joanmarie]

I updated the title because I found some more:

• foreignObject - group or graphics-object?
• g - group or graphics-object?
• mesh - img or graphics-symbol?
• textPath - group or graphics-object? See also TextPath and TSpan need platform-specific mappiings #2 and what was done for text
• tSpan - group or graphics-object? See also TextPath and TSpan need platform-specific mappiings #2 and what was done for text

[joanmarie]

@boggydigital and @AmeliaBR: Any thoughts?

[AmeliaBR]

These are all intentional, except text/textPath, where (as noted in the spec) I would much rather have a dedicated "text-span" role, but ARIA is lacking.

We introduced the new graphics-* roles because we needed different semantics compared to the core ARIA roles. If we start applying them to elements that do fit the original semantics, then we dilute the differences in meaning.

There's a section at the end of the ARIA Graphics spec that covers some of the differences, and more details in the individual role descriptions. Short version

img vs graphics-symbol:

• use img for a complete image that requires a full description & has meaning on its own
• use graphics-symbol for an icon where the shape represents a category or simple value, separate from its visual appearance.

group vs graphics-object:

• use group for a collection of similar items
• use graphics-object for a single complex item which may have component parts

The defaults for SVG elements are always going to be a little bit arbitrary, because SVG elements are not defined by their semantic meaning. But the defaults were based on thinking of how these elements would be most likely used if the particular element was worth giving an accessible name in the first place.

An SVG shape element, other than perhaps a path, won't often be a complete image on its own. So if you're giving an individual circle or a rect an accessible name, the shape is probably acting as a generic symbol.

An image, in contrast, is a direct equivalent to an img in HTML, and should have the same role. In some cases, the SVG image is only part of the complete SVG graphics, but it will only rarely act as a category symbol or icon in a diagram or chart.

A g element is probably used equally often for both group and object semantics. But the name of the element comes from "group", so the group role is the default and graphics-object is the semantic override.

A foreignObject is also open-ended, but it won't usually fit the graphics-object semantic (it's usually used to embed an HTML document fragment, not a single graphic). Common uses of foreignObject are to embed one or more HTML input elements, or to embed a section of formatted text. So group is the generic role for a document section worth giving a name to when no other semantic is given. (Although the element would often simply be presentational: like most SVG elements, it is only exposed to the accessibility tree if the author has given it a name or functionality.)

A mesh is a shape with complex, two-dimensional paint pattern, which makes it about halfway between a path and an image as far as the roles it could play in a graphic. I opted for treating it as closer to an image than a simple shape, but this is definitely one of the arbitrary distinctions.

[AmeliaBR]

P.S., If you have any ideas for clarifying text in either the SVG-AAM or Graphics Roles spec, let me know.

[AmeliaBR]

I'm closing this issue, but if anyone wants to suggest changes for a specific element, please open a separate issue. There is still an open issue (#2) about textPath and tspan.