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 <http://www.w3.org/html/wg/drafts/html/master/>
>>
>
>