RE: SVG 2 review request

I think the Working Group’s willingness to consider interactivity in SVG inside HTML <img> [reference to previous discussions on listserv] 

as well as the ability to deform text (and glyphs) to shapes (as cited in 2.0)  can also be cited as examples of progress on accessibility. The less often authors need to make bitmaps to display their meaningful intentions, the better for accessibility (at least until the Turing test for vision has been passed). Similarly, the less often animated GIF is needed to display the semantics of animation, the better!

 

In the world of HTML, whence come most of the web standards folk, one often thinks of words (and their meanings) as being the essence of accessibility. In the domain of geometry, where the semantics of position and change of position is “the meaning,” the underlying issues of proximity, connectedness, number of points in a polygon, canonical descriptions of movement around a circle, etc. *are* accessibility. [1]

 

cheers

David

[1] http://cs.sru.edu/~ddailey/svg/GeometricAccessibility.html

 

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: Thursday, August 11, 2016 4:36 PM
To: Rich Morin
Cc: w3c-wai-ig@w3.org; Nikos Andronikos; www-svg
Subject: Re: SVG 2 review request

 

Hi Rich & the rest of the WAI team,

 

I'm one of the editors of the SVG 2 spec, and also an editor of the SVG Accessibility API Mapping (SVG-AAM) spec and related efforts in the SVG Accessibility Task Force.

 

I'm working with Nikos to update/expand the wiki page summarizing new features, but for me the important accessibility improvements are as follows:

* Provide both declarative ('tabindex') and scripted control over which elements receive keyboard focus, allowing the creation of keyboard-accessible widgets, in a manner consistent with HTML.
* Allow 'WAI-ARIA attributes' (role and also state and property attributes) on all elements
* Define default and allowed 'role' values for each element.
* Allow alternative text metadata ('title' and 'desc') to be provided in multiple language versions in the same file.

As you mention, defining default semantics is all very well, but it depends on what those are.  Within SVG 2, that means defining the implicit and allowed ARIA roles for each element type (https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics).  Within the SVG-AAM, we get into the trickier issues of exposing more complicated semantic features; that spec is still being worked on, but an Editor's Draft is at https://w3c.github.io/aria/svg-aam/svg-aam.html.  

 

You'll note that implicit role mappings for some elements use new graphics-specific roles that have been introduced by the WAI-ARIA Graphics Module (http://w3c.github.io/aria/aria/graphics.html) to describe graphical structure.  That spec is still being finalized, along with mappings for the roles in the common accessibility APIs.  This module only includes the most essential, generic roles, such as would be needed in a simple labelled diagram.  However, the SVG Accessibility Task Force is planning to follow it up with a more complex role and attribute structure for describing the semantics of complex charts and maps.  If you're interested in that topic, we're always looking for more input on the Task Force.

 

Regarding the removal of SVG Fonts:

 

If SVG Fonts had been widely supported and widely used, then removing them would be an accessibility loss, because SVG Fonts were intended to make it easier for designers to create files with custom logos and wordmarks that were still accessible as real text.  However, in practice support was poor and designers continued to use paths to ensure exact replication of wordmarks.  Furthermore, as a complete font format, SVG Fonts had very limited internationalization support.  A replacement effort to standardize the use of SVG glyphs in OpenType font files is intended to address this limitation.

 

For projects like logos where full font files are not appropriate and exact rendering is required, the new ARIA support (along with SVG's native ways of providing alternative text) can be used to provide accessible equivalents to text that is represented using graphic elements.  It's not perfect (e.g., no copy & paste support), but it does not represent a regression in any practical sense.

 

I hope that addresses most of your concerns.  If you or anyone else have further questions, do let me know.

Sincerely,

Amelia Bellamy-Royds

 

 

 

On 11 August 2016 at 10:01, Rich Morin <rdm@cfcl.com> wrote:

To get an idea of what is being considered for SVG 2, I skimmed:

  SVG 2 new features
  https://github.com/w3c/svgwg/wiki/SVG-2-new-features

I only found two items that directly referenced accessibility:

 - Include WAI-ARIA attributes and define semantics

 - Change role mapping for the 'a' element to depend on whether
   it is actually a valid link.

Both of these seem reasonable, though the definition of semantics
for the WAI-ARIA attributes could be tricky.


However, it strikes me that some of the other changes (such as
the removal of SVG Fonts) might have an impact on accessibility.
Does any tooling currently depend on the use of these fonts?


Moving into the realm of science fiction, I have been speculating
about ways to make SVG-encoded charts and diagrams accessible:

  https://en.wikipedia.org/wiki/Diagram

For example, I typically use OmniGraffle to create data flow
and system architecture diagrams.  If I were to export these as
SVG, might it be possible to recognize the underlying semantics?
If so, it might be possible to describe the connectivity and/or
enable navigation and exploration of the nodes and edges.

Corresponding techniques could (conceivably) be applied to other
charts and diagrams, including functions graphs, histograms, pie
charts, scatter plots, and Venn diagrams.

Might there be anything that SVG 2 could do to enable this sort
of thing over coming years?

-r

 --
http://www.cfcl.com/rdm           Rich Morin           rdm@cfcl.com
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841 <tel:%2B1%20650-873-7841> 

Software system design, development, and documentation