Re: Comments on SVG Accessibility Mappings -- Default and Allowed Semantics

I modified the SVG2 spec and the mapping spec. map to a role of "group" for
the native host language semantics with a note indicating that more work is
required here for text interface mapping . This was done for <text>,
<tspan>, and <textPath>. The SVG2 spec. does not have the note but has the
default group mappings for these.


Rich Schwerdtfeger



From:	Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To:	public-svg-a11y@w3.org
Date:	01/23/2015 10:16 AM
Subject:	Re: Comments on SVG Accessibility Mappings -- Default and
            Allowed Semantics



One follow-up from the call this morning.

Richard mentioned that elements with "group" role do NOT take their
accessible name from their contents, which was something I hadn't realized.

It makes sense for the normal use of "group" (as a collection of related
list items, table rows, and so on, each of which has their own name).  It
also doesn't affect using "group" as the default role (until more specific
options are available) for shapes, since (a) the only content that should
contribute to the name is <title>, which has a separate rule for it and (b)
if the shape doesn't have specific accessibility content, it won't be
included in the accessibility tree at all, so there won't be any name to
compute.

However, this may pose a problem for `<text>`.  As I mentioned previously,
we want all <text> elements to have some sort of default "chunking" role to
distinguish separate elements.  At the same time, it could get confusing if
all these chunks have the same non-informative name ("group"), and the user
had to specifically select them to discover the actual text value.  This
would happen with default role of "group" if the author has used `<text>`
with no accessibility attributes or <title>/<desc> child content (i.e.,
most of the time).

As discussed, the plan is to define new ARIA roles.  In the meantime, would
this behavior be okay?

The only alternative I could think of was to use "heading" as the default
role for SVG text?  That would probably be okay for most stand-alone SVG,
but with inline SVG it would  clutter up the main table of contents.
Adding a default role of "article" for SVG when it is a direct child of
HTML elements would encapsulate the unordered heading elements, but would
be overkill for small inline SVG icons.

In other words, "group" is still the best option of the existing ARIA
roles.  I just wanted to point out the impact on the name calculation.

--Amelia BR

On 19 January 2015 at 19:00, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:
  - 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).