Re: SVG Accessibility API Mapping Spec: Significant edits

Thank you Amelia.

Addressing each bullet:

- We do need to keep them synchronized but I can look at how we might
reduce it. It is important that a user agent manufacturer be able to read
this spec. and get the gist.
- The issue with <desc> is it is not visible. Also, some platforms don't
yet support access to structured text e.g. Mac, iOS. Even if it is
structured, if structure is important then it should be visible to all
users. For that we have aria-describedby but even that is limited by
platforms that don't support description relationships.
- I need to look at dat viz. This may be sticky issue with user agents.
- tabindex on non rendered are ignored. They must not be exposed to AAPI
- Role mappings that use of a generic ARIA role: One does not exist but we
can create one. Most platforms expose the passed ARIA role. We could
default to "graphicalobject" but I thought we agreed these would be
symbols. I agree we should default to the new graphics roles.
- aria-busy is a global attribute so we can put it anywhere we need to. We
may wish to put something about aria-busy usage in this spec. or the ARIA
specification. I am not following how aria-pressed applies. aria-pressed
applies to toggle buttons typically as it reflects the pressed state.

Do you want me to edit what you have or create a branch off your branch? I
will take a look at what you have.



Rich Schwerdtfeger



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