SVG WG review of SVG accessibility specifications

A reminder that there are two specifications that the  SVG Accessibility
Task Force is hoping to publish in the coming weeks.  One is an updated
working draft, the other a first draft:

>
>    - *The SVG Accessibility API Mapping specification* (aka SVG-AAM),
>    https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html.
>    This would define how user agents should interpret SVG content when
>    creating an accessible representation of a document.  It includes, for
>    example, the default ARIA roles for different elements, and how title and
>    desc should be used to generate accessible names and descriptions.  This is
>    a significant update from the working draft published last February,
>    although there are a number of outstanding issues that will not be resolved
>    in this publication round.
>
>    - *The ARIA Graphics Module*,
>    http://rawgit.com/w3c/aria/master/aria/graphics.html.
>    This defines new ARIA roles that would form the foundation of a
>    description of structured graphics, such as diagrams.  The img role from
>    ARIA 1 is not sufficient for complex SVG, because it assumes that an image
>    has a single text description, and no meaningful child content.  The new
>    roles would allow graphical objects to contain other objects with their own
>    descriptions, and possibly with interactive components.  This document
>    would then form the foundation for a future, more complex role model that
>    could describe the semantics of complex charts and maps.  This would be a
>    first pass working draft.
>
> I (and hopefully Doug and maybe Rich) will be available to discuss the
main issues on the teleconference this week.  However, comments and
questions by email are of course welcome as well.  After that we'll
probably ask for a resolution via email responses (or at least, via an
absence of email objections within a reasonable time frame!).

I've copied below a summary of the outstanding issues for SVG-AAM (which I
sent to the SVG accessiblity task force list last week).  The task force is
doing our final review of the ARIA Graphics module this week, but I think
it's less controversial.

Best,
Amelia

___________________________________________

SVG-AAM Status

Remaining things to do before publication:

   1. *valid URL for editor's drafts:* Sort out the process for creating
   regular snapshots of the Editor's Draft in Github pages
(w3c.github.io domain),
   and update the Editor's Draft URL accordingly (it currently points to
   rawGit, which provides an up to date reflection of the document, but is not
   intended for wide use).

   2. *admin tidying*: Update dates and other status of document text.

   3. *name and description edits:* If possible, coordinate with the
   editors of the Accessible Name spec about refactoring the name &
   description algorithm to improve readability, and update our text in
   response.  I'll start working on a proposal this afternoon, but I'm not
   sure whether this will happen in the next few weeks.  If not, we may wish
   to add an Editor's note.

In addition, the following outstanding issues are recorded in Editor's
notes, and won't be addressed for this publication round:

   1. *hidden elements:* Coordinate with the editors of the CORE-AAM spec
   regarding the definition of 'hidden' elements.  See the short note at
   the end of Section 3 (Important Terms)
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote1> and
   in more detail in the second Editor's Note at the end of Section 5.1.1
   (Excluding Elements)
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote3>.

   2. *complex desc content:* Explore whether there should be other ways to
   make <desc> content directly browsable in a way that exposes structured
   child content.  See the first note at the end of Section 5.1.1
   (Excluding Elements)
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote2> and
   also the short note at the end of Section 10.3 (Relations)
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote8>.

   3. *use elements:* Determine whether a more complex representation of
   the re-used content is required.  If so, determine how to represent it and
   what special computation is required.  If not, consider whether the name
   and description proposal is sufficient.  Seethe detailed note after the
   use element in the mapping table
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote6>,
   and also the note at the end of Section 10.1 (Name and Description)
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote7>.

   4. *graphics roles:* Update some of the default mappings to use new ARIA
   graphics roles, once we have appropriate platform API mappings for those
   roles.  Also, coordinate with the main ARIA team regarding getting better
   roles for structured text (e.g., a paragraph role).  See various notes and
   editor's notes within the role mapping table
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#mapping_role_table>
   .

   5. *SVG views:* Determine whether the proposal for SVG views is
   sufficient, and coordinate with the SVG WG regarding viewTarget.  See the
   note at the end of Section 10.5 (SVG Views)
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote9>.

   6. *Animation and ARIA:* Coordinate with the SVG WG regarding whether
   ARIA attributes are modifiable with declarative animation.  See the note
   at the end of Section 10.6 (Declarative Animation)
   <http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote10>.
   I've delayed following up on this because of the controversy over whether
   animation elements should be deprecated, but that seems to have stabilized,
   so I should look into it again.

(P.S. Links are to my branch on rawgit, and if you're reading this mail in
the archives long after it is written, they will likely no longer go to the
correct points in the document, if they work at all.)