Re: semantic level of SVG usage

You can see an example of how to deal with a flowchart at file:///Users/chaals/Documents/github/SVG-access-W3CG/use-case-examples/revisedrec2.svg

The tricks are to make the "nodes" into lists, using aria, of links. This is invisible metadata that has to be maintained carefully or it breaks, but in most modern screenreaders it works. Adding tabindex means you can navigate with the keyboard. Adding CSS that works on :hover and :focus means keyboard navigation is actually visible. Making the connectors into links means that you can move around according to the structure.

All of which is something. Works reasonably well in blink-based browsers, and if you include the svg code within HTML as in file:///Users/chaals/Documents/github/SVG-access-W3CG/use-case-examples/revisedrec2.svg it more or less works in IE, too.

Making bidirectional links is still hard. There is a very rough example at file:///Users/chaals/Documents/github/SVG-access-W3CG/use-case-examples/sparse-chord.svg described a bit at file:///Users/chaals/Documents/github/SVG-access-W3CG/use-case-examples/sparse-chord-notes.html

The problem with this is that you can't get an overall sense of the structure without going through the whole thing. So you need a desc element - and then you need more aria to get anything and even then it only works with screen readers, which seems a bit like requiring wheelchair users to have a guide dog to catch a train…

But basically we don't need new things in SVG, just less dreadful implementation. Some of this could be readily fixed with browser extensions. And most of what is required *could* be automatically generated by libraries that produce charts. But we're not there yet :(

On the other hand, we'd love help, either playing on that github repo, or in the SVG accessibiltiy task force or community group, or through more discussion here :) So thanks for raising the topic.

For an old example of what you are proposing, you could also have a look at the metadata sections of http://w3.org/TR/svg-access - which I wrote a long time ago. THe reason for shifting my thinking is based on the difficulty of establishing agreed semantics - for all that ARIA is weak, and allegedly only relevant to assistive technologies, I think it has more real promise for making some progress than anything else around right now. Although if someone manages to do it outside ARIA that would also be fine.

cheers

17.08.2016, 18:28, "Rich Morin" <rdm@cfcl.com>:
> Although I like the idea of adding ARIA metadata to SVG, I'm concerned
> that its effectiveness may be extremely limited by the semantic level
> of SVG tags and their typical usage.
>
> # Motivation
>
> Consider a data flow diagram, as produced by OmniGraffle. The building
> blocks of the diagram are geometric shapes and arrows, but this level
> of abstraction is largely absent from the SVG. Instead, it uses either
> a filled `path` or a pair of `rect` elements.
>
> And, although the semantic payload of the diagram is largely concerned
> with connectivity, the SVG contains no information on this. The only
> way I can see to get connectivity information is to compare locations
> of line endpoints with the (fuzzy) boundaries of geometric shapes.
>
> I have similar concerns about other kinds of plots and diagrams. For
> example, the semantic payload of a pie chart or a histogram has to do
> with the numeric quantities being represented, not with the angles or
> heights used in the generated image.
>
> The SVG images produced by D3.js are even more problematic, using tags
> which have only a distant relationship to the semantic payload:
>
>   https://github.com/d3/d3/wiki/gallery
>   http://bl.ocks.org/mbostock
>
> In summary, adding attributes to SVG tags may not be enough to make
> the resulting image particularly accessible.
>
> # Proposal
>
> By combining SVG attributes (e.g., object identity) with a separate
> section of the XML document, it would be possible to add arbitrary
> semantic information to the image. For example, the added section
> could describe graph connectivity, encode raw data for plots, etc.
>
> This could support a variety of post-processing needs, ranging from
> accessibility to machine learning. And, because the added section
> wouldn't be part of the base SVG, programs could simply ignore it.
>
> Comments and suggestions welcome.
>
> -r
>
> P.S. Amanda Lacy, Johannes Rössel, and Gene Dronek contributed
>       valuable information and insights to this note, but they
>       are not responsible for my conclusions.
>
> --
> 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

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Wednesday, 17 August 2016 22:28:01 UTC