SVG Accessibility/ARIA roles for graphics
This page summarizes discussion on a core taxonomy of ARIA roles for graphics. These basic roles would then later be complemented by much more detailed taxonomy describing the components of charts and other data visualizations.
- 1 Roles
- 1.1 img
- 1.2 Structured Graphical Component
- 1.3 figure
- 1.4 icon
- 1.5 symbol
- 1.6 shape
- 2 Complete Examples
- The existing role, currently covers everything from simple icons to detailed diagrams
- Children are presentational, so content is conveyed solely through label/description
- Structured graphical content (such as SVG) currently must be mapped to a non-graphical role, such as group
Structured Graphical Component
- Complex visual content with a meaningful structure to it. The component parts may be interactive.
- A large graphic can contain component graphics so long as they still meet the criteria.
- This would be the default role for <svg> and <g> elements that meet the criteria for inclusion in the accessibility tree.
- The fallback role would be group.
What to call it?
Amelia had originally suggested "graphic". Léonie pointed out that "graphic" was too ambiguous a role name. “structuredimg”, “compleximg”, and "compoundimg" have been suggested as alternatives.
More specific roles (chart, map, infographic) will be addressed separately in the charts taxonomy.
- I'm concerned that the inclusion of "img" in the name implies that this role should only be used for the complete graphic. I had been thinking of this as essentially a named group for graphical components. E.g., Chaals' example of a house image (see comments under "Shape") would be "Graphic: House; contains 3 components".
- I think graphic should be the default role for an svg element.
- graphic could also be the generic role and child roles of graphic could include - map, chart, blueprint (or technicaldrawing), diagram and possibly artwork.
- Alternatives for the graphic family of roles for an svg element would be the icon or img role.
- I don't like to use the same roles for an SVG element and parts of an SVG element. Once you get into parts you should be using a taxonomy.
Any structured graphic, or part of a graphic, that isn't significant enough to be called its own figure.
E.g, in the Faraday's Law simulation from PHET, there are a number of meaningful components: the magnet, the voltmeter, the coils, the lightbulb. The magnet is interactive: you can drag it around. The lightbulb and the value on the voltmeter change in response.
Another example, of a fun/silly interactive graphic with multiple meaningful components: A simple rocket animation that starts when the user triggers a switch. I currently have the switch labelled with a button role, but the rocket, fuse, and the SVG as a whole also have descriptions.
Questions and Comments
(We seem to be in agreement that this is a useful role to have, the discussion has focused on the name.)
- A graphic that is also a section of the document, and should be included in the table of contents.
- The fallback role would be complementary or region or another document landmark role.
- Is the role of figure to get a figure in a table of contents?
- For screen readers, it should be possible to move point of regard to such an element.
- Basically, the idea is that a figure should be more significant, and easy to find. So yes, the main distinction is it should be in the table of contents.
- I don't get the use. Is figure a role on an SVG element? If so I don't like it. The SVG will actually represent something like a map, chart, technical drawing, diagram and should be identified as such. I don't see why a SVG role would affect a table of contents.
At the 29 May teleconference of the SVG Accessibility Task Force, we resolved that we wanted a "figure" role, and that its semantics should be harmonized with the HTML 5 figure element:
The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.
Note: Self-contained in this context does not necessarily mean independent. For example, each sentence in a paragraph is self-contained; an image that is part of a sentence would be inappropriate for figure, but an entire sentence made of images would be fitting. [ABR: I have no idea what "a sentence made of images" means, but it's in the HTML5 specs]
The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc.
- A graphical element which conveys a simple concept or category using a symbolic image.
- Differs from an image in that a short name is all that is expected; a detailed description of the visual representation is not required to convey the meaning of the icon.
- Children are presentational -- an icon is an atomic element. It should never have component parts with interactivity of their own descriptions -- use "graphic" instead.
- The fallback role would be img.
- Icons used to convey simple categories of information concisely. E.g., weather icons, icons used in restaurant reviews to indicate price range, support for special dietary needs, and other features of the listed element.
- (Maybe) icons that are children of toolbars, menus and links. However, it would not always be necessary, since the role & label on the widget itself would convey the information.
Questions and Comments
- I think the argument would be that the essential information about an icon is what it represents rather than the details of its visual appearance. The latter may however be useful to know in some contexts, thus I would suggest including a brief description in DESC and a label designating the purpose of the icon in TITLE. Unfortunately, this would preclude providing help text usable as a tool tip in DESC. However, if the icon is associated with interactive behavior, then a widget role such as button should be used instead, presumably.
- To make interactive icons more non-visually accessible, a case can be made for a three-way distinction:
- 1. Short label indicating the purpose or referent of the icon.
- 2. Help text (optional).
- 3. Brief description of visual appearance (optional).
- Both 2 and 3 are desirable but not essential.
- I would like to see icon used only on the SVG element.
- 1. Where the SVG should be considered atomic and only represents one thing.
- 2. And no parts have meaning outside of being part of the visual representation.
- For parts of an SVG that represent something I prefer using "symbol" (aka shape). And I believe symbol should also atomic.
- I had originally been thinking that "icon" would apply equally to stand-alone icons and to icons within a more complex graphic or chart. However, I see Fred's point, so I've listed "symbol" separately.
- I think the argument would be that the essential information about an icon is what it represents rather than the details of its visual appearance. The latter may however be useful to know in some contexts, thus I would suggest including a brief description in DESC and a label designating the purpose of the icon in TITLE. Unfortunately, this would preclude providing help text usable as a tool tip in DESC.
- The most basic use case, is needing to know what an object is. The icon role would seem to satisfy this case.
- The rest is authoring practice. Knowing what an icon represents is definitely essential, and this could be accomplished with something like:
- <svg role="icon" aria-label="Delete">...</svg>
- I'm less sure that the use case for a description is strong enough. It would be good to gather some quantative data to work with if we can.
- I also have reservations about recommending <title> as an authoring mechanism to provide help.
- A scratch browser test this morning suggests that only Firefox renders <title> as a tooltip. Chrome, IE and Safari don't, and as a Webkit based browser I suspect Opera is unlikely to either.
- When it is rendered, <title> has the same UI as @title in HTML, so it comes with all the same accessibility/usability issues .
At the 29 May teleconference of the SVG Accessibility Task Force, we resolved that we wanted an "icon" role. Still to be determined is how icons and symbols are distinguished: as different roles, or as the same role in different contexts?
- An icon-like complex shape used to convey a simple meaning within a structured graphic
- The symbol itself would be presented as an atomic object; children are presentational
- Amelia's original proposal included that this could be the default role for <use>, so that authors would have to explicitly over-ride the role if they wanted the browser to include the cloned content in the accessibility tree.
- blue prints: electrical outlets, junction boxes, switches
- maps: features that are represented by a point at the map scale - church, (train, subway) station, mine, monument, benchmark, hazard to navigation
Questions and Comments
- Is it worth having a separate role, or can "icon" do double duty? Or call it "symbol" and use it for icons as well?
- I agree with Chaals that some explanation of Ameila's last point would be helpful:
- This could be the default role for <use>, so that authors would have to explicitly over-ride the role if they wanted the browser to include the cloned content in the accessibility tree.
- Not sure if this is suggesting that img would be the default role? If so, why wouldn't an object with a role of img be in the acc tree already? Also not sure what content is/would be cloned?
ABR: What to do with <use> is really a separate question. Didn't mean to distract from the main ideas.
- The symbol element should map to a symbol (role), not sure if any other element needs a symbol role.
At the 29 May teleconference of the SVG Accessibility Task Force, we resolved that we would not propose a "shape" role. The more generic symbol/graphical component roles should be sufficient. If the geometric shape of an element is important to its interpretation, authors should mention the shape in the title/description.
The discussion is maintained below for reference.
- A basic geometric shape.
- The main purpose of this role, as distinct from img or icon, is so that accessibility tools can communicate what type of shape it is. A new ARIA property would allow the author to convey the shape type separately from the label and description.
- Children are presentational.
- The fallback role would be img.
- This would be the default for all the basic SVG shapes if they met the criteria for inclusion in the accessibility tree.
- All the standard SVG shapes except path would have default shape-type descriptions that the browser should localize by default.
- You could also use the shape role on a group if that group represented a single graphical element (e.g., if it contained a basic shape plus its visible label, or a shape that has been duplicated and layered for graphical effect).
- Flow charts where the shape of nodes often conveys meaning, but you don't want to repeat that in the label, which should focus on the substantive information.
- To describe the components of a structured graphic when it is important that the user understands the geometric presentation of the information
Questions and Comments
- I'm not convinced that children should be presentational.
- Consider the shape "a triangle extended over an almost-square rectangle, with a small sqaure-topped vertical riser on one side". This is a common enough shape represented by a group. It may have two or four children whose shape is basically "a square, or almost-square", and one vertically-sligned rectangle. (typically the rectangle will be in the middle, anchored at the bottom of the parent shape, while the two squares will be on either side of it, floating toward the top of the rectangle section of the parent shape. There may also be a "collection of circles" or some "wavy lines" extending up from the vertical protrusion on the triangle that is the top of the parent shape.
- For those who gave up drawing mental pictures, I'm describing the way kids draw a house, as the first of a few examples that popped into my head.
- This is a good example. Note also that there are textbook geometry problems that depend on embedded shapes of just this kind.
- If the children of “shape” were presentational, the author would have to apply the “shape” role explicitly to all of the component shapes, a result which I would prefer to avoid. If there are many use cases in which the components of shapes are purely presentational, then obviously I would adjust my view, as we are here defining the default, which ought to be correct in a majority of actual cases.
- While we’re discussing examples, consider how we might represent a paradigmatic drawing of a right triangle. There is typically a small square symbol inside the triangle which, by convention, indicates a right-angle. Given the above mini-taxonomy, I would apply the “shape” role to the triangle and an “icon” role to the symbol with title “right angle” and possibly a description.
- Perhaps the central distinction we need here, at a high level, is that between a “structured graphic”, one which has semantically significant components, and “atomic graphic” which does not. The question about shape, then, is whether it should inherit from the “atomic” or “structured” role.
- I would envisage “atomic graphic” and “structured graphic” as concrete rather than abstract roles in the taxonomy, and I would allow other concrete roles to inherit from them.
- I think both symbol (shape) and icon should be "atomic" for AT.
- I prefer the term symbol rather than shape. Symbol is widely used in graphics and has meaning to author and user. Examples: map symbols, blue print symbols, math symbols.
- There seems to be a lot of confusing about the purpose of this role. I was really only thinking of it for simple shapes (circle, diamond, pentagon) where the actual geometric shape was important information. Complex graphics with meaningful sub-components would use the "complex graphic" role, whatever we decide to call it. Complex symbols where the visual sub-components are not as important would have a role of icon/symbol.
- Children are presentational because (in SVG, anyway, based on current API mappings) there will never be a child of <circle>, <rect>, etc. that is its own node in the accessibility tree.
icon role example
symbol role example
(TO DO: What would these roles look like in combination?)