SVG-A11y Task Force: Plans for 2017

Hello all,

I wanted to update everyone who is interested in this group's work about
the plans & priorities for this year (at least as I see them).

*Short version:* Please reply to this thread if you expect to, or would
like to, be active in the group this year. Let us know in particular:

   - Are you available to participate in teleconferences? If so, how often
   & what times of day?
   - Are you available to work on the test suites? How much time can you
   commit? How much familiarity do you have with the rest of the ARIA test
   suite?
   - Are you available to work on specs and authoring guides? How much time
   can you commit?
   - Are you involved in developing software implementations (web browser
   or assistive tech) of graphics accessibility? What is your role?


Please also reply if you want to suggest different priorities, & especially
if you are able to take responsibility for moving forward on any of the
projects.  Also, please correct me if I've said anything incorrect on your
behalf.

*Some background:*

   - Rich Schwerdtfeger retired from IBM at the end of 2016.  He is
   continuing on as co-chair of the ARIA working group, as a representative of
   Knowbility, but has said that he'd like to reduce the number of other
   meetings he's committed to.

   - Fred Esch has not been with IBM for a few months now.  He is
   continuing with the W3C / ARIA working group and this task force as an
   Invited Expert.  However, he is not able to participate in teleconferences
   during the workday. And since evening calls in US Eastern are very late
   night in Europe, we are unlikely to find a good time when he could chair
   meetings.

   - Doug Schepers is no longer with W3C, as of the end of 2016.  He wants
   to stay involved with SVG & accessibility standards work in some capacity,
   but is not sure exactly what that will look like in 2017.

   - The SVG Working Group has had difficulty getting enough active
   involvement from W3C members over the past year.  It is currently on a
   charter extension until the end of January, with a proposal for a
   stripped-down new charter that would last until the end of October 2017.
   The new charter has a much-reduced scope [1].  All the specifications that
   were shared between SVG and CSS will become the sole responsibility of the
   CSS WG, and all next-level SVG specifications have been put on hold.

   However, the SVG Accessibility specifications are currently still
   included in the draft SVG WG charter as shared deliverables between the SVG
   and ARIA working groups.

*The current plan:*

I have said that I can chair teleconferences for the SVG-Accessibility Task
Force in 2017.  But I don't have a lot of extra time to devote to work
beyond that.  I can probably also make edits to the existing specs, as
required, and coordinate with Michael Cooper (the ARIA working group's W3C
staff contact) to get them published.

Teleconferences will probably be either every-other-week or once a month.
It depends on how many other people are involved in the group, how many of
us are available for teleconferences, and how much work is getting done
between (and during) calls.  Maybe it will be more effective to switch to a
mostly-asynchronous process, using the mailing list and GitHub issues.

There are two top priorities for work: Finalizing the existing
specifications, and creating a matching test suite.

A longer-term goal is to look into ARIA roles/attributes for describing
more complex data graphics, but that is on hold for now.  The focus is on
getting web browsers and common assistive technologies to a respectable
minimum standard of accessibility for SVG and other graphical documents.

*Status of the Specifications:*

There are three draft W3C specs that are the responsibility of this task
force. All are currently at "Working Draft" status:


   1. SVG Accessibility API Mappings <https://www.w3.org/TR/svg-aam-1.0/>
   Guidelines for how SVG core features should be exposed (by web browsers)
   to the operating system Accessibility APIs.
      - The last Working Draft updated it to use the new ARIA graphics
      roles as defaults for many elements (previous drafts had mapped
everything
      graphic-specific to ARIA "group" role, because nothing else fit).
      - The Editor's Draft includes updates not in the WD, mostly related
      to <use> element (the new edits require the <use> shadow DOM to be fully
      exposed). We should probably publish an updated Working Draft, especially
      since no additional work is happening right now.
      - Other issues are still open.  We need more feedback from
      implementers about the best way to deal with unique SVG features such as
      view, and how to deal with shadow DOM more effectively.
      - There's an initial test suite covering many aspects of this spec,
      but it needs to be updated & completed.

      2. WAI-ARIA Graphics Module <https://www.w3.org/TR/graphics-aria-1.0/>
   New ARIA roles for describing structured graphics. The roles are used in
   the SVG mappings as defaults for some elements, but could also be used
   directly in the role attribute. This spec describes the roles semantically,
   but doesn't set any testable requirements for how they should be exposed.
      - I don't *expect* this spec to need further edits, so it could be
      eligible for "Candidate Rec" status as-is, but it wouldn't be
able to move
      beyond that until the Graphics Mappings spec is final & tested.

      3. Graphics Accessibility API Mappings
   <https://www.w3.org/TR/graphics-aam-1.0/>
   Rules for how the new ARIA graphics roles should be exposed by browsers
   to the different operating system Accessibility APIs.
      - Needs more feedback from implementers familiar with those APIs.
      - In particular, needs feedback from people working on diverse
      assistive tech about whether the proposed ways of exposing the roles are
      sufficient to convey the relevant semantic distinctions to end users.
      - Needs to be integrated into the SVG test suite, since these roles
      are defaults for some SVG elements, and should also have a separate test
      suite to ensure the roles are correctly exposed when used explicitly,
      including on SVG elements, HTML elements (for "CSS-only"
graphics) and HTML
      <canvas> sub-DOM.


*Status of the Test Suite:*

Most of the work on the test suite so far has been done by Fred Esch, with
extensive feedback from Joanmarie Diggs.  See Test Assertions with Tables,
on the task force wiki
<https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Assertions_with_Tables>
.

The test structure is coordinated with the core ARIA test suite.  Test
files are short SVG snippets, expected results are defined in terms of what
should be exposed in the operating system Accessibility API.

TODOs include

   - Double-check & possibly add tests for things that shouldn't be exposed
   - Double-check & maybe add new tests for name & description
   - Update tests for roles to match latest SVG AAM and Graphics AAM specs
   - Add tests for SVG <use> shadow DOM
   - Add tests for SVG <view>
   - Add tests for declarative animation
   - Probably add some more tests for edge cases / contradictions (e.g.,
   invalid roles, invalid aria-hidden)
   - Double-check & complete the Language-dependent tests
   <https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Assertions/Language_Tables>,
   and figure out best ways to integrate them in the testing harness.


There is also ongoing work to improve the core SVG test suite.  However,
that work is using different testing harnesses, because it is only testing
what's happening in the DOM and on the screen, not in the accessibility
tree.  From an accessibility perspective, the most important aspect of that
is the keyboard focus section.  It may be appropriate to add some
"focusability"-related tests to the SVG-A11y test suite, too.

*Potential complications:*

If the SVG WG new charter does not get approved (and the group dissolves
for now), this task force would need to be re-assessed.  I believe it would
still be useful to have a graphics-focused sub-group of the ARIA WG, but it
depends on how many people are involved, & whether they are all also
actively involved with Core ARIA WG.  Either way, formal responsibility for
the SVG Accessibility specifications would need to be taken over by the
ARIA WG.


[1]: Draft SVG WG charter for 2017, https://w3c.github.io/charter-
drafts/svg-2016.html

Received on Wednesday, 4 January 2017 23:25:35 UTC