- From: Rich Morin <rdm@cfcl.com>
- Date: Wed, 17 Aug 2016 09:20:52 -0700
- To: "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
- Cc: www-svg <www-svg@w3.org>
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
Received on Wednesday, 17 August 2016 16:21:25 UTC