Re: ARIA roles for graphics

I don't see a problem with adding mappings for 1.1. But I would only want
to add mappings that we would not want to remove or replace later. I like
icon, but don't know if I would want to keep the rest in 2.0.  We are being
told that any roles we create in a graphics extension must extend something
in core ARIA. I am not sure I agree with that. But I would like us to build
a usable taxonomy rather than address annoyances that result from a mapping
to existing ARIA.

We can talk about this tomorrow.
                                                              
                                                              
                    Regards,                     Fred         
                                                              
                   Fred Esch                                  
       Accessibility, Watson Innovations                      
    AARB Complex Visualization Working Group                  
                     Chair                                    
        W3C SVG Accessibility Task Force                      
                   IBM Watson                                 
                                                              
                                                              






From:	Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To:	public-svg-a11y@w3.org
Date:	05/20/2015 10:44 PM
Subject:	ARIA roles for graphics



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.

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.

Now, I know that adding new ARIA roles does not necessarily mean new API
mappings -- but it gives a nudge in the right direction to the people
behind the APIs.  And, since the complete role string is available to
accessibility tools even when it isn't mapped, it does make a little extra
information available if anyone wants to use it.

To recap the roles currently available for graphics, and their limitations:
      img
            Should be used only when this element and all child content
            forms a single image.
            Currently used for everything from simple icons to photographs
            to complex charts and maps (although hopefully not SVG charts
            and maps).
            Child content (if not used for the name/description) is assumed
            presentational and ignored.
            Therefore, img is not useful for structured graphics with
            meaningful parts.

      complementary, region, article
            Possible choices for labelling a figure (as a whole) if you
            want the component parts to still be accessible.
            Do not convey the idea that the content is graphical.

      text (new in ARIA 1.1)
            Complex content that should be treated as plain text with a
            value equal to the accessible name.
            Good if the graphic directly represents text, or can be
            replaced with a few words of text without loss of meaning, but
            not useful for other cases.

      group
            Conveys a structure, without specifying what it is or giving it
            any great importance.
            Doesn't have any semantic meaning beyond that.
            Is nonetheless what we've been using as the default mapping
            because it is the only role that doesn't convey incorrect
            semantics.
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.

      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.

      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.

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

Best,
Amelia BR