Re: Comments on SVG Accessibility Mappings -- Default and Allowed Semantics from Richard Schwerdtfeger on 2015-01-21 (public-svg-a11y@w3.org from January 2015)

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Wed, 21 Jan 2015 13:37:09 -0600
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Cc: public-svg-a11y@w3.org
Message-ID: <OF320C66BF.CC8F3E41-ON86257DD4.00668FDA-86257DD4.006BC512@us.ibm.com>
Hi Amelia,

Thank you so much for the detailed review. It is much welcomed!

My response is below. As a general comment we did not fully addressed rich
text in the Core. We need to do that. I agree we need some sort of
"container" role for <text>. I could make it a "group" role for now but
that is a bit misused as I discuss below. In HTML you don't need a
container to really add text. You only need a <body> container. There is a
BIG discussion on this on tomorrow's ARIA call.

If we are really providing access to text we need a richer accessibility
API definition. You need to have access to text offsets, caret information
(if it is editable). Know where the line breaks are, etc. It is very
involved.  We do need to address it but not for the first public working
draft. We could do the grouping temporarily (previous paragraph).

Cheers,
Rich

Rich Schwerdtfeger

Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote on 01/19/2015
08:00:44 PM:

> From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
> To: public-svg-a11y@w3.org
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Date: 01/19/2015 08:01 PM
> Subject: 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

currently, we don't have default roles for things like ellipse or circle.
When we do our taxonomy here we should create a basic shapes section in our
SVG aria document and have the basic shapes in the mapping spec. default to
those when there is alternative text but no roles.


>   * Default depends on whether there is non-null content for
> accessible name and accessible description; if so, map to "group"
> otherwise map to "none".

yes. But we can change per above. The reason they map to null has to do
production of an accessibility tree. SVG content is persistent so we need
to not make accessible objects when they are not needed. I will talk about
Friday.

>   * Any role is allowed.
Well, almost. there are exceptions. See Audio and Video


>   * 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"?
>
That is not up to the AT. That is up to us to define. I mentioned that on
the last call. I will discuss that Friday. ... but very good point.


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

OK. let's discuss image. Regarding audio and video there are special roles
for



> - Text elements:
>   * `<text>`, `<tspan>`, `<textPath>`, and `<tref>` (if its not
> being excluded as deprecated)

I am not following but text content is used in the accessible name
computation. One to-do we have to have in core is address general text
mapping as there are accessibility apis that have to do with access to text
where position, caret location for editable text, highlighting, and other
pieces need to be addressed. We need to tackle this in the Core
Accessibility API mapping SVG and HTML. That won't make this first working
draft.


separate from just access to readonly text <text> plays into name
computation. If you look at the ARIA spec. you will see (using checkbox as
an example):

http://www.w3.org/TR/wai-aria-1.1/#checkbox

that if a name is not supplied by the author (<title>, aria-label,
aria-labelledby, the text content of that element is used to compute the
accessible name. So, in svg an author could but text content inside a
circle whose role was checkbox and grab the text to compute the name.


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

See previous paragraph. I can put a note in the spec., if you like, that
this is something we need to address but we have to coordinate with the
Core mapping spec. as well as the HTML spec. For example, in HTML you don't
need to have a <p> to write text. We also don't have a notion of a
paragraph in SVG.


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

This is a bigger issue that should also involve CSS. We do have a math role
in ARIA.

>   * Unfortunately, none of these text-level semantics can currently
> be defined via ARIA.

No it is not. See above.

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

Um. I can see where we want text lumped into some container. I am not sure
"group" is the right answer. We are looking at addressing this issue with
ARIA and the other other accessibility api mapping specs. So, all the
things we have that map to "group" may map to another type of container. I
agree in principle that we need some sort of container to separate text
"chunks".


We could discuss have <text> map to group for this call but it will need to
change. We are discussing having the aria role of "section" becoming a
concrete vs. abstract role that would be a better fit for many of these.
Groups are used to do things like associate a group of related checkboxes.

>   * 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!
>
True. The anchor tag can take any role in HTML.


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

yes. If intentionally grouped something with <g> then there was author
intent. There is a big reason for not defaulting other things to group and
that has to do with memory and the accessibility tree. semantics are about
author intent. If you have a <circle> it is just a circle. It does not mean
it is a grouping of any semantically important information. However,
if we create new roles for circle then I would default to that.


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

Ok. let's discuss how we approach that with the author.

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


Let's discuss this before we go to pub.

>   * 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

That is an easy change however svg working group people felt different. I
would agree with you.

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

That is not an issue. This only means that defs is not mapped. Making a
role of none has no impact on non-related structural child content.

Sounds like we need to discuss <use> in more detail.



>   * 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!)

If a role is none there is nothing to map. Perhaps that needs to be made
clearer. If there is no role there is no accessible object. We need to
discuss this more.
If you want these to map we need to know what they are mapped to. Would it
be group?

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

OK. Let's discuss more. This may be something for the next working draft.


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

Title and desc are used in the accessible name and description computation.

>   * 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?

Hmm. we could take the first desecendant found that was not a descendant of
another element. Would that be better?



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

Certainly we need authors to make correct use of the aria states and
properties. metadata is not really intuitive here.
Received on Wednesday, 21 January 2015 19:37:45 UTC