Re: SVG 1.1 default implicit ARIA semantics

Amelia,

A new task force has been established to produce graphics semantics and we
will be developing platform accessibility API Mappings. We have a new
specification for that which is also in development that also will be
developed by the task force (SVG accessibility task force).  WAI-ARIA
semantics, today, can be used in places for SVG but is generally not the
right semantics for drawings. That is understood by both the PF and SVG
working groups.

The text content needs a mapping but not necessarily the container. Group
does not necessarily make sense either. I will look at an appropriate
solution for text content.

Paragraphs don't show up ad roles in api mappings. I agree region does not
make sense either.

We are working on times to hold the task force meeting. I posted to the
list about this last week.

Cheers,
Rich

Rich Schwerdtfeger



From:	Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To:	Alexander Surkov <surkov.alexander@gmail.com>, www-svg
            <www-svg@w3.org>, public-svg-a11y@w3.org
Cc:	Steve Faulkner <faulkner.steve@gmail.com>
Date:	11/26/2014 04:06 PM
Subject:	Re: SVG 1.1 default implicit ARIA semantics



On 26 November 2014 at 14:04, Alexander Surkov <surkov.alexander@gmail.com>
wrote:
  Should we work on SVG stuff mapping into accessibility APIs rather than
  ARIA. Some stuff like SVG text have lack of ARIA equivalents but should
  have a mapping to APIs.

A larger project is to define new ARIA roles for graphic-specific
concepts.  The mapping to existing ARIA roles is a first step, top-level
approach.  For finer-grained roles that are implemented in most
accessibility APIs but not yet in ARIA, additional instructions could be
added, equivalent to the content in the HTML-to-Platform Accessibility
guide [0].  However, since so much of SVG defines free-form presentation
without implied semantics, I don't think there will be much added material.

That said, you made me look closely at the proposal with respect to text
elements, and I identified a serious concern.

Steve's draft has "presentation" as the default role for all text elements
unless they contain specific accessibility attributes or child elements.
This would force accessibility APIs to ignore the basic text content of
these elements [1] -- probably not what most authors would expect!

I suggest that the default role for tspan, and textPath elements should
always be "group".  This means that, in the absence of specific
accessibility content, the elements are transparent for the purpose of
accessibility APIs -- the text content would be interpretted as part of the
flow of the parent text element [2].  This is consistent with their
standard use to define arbitrary styling of a span of text.

For the text element itself, however, there should be a stronger role, that
clearly distinguishes separate text elements as distinct "chunks" of text.
Currently, when copying and pasting text from an SVG into a text editor,
most browsers treat text elements as equivalent to paragraphs (separated by
line breaks), and I think that sort of semantics should be preserved.

However, ARIA doesn't currently have a paragraph-equivalent role.  I think
the closest is "region" [3], but that forces APIs to include each text
element as a separate entry in the page table of contents, which would be
problematic for much existing content (e.g., charts where each axis tick
mark has a separate text element). That leaves "group" as the only
non-abstract "section" role that doesn't have other semantics, at least for
now [4].  Either way, additional instructions could encourage accessibility
API implementers to map text elements to a more specific
paragraph-equivalent role.

I'm sure that this topic will provide fodder for the first meeting of the
re-invigorated SVG accessibility working group.

Best,
Amelia BR

[0] HTML to Platform Accessibility APIs Implementation Guide
http://www.w3.org/TR/html-aapi/
[1] presentation role definition:
http://www.w3.org/TR/wai-aria/roles#presentation
[2] group role definition: http://www.w3.org/TR/wai-aria/roles#presentation
[3] region role definition: http://www.w3.org/TR/wai-aria/roles#region
[4] section abstract role definition:
http://www.w3.org/TR/wai-aria/roles#section


  On Tue, Oct 28, 2014 at 8:41 PM, Steve Faulkner <faulkner.steve@gmail.com
  > wrote:
   Hi SVGers,

   I have put together a default implicit ARIA semantics table for the
   elements in SVG 1.1
   http://stevefaulkner.github.io/SVG1.1/

   This is based on the corresponding table in SVG 2
   https://svgwg.org/svg2-draft/single-page.html#struct-implicit-aria-semantics


   The primary goal of this doc is to provide a set of conformance criteria
   that can be implemented in conformance checkers such as
   http://validator.w3.org/nu/
   --

   Regards

   SteveF
   HTML 5.1