Comments on SVG Accessibility Mappings -- Default and Allowed Semantics

Below are my concerns and suggestions regarding the role mapping part of
the draft spec.  A separate email provided general comments on the rest of
the text.

-- Amelia BR

_______________________________________________

Comments on
SVG2 Accessibility API Mappings
===============================
W3C Editor's Draft 16 January 2015

http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

5.4 Role mapping
----------------

I find it easier to discuss default semantics by grouping all elements into
categories that have the same or similar default and allowed roles:

- Shapes:
  * All the basic shapes
  * Default depends on whether there is non-null content for accessible
name and accessible description; if so, map to "group" otherwise map to
"none".
  * Any role is allowed.
  * Should there be text suggesting that, where an accessible name exists,
the API or AT that directly describes the element to the user (e.g., a
screen reader), should use a more meaningful description of the element
(e.g., "circle", "graphic", or "shape") as opposed to using "group"?

- Replaced content:
  * `<image>`, `<audio>`, `<video>`, `<canvas>`, `<iframe>`
  * Default role for `<image>` is "img", default for others is "group"
  * If the API supports specific audio/video roles, map to those instead
  * I DO NOT agree that `<image>` should have no other role allowed; an SVG
image could be used as a widget component (e.g., image button), and we must
allow that to be properly annotated.

- Text elements:
  * `<text>`, `<tspan>`, `<textPath>`, and `<tref>` (if its not being
excluded as deprecated)
  * As I've commented previously, I think there needs to be some role that
identifies each `<text>` as a distinct unit, equivalent to paragraphs in a
document.
  * For the others, they would be purely presentational by default, but it
would be nice if authors could indicate semantic meaning for style changes
(e.g., emphasis, math, code, small print, etc.).
  * Unfortunately, none of these text-level semantics can currently be
defined via ARIA.
  * My recommendation is therefore to have `<text>` map to "group" by
default, so that separate text elements aren't all concatenated together as
an indistinguishable blob.  API-specific instructions could advise mapping
to a paragraph-equivalent role where possible.
  * The other text elements would have a default role of none/presentation
(i.e., the text content is presented as part of the parent element in the
accessibility tree) unless the accessible name or accessible description
includes content *other* than the plain text content of the element (i.e.,
`<title>` or `<desc>` child content, or ARIA label/description attributes).

- The `<a>` element:
  * Default role is "link", any role allowed.
  * Allowing any role is important, since currently `<a>` is the only SVG
element that gets keyboard focus in most browsers; an accessibility-minded
author will use it for pretty much any widget component!

- Container elements:
  * `<svg>`, `<g>`, `<symbol>`
  * Default should be `group` for all of these; I don't see a reason to
have different defaults for `<g>` vs `<svg>`.  Even if authors haven't
included an accessible name for the group, there is probably a reason they
used grouping.
  * Note that `<symbol>` would not normally be directly exposed through the
accessibility tree (since it is never directly rendered); it could only be
exposed through a `<use>` element.

- The `<use>` element:
  * There are two approaches for dealing with `<use>`.  The current draft
treats `<use>` as a single graphical element, similar to any shape
element.  That's one option, which I think reflects how most UAs currently
treat the element for accessibility purposes.
  * I would recommend, however, that all `<use>` elements get an implicit
`aria-owns` attribute pointing to a clone of the re-used graphical
element's accessibility subtree.  That way, authors would only have to
markup the `<symbol>` or other re-used content once, and the labels or
descriptions would be propogated every time that symbol is used.  I suspect
this is how Firefox currently works, since they implement `<use>` elements
as full clones, but I haven't tested it myself.
  * Authoring guidelines could still encourage the use of ARIA attributes
or `<title>`/`<desc>` child content directly on the `<use>` element, for
backwards compatibility.  Unfortunately, we cannot advise authors to
explicitly use `aria-owns`, since each element can only be "owned" by one
other.
  * One complication: `<use>` elements can reference content from a
separate document, versus ARIA generally is restricted to a single file.
However, ARIA already allows `<iframe>` or `<object>` content to be
included as a separate accessibility sub-tree, and this feature can
probably be adapted for `<use>`.

- Graphical effects:
  * This would include filter elements, gradient elements, animation
elements, `<clipPath>`, `<mask>`, and so on.  These elements do not
represent a single perceivable object, and therefore should not be included
in the accessibility tree.  Would also include `<defs>`.  However, child
content of `<defs>` might have roles, depending on how we decide to handle
`<use>`.
  * Default role none/presentation, no role may be applied.
  * However, it should be clear that authors are still allowed to give
these elements *other* accessibility attributes and child content, in order
to reference it through another element's `aria-labelledby` or
`aria-describedby` properties.  For example, if colored gradients (or
`<solidColor>` elements) are used to categorize content on a map or chart,
the author could add `<desc>` elements to each gradient, explaining its
semantic meaning.  Then, whenever a shape is set to use that gradient as a
fill, the author could also set it to point to that element as
`aria-describedby`.   Similarly, when an animation is triggered, that
animation's label or description could be added to the description of the
target element.  (Note: might need to clarify the accessible
name/description computation to ensure that this works!)

- The `view` element:
  * This needs special treatment because while a `<view>` isn't directly
perceivable and doesn't have any child content (except optional
`<title>`/`<desc>`), a view (a) is often the target of links, (b) controls
which other graphics are visible to the user, and (c) may be formally
associated with the specific elements that it zooms in on, by using the
`viewTarget` attribute.
  * I don't think we can do much with the implicit targetting created by a
view (except to advise authors to include `<title>`/`<desc>` to label the
view).  For `viewTarget`, however, there should be some automatic
association; maybe treat `viewTarget` IDREFs as being equivalent to both
`aria-labelledby` and `aria-describedby` if those attributes aren't
explicitly provided?
  * Default role would be "group" if any accessibility content *or*
`viewTarget` is provided, none/presentation otherwise.
  * I don't know if we should allow other roles (e.g., widget roles),
particularly on a view without accessibility content, given that a view
doesn't correspond directly to any perceivable content.

- Descriptive elements:
  * `<title>`, `<desc>`, and `<metadata>`
  * The `<title>` and `<desc>` are treated as descriptors of their parent
element, they are not represented in the accessibility tree themselves;
default role of none/presentation, no other role may be applied.
  * What to do about the document-level `<title>` and `<desc>` (direct
child of the document element or of the first `<defs>`)?  Is the above
sufficient?
  * The `<metadata>` element is a little more complicated.  It isn't
displayed content, so it shouldn't be part of the accessibility tree.
However, the SVG specs allow an author to use a `<metadata>` block to
provide the accessible content of an SVG (e.g., an HTML table or XML data
tree that contains the equivalent content for an SVG data visualization).
I suppose that the solution is to advise authors to make correct use of
`aria-describedby` or other explicit associations if they are using
`<metadata>` to store alternative content.