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