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

Thank you Amelia,

I checked the GitHub and currently only two issues are marked with Agenda+ tag:

https://github.com/w3c/svgwg/issues/291

https://github.com/w3c/svgwg/issues/269


The first one seem like the issue we should quickly resolve and the second one was discussed during last call. I expect we’ll find the time to discuss SVG-AAM and Graphics-AAM today as needed.

For the topic you’re proposing can you please file an issue and add agenda+ tag, so that we have all the topics in a single location? Thank you!

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com]
Sent: Friday, February 2, 2018 4:59 PM
To: www-svg <www-svg@w3.org>; SVG Working Group <public-svg-wg@w3.org>
Cc: Michael Cooper <cooper@w3.org>; Joanmarie Diggs <jdiggs@igalia.com>; Ian Pouncey <w3c@ipouncey.co.uk>
Subject: 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.