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
>
> Software system design, development, and documentation
>
>
>
>
>