Re: SVG Accessibility API Mappings

Hi Fred,

I fixed the bad links for including elements in the accessibility tree.

We can change the default mappings but we need to put them in the spec and
we need the roles in an aria graphics module for circle, ellipse, etc.

Rich


Rich Schwerdtfeger



From:	Fred Esch/Arlington/IBM@IBMUS
To:	"Amelia Bellamy-Royds" <amelia.bellamy.royds@gmail.com>,
            <public-svg-a11y@w3.org>
Date:	09/15/2015 02:23 PM
Subject:	SVG Accessibility API Mappings



Amelia,

I looked at the SVG Accessibility API Mappings and have a few thoughts.

I noticed that the Including Elements in The Accessibility Tree link did
not work

Section 5.1.1 Excluding Elements from the Accessibility Tree.
User agents MUST NOT include the elements from the SVG namespace in the
accessibility tree:
needs to add -
children of elements with role graphics-symbol

Section 5.4.2 SVG Element Mapping Table

I think the shape elements (circle, ellipse, line, path, polygon, polyline,
rect) should map to graphics-symbol instead of img when eligible to be
included

original
img role mapping if the element meets the criteria for Including Elements
in the Accessibility Tree; otherwise, not mapped
preferred
graphics-symbol role mapping if the element meets the criteria for
Including Elements in the Accessibility Tree; otherwise, not mapped


canvas - default map to img instead of group? I don't know whether any
default content can be passed from the canvas and be included in the
accessibility tree, if not img might be a better role than group.


iframe not mapped by default,
allowed roles should include application, figure, graphics-doc,
graphics-object, img

svg - should consider graphics-doc as default role

text - default role text
textPath - default role text
tspan - wouldn't tspan be included in text and not need its own mapping?

use - default role graphics-symbol


Section 5.6.1 Name and Description

In the name calculation - if the element does not have aria-labeledby,
aria-label or a title. Then I like using the role and aria-gtype separated
by a space for the accessible name, so eventually we could get name like
"axis y" without the author having a title, aria-label or aria-labeledby.

Section 5.6.2 Widget Values
Widget values for elements should be exposed whenever the element is
included in the accessibility tree (it shouldn't need a role application to
expose the attributes).

Section 5.6.4 Group Position
We will need special rules for group position. I think elements with the
same semantic parent and same role/aria-gtype should be in the same feature
and make a single set. I think aria-level within a chart feature is
something we should discuss. Potential chart situations where level could
be appropriate are in clusters, stacks, faceted (paneled) charts and charts
with hierarchical layouts - hierarchical heatmaps, org charts, trees and
possibly graphics where zoom increases detail (that is if zooming makes a
it appear to media queries that the display size changed).
                                                            
                  Regards,                   Fred           
                                                            
                  Fred Esch                                 
    Accessibility Focal, Watson Solutions                   
  AARB Complex Visualization Working Group                  
                    Chair                                   
      W3C SVG Accessibility Task Force                      
                 IBM Watson