Agenda+ (SVG WG): Publish an updated working draft of the SVG Accessibility API Mappings spec

I would like to set aside some time at the Feb 5 or 12 SVG working group
teleconferences to discuss the SVG-AAM spec (https://w3c.github.io/svg-aam/).
Detailed summary of the Background and Next Steps follows.

~Amelia


*Background:*

The SVG-AAM spec describes how SVG elements and behavior should map to the
ARIA model and specifically to the operating system APIs that are used by
assistive technology like screen readers and voice control interfaces.

The last published update to the SVG-AAM was in September 2016:
https://www.w3.org/TR/svg-aam-1.0/

Even at that point, I had already made significant changes to the Editor's
Draft (https://w3c.github.io/svg-aam/), which can be grouped into 2
categories:

   - Changes to how use elements were exposed, to reflect the SVG 2 changes
   towards a shadow DOM model
   - Changes to the default ARIA roles of SVG elements, to use the new
   Graphics ARIA roles (https://w3c.github.io/graphics-aria/) instead of
   describing every SVG container element as a generic "group" and every
   graphical shape as a generic "image".

Re-publishing the SVG-AAM with these changes was dependent on work on the
Graphics-AAM (https://w3c.github.io/graphics-aam/), which defines how the
new Graphics ARIA roles are actually exposed in the operating system APIs.

Of course, activity on all of the above was delayed by all the issues with
SVG WG rechartering and dissolution of the SVG Accessibility Task Force.
This was compounded by my two co-editors on the ARIA side changing jobs &
eventually ending their participation in W3C activities.

In the new SVG working group charter, SVG WG has sole responsibility for
the SVG-AAM, while ARIA WG has responsibility for Graphics ARIA and
Graphics AAM.

New working drafts of Graphics ARIA and Graphics AAM were published this
week (and are probably close to last-call stage).  Thanks to Joanie and
Michael at the ARIA working group for pushing that through.  We'd now like
the SVG-AAM to be updated to match.


*Next Steps:*

The Editor's Draft needs some cleanup to reflect changes in other specs
over the past year and a half. I'd like to get that done in the next couple
weeks, prior to re-publication. I can do some, and Ian Pouncey (of the
Paciello Group) has offered to join me as a co-editor, so hopefully we can
work out the clerical details between us.

That said: this would still be an interim working draft.

There are still open issues in the SVG-AAM (described as Editor's Notes in
the draft), specifically with respect to views, use elements, and
title/desc elements, none of which have direct equivalents in HTML.
Feedback on these points would be appreciated. Browser implementers could
start by looking at what they currently do & any complaints they've
received from users about that behavior.

The SVG-AAM now resides in its own repository, so please file any issues
here: https://github.com/w3c/svg-aam/issues

The main work remaining, however, is a full test suite (Where have we heard
that before? Oh, yes, for SVG 2, too!).

The SVG-AAM tests would use the structure in place for other ARIA specs,
since they need to test what is actually exposed in the Accessibility APIs,
not only what's in the DOM and on screen.  For an idea of what that looks
like, you can look at the tests for the Graphics ARIA & AAM:

   - Test folder in WPT:
   https://github.com/w3c/web-platform-tests/tree/master/graphics-aam
   - Summary of test results:
   http://w3c.github.io/test-results/graphics-aam/

The SVG-AAM tests would need to be much more extensive, covering all SVG
elements (to be sure the default roles are correctly mapped, and role
restrictions are respected), plus accessible name and descriptions, and
also correct handling of error cases & other special behavior like use
elements.

There were some preliminary tests created based on the previous SVG-AAM
draft; these all need to be updated, and more tests are required.  With
tests, we can hopefully work more effectively with implementers to get SVG
accessibility to a consistent level, and to come to decisions about the
remaining spec issues.