RE: ARIA roles for graphics

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: 21 May 2015 03:44

When reviewing the accessibility API mappings, I was once again struck by how useless the repeated "group" role is.  I would really like to push forward with a basic set of graphics roles.

 

Agreed.

 

Yes, our long-term goal is to come up with a nuanced taxonomy for describing the semantic meaning of charts, maps, and so on.  But in the short term, can we decide on some roles for simple graphics, that we can present to the ARIA group for inclusion in ARIA 1.1?  And equally importantly, that we can use as the default ARIA roles in the SVG API mappings document.

 

<SNIPPED>

 

The following roles I think would cover most basic graphics.  In combination with proper use of other ARIA attributes (such as labelled by and flow to) they could greatly enhance the ability to describe infographics and labelled diagrams.

* graphic

* 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 either be group or region depending on how significant the graphic is.

 

Conceptually this makes sense, but I think it might be difficult to distinguish between an image and a graphic in a practical sense. Throwing some alternative name suggestions out there… “datachart”, “infographic”, “structuredimg”, or “compleximg”?

 

* figure

* A graphic that is also a complementary section of the document, and should be included in the table of contents.
* The fallback role would be complementary.

 

Would complementary content be included in a TOC? Looking at it from an HTML perspective, <figure> and <aside> (which maps to complementary) serve quite distinct purposes.

 

* icon

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

 

+1

 

* shape

* 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.  For example, in a flow chart, 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.
* 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).

 

 

+1 Although we’d definitely need the ARIA attribute to complement it – perhaps aria-shapetype or something.

If we can agree on a simple schema such as this, hopefully we can get it into ARIA 1.1 -- and into implementations -- while we are still working on the more complex charts taxonomy.

 

Yes, I think this would be a useful first step.

 

Léonie.