SVG Accessibility API Mapping Spec: Significant edits

As promised, I've spent the last few days working through the SVG
Accessibility API Mapping Spec, trying to integrate all the issues we've
previously discussed.

The edited draft can be seen via rawGit at
https://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html

I've tried to be fairly detailed in my commit messages, so you should be
able to review the main changes from comparing github branches [2].  The
biggest change is that I've created sections for excluding / including
elements in the accessibility tree.  I then reference these sections to
simplify the role mapping table, with text along the lines of "img role
mapping if the element meets the criteria for Including Elements in the
Accessibility Tree; otherwise, not mapped".

There are a number of issues still to be resolved, which are indicated
using editor's notes:

   - Sections 1.1 and 1.2 are almost-exact copies from the Core AAM spec;
   I'm not sure we need them here, but if so they will need to be kept
   synchronized.

   - I am concerned that the approach we have taken for dealing with
   metadata elements (particularly <desc>) eliminates the possibility of
   having structured alternative text content that the user can navigate.  The
   description generated via the text alternative computation is plain text
   only.  In contrast, the SVG <desc> is supposed to support structured
   content, including content from HTML or other namespaces.  Taylor Hunt
   proposed an interesting use case of having a short description with links
   to longer descriptions [3] but there are other use cases, like embedding a
   data table or ordered list as alternative content.

   - I have followed the suggestion of the Core AAM spec and recommended
   that invisible elements should be excluded from the accessibility tree.
   However, I've added an exception for invisible elements that can receive
   user input events, since this is a common practice in data viz: invisible
   elements provide large hit regions for small data points.  (A
   good-accessibility practice we should encourage!)  The guidance ends up
   rather convoluted and will probably be difficult to implement.  Suggestions
   for a better approach are very welcome.

   - We don't have clear rules yet about what should happen if the author
   applies tabIndex to a non-rendered element.  It should probably be ignored,
   but we need to say so somewhere, maybe in the main SVG spec.

   - The role mappings still use the generic ARIA group role in many
   cases.  However, platform APIs may have better roles (e.g., a graphics role
   that is allowed to have child content, a text paragraph role).  We should
   be more specific about these mappings.  Whatever mappings we suggest should
   also be coordinated with default mappings for the new ARIA graphics roles.

   - I've added a brief note on declarative animation, as it relates to
   hiding/showing elements.  However, I would like to also make the WAI-ARIA
   states and properties animatable, so that you could set `aria-busy` or
   `aria-pressed`, etc., for the duration of an animation, and update the
   label or description.  This is another change that belongs in SVG 2, but I
   wanted to keep a note about it here, so it can be updated when required.

   - Finally, there are a few other editor's notes regarding
   cross-references and such.  And I'm sure there's lots of standard spec
   formatting that I'm overlooking.


If people want to tweak the draft before over-writing the current editor's
draft, someone would need to create a branch on the main ARIA repository.
Then I can make a pull request against it.  Or if I get a couple "looks
good to me" votes, I can just make the pull request for it to go into
master.

Best,
Amelia

[1]: https://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html
[2]: https://github.com/w3c/aria/compare/master...AmeliaBR:svg-aam
[3]: https://lists.w3.org/Archives/Public/public-svg-a11y/2015Jun/0008.html