Comments on SVG Accessibility Mappings -- Language and Scope

I've carefully reviewed Richard's draft spec on default SVG accessibility
mappings.  Below are general (and often nitpicky) comments on the language
and scope of content.  I'll send a separate email with detailed discussion
of the default and allowed semantics.

At this point, I'm mainly focused on outlining concerns; if others agree
that those concerns are valid, I would of course be happy to help come up
with alternatives!

Best,
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

General
-------

Should we remove the `2` from the title?  It is possible that this report
will be finalized before anything titled "SVG2" is ready.  Furthermore, we
want to encourage user agents and authors to start using the API as soon as
possible, irrespective of implementation status of other SVG2 features, and
to retroactively apply it to SVG1/1.1 content.

To make this document a stand-alone enhancement to SVG 1.1, perhaps we
could include the normative text from SVG2 that specifically adds the ARIA
1 attributes to all SVG elements.  Or would that be confusing the purpose
of the document?

More broadly, what *is* the purpose of the document?  Is it only for
implementers, or is it for authors as well?  Will we be creating a separate
document with guidance for authors?  (Possibly as a graphics-related
section of the main WAI-ARIA authoring practices note.)  Many of my
comments that follow relate to the fact that the language may be confusing
for authors; if there will be a parallel, author-focused document that is
less of an issue.

Abstract
--------

- Should have a clearer statement about the target audience (UA
implementers vs document authors).

- Should make it clearer that it extends/replaces the accessible name
computation for SVG elements.

- More generally, I would prefer to re-arrange to have the first sentence
or two stand alone with the information about why this is important, moving
the links to other documents farther down.

1.0 Introduction
----------------

- Not sure why the statement about showing/hiding GUI components is
relevant.  ATs need to access components that are always visible in a GUI,
too.

- There should be a paragraph about the fact that SVG 1 and 1.1 included
elements for accessibility purposes (e.g. `<title>` and `<desc>`), but that
to date there has been no formal guidance on how UAs should present this
information to ATs, or how to integrate with other languages and validators
that use the ARIA system.

- I don't like the "Unlike earlier versions of SVG" statement re DOM and
events.  It suggests that earlier versions of SVG didn't have a clear DOM,
when what you really mean is that SVG 2 updates the SVG DOM to DOM 3.

- The reference to ARIA 1.1 as "a planned W3C recommendation" should make
it clear that it is an update of an existing recommendation (ARIA 1).

1.1 Accessibility APIs
----------------------

- I think the distinction between "static" web pages and rich internet
applications is not as useful as the distinction between semantic markup
and custom web applications.  The paragraph that starts "In the case of
static Web pages" later discusses "UI elements that are known to be
interactive", but that's somewhat buried for a reader skimming through.

1.2 The Accessibility Tree and the DOM Tree
-------------------------------------------

no comments

2.0 Normative User Agent Implementation Requirements for SVG 2
--------------------------------------------------------------

This is all standard boilerplate; only comment is re the section title, and
whether we want to restrict this document to SVG 2 or just say "for SVG".

3.0 Important terms
-------------------

Accessibility Subtree::
Is an aria-owns relationship part of a subtree?

Hidden::
Should make it clear that an element can be hidden implicitly via CSS or
language semantics, not just by explicitly setting `aria-hidden`.

Live region::
This sentence does not make sense: "Since these asynchronous areas are
expected to update outside the user's area of focus, assistive technologies
such as screen readers have either been unaware of their existence or
unable to process them for the user."  Maybe replace "are expected to" with
"frequently"?  Or else keep "expected to" and change the second clause to a
forward-focused "ATs need to be made aware of the changes and how to
process them...".

Owned element/Owning element::
Should these definitions reference the accessibility tree/subtree
definitions (or vice versa)?

Role::
Should clarify that roles apply to objects in the accessibility tree /
elements in the markup.

Root WAI-ARIA node::
Do we really want to reference `<frameset>` as an example?

Target element::
Clean-up code formatting.

Valid IDREF::
I would change to "A reference to a target element in the same document
whose ID matches the IDREF value."  The current wording could be read as
implying that two elements should have matching IDs.

4. Supporting Keyboard Navigation
---------------------------------

If this document will be generalized to apply to all SVG, not just SVG2,
then there should be some content added here about keyboard navigation and
SVG 1.1

5. Mapping WAI-ARIA to Accessibility APIs
-----------------------------------------

For 5.1, do you really mean "this section must conform" (as in, please
ignore any content of this document that conflicts with the linked
reference), or do you mean "SVG user agents must conform", similar to the
following sections?

For 5.2, is there a benefit in referencing the SVG2 spec as the "host
language"?  Wouldn't it make more sense to reference section 5.4.2 of this
document, which defines the native markup semantics by mapping to roles?

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

I don't find the long list/table the most effective way to present this
information.  I think it would be clearer if the default semantics were
defined by grouping all SVG elements into categories, and then defining the
default and allowed roles for each category.  An alphabetical list of
elements could then be used to look up which category each element is in.

This would avoid repeating the same text about checking for accessible name
content again and again, and should make it easier to catch errors (like
ellipse not having the same instructions as other shapes, in the current
draft).

See separate email for suggested categories and comments on the mappings
themselves.

 5.6 Special Processing Requiring Additional Computation
 -------------------------------------------------------
 This section really needs to be expanded to be informative for authors.
Both authors and implementors should be able to look at a single document
and understand how `<title>` and `<desc>` interact with the corresponding
ARIA attributes; which take precedence, does one replace the other or are
they combined, and so on.

 I think we should also explicitly encourage authors to use `<title>` and
`<desc>` (host language semantics), with the caveat that `aria-label` or
`aria-labelledby` should be used instead of `<title>` if the tooltip value
doesn't make a good accessible name or vice versa.