SVG 2 review request

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Accessible chart and diagrams -- declarative topology (was SVG 2 review request)

David Dailey
Hi Rich,

Following the lead of Doug and Amelia and putting this in a new thread since
I think it is probably beyond the scope of a feature review for SVG2, there
has been some discussion (there really has, I'm not making this up!) here
for several years about SVG "connectors"[1] that would have some graph
theoretic properties. I think it is safe to say that it won't be a part of
SVG2. On the other hand, there did seem to be some support and there was a
good deal of discussion, since I was even present for some of it.

I would hope that SVG2's approval moves along fairly smoothly (despite what
I think are some steps backward from SVG 1.1 and particularly from SVG1.2).
I also hope that input from the community of users of SVG will be weighed
heavily, in what I hope will be new work on SVG3. SVG 2 seems (to this
"outsider") to have been a period of hunkering down and reinventing things
so that HTML can have access all the good things that SVG has brought to the
numerous and diverse visualization communities.

SVG's inability to deal with connectivity (in maps, diagrams, traffic flow
and topological constructs) has been the subject of many presentations by
the community of practicing SVG users for many years at SVG Open and The
Graphical Web. The persistent "superpath" proposals that have emerged since
SVG1.2 point to a continued interest from users in such things. Dr.
Moissinac's presentations [2,3] on the topic have reminded us of how much
some of that work looks like topology, but then much of Tav [4] and Nikos'
[5] work on advanced gradients has a strongly topological flavor as well
(orientation and alignment of directionality on surfaces).

I've been working on a "theory of flow and drawing" that depicts such things
as weave, underpasses, relationships, knots, visual paradox, and
directionality things that are currently difficult to accomplish with SVG.
I have quite a corpus of material I've developed toward that end and am
hoping to have it in some sort of presentable state by November.  I'm
encouraged by the existence of concise notations for certain combinatorial
structures like Venn diagrams, knots, tangles, and polyominoes. I think a
declarative notation, such as you've advanced, can be brought to bear on
problems that are fundamentally more topological and graph theoretic than
strictly 2D and geometric. The level of abstraction and semantics would be
higher.

I don't know if the W3C or the SVG WG is able to entertain such development
of "declarative topology" or not.

Cheers
David

[1] http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml
[2] http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf
[3] http://graphicalweb.org/2015/#presentation_33
[4] https://svgwg.org/svg2-draft/shapes.html#MeshElement 
[5] http://graphicalweb.org/2015/#presentation_18



-----Original Message-----
From: Rich Morin [mailto:[hidden email]]
Sent: Tuesday, August 16, 2016 4:16 PM
To: [hidden email]
Cc: www-svg
Subject: Re: SVG 2 review request

Following up on my speculation about ways to make SVG-encoded charts and
diagrams accessible, I created this wiki page:

  http://wiki.cfcl.com/Projects/AxAp/Graphs

Comments and suggestions welcome.

-r

--
http://www.cfcl.com/rdm           Rich Morin           [hidden email]
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841

Software system design, development, and documentation







Reply | Threaded
Open this post in threaded view
|

Re: semantic level of SVG usage

Jonathan Wilkes
In reply to this post by Rich Morin
> 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've ported the GUI of Pure Data (diagram-based realtime DSP
language) from tcl/tk-- using tk canvas-- to nw.js-- using SVG.  In
both cases it's trivial to walk the graph-- with tk canvas you'd leverage

the "-tags" flag, and with SVG you'd leverage the "class" attribute.  

Furthermore, in SVG you can leverage <g> to group the rectangles or
paths that belong to a particular "node" in the diagram.  Let's say you
have a <g id="node1"> and <g id="node2">.  To connect them, use a
<line id="line1" class="from_node1 to_node2">.  It's completely unambiguous.

-Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: semantic level of SVG usage

Cohn, Jonathan
In reply to this post by Rich Morin
Is the labeling of SVG supported by the primary screen readers at this time? Would your proposal mean that all screen readers would need to implement a second approach to providing information?

Thanks,
Jonathan Cohn
AIR

> On Aug 17, 2016, at 12:20 PM, Rich Morin <[hidden email]> wrote:
>
> 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           [hidden email]
> http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841
>
> Software system design, development, and documentation
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Interactive Images (was: SVG 2 review request)

Amelia Bellamy-Royds
In reply to this post by Amelia Bellamy-Royds
In a separate thread, David Dailey referenced my last email, saying:

Now, if as Amelia points out[1], folks can work on convincing places like FB, Google Plus, Twitter and Wikipedia that SVG in <img> adds value to their platforms – and is safe--, the web will become a richer place.  Am I correct in concluding from what I read at the links you provided, Amelia, that SVG in <img> is, as much as anything on the web, safe right now?


[1] https://lists.w3.org/Archives/Public/www-svg/2016Aug/0030.html


That's an oversimplification.  Sorry if I made it seem like a solved problem.

It is true that, while I am viewing the SVG as an embedded image, it is safe, and can't access or modify the rest of the HTML page.  Therefore, embedding an SVG as an image in your website is safe if it is hosted on an external domain.  This is what Ello does, embedding the SVG images that you host on your own website.

The risk is in hosting and serving unknown SVG files from your web domain, if that domain also hosts private content that normally requires authentication to access.  Which covers a lot of social media use cases.

User-uploaded SVG files are still a potential security risk, just like user-uploaded HTML or JavaScript, because the file can always be viewed independently, and the security limitations of the image element no longer apply.  

For example, if I were to upload an awesome-looking but secretly malicious SVG (that someone had shared with me) to a host service, and then view that hosted SVG in an active tab (because the person who shared it told me that it looks better full-screen), it could run scripts that fetched all my other private images hosted on that service and forwards them to a 3rd party server.

An HTTP Content Security Policy directive used by the host server and enforced by my web browser could prevent this.  However, there are still many browsers in use which don't enforce CSP: http://caniuse.com/#feat=contentsecuritypolicy 

Host servers could of course strip and sanitize SVG, just like they sanitize HTML comments and other uploaded content (and other images, too, by processing them to remove metadata).  For example, they could remove all script tags and event handler attributes, and maybe all external references.  But so far there hasn't been enough user demand to convince the larger social media companies to do the same.

~ABR

Reply | Threaded
Open this post in threaded view
|

Re: semantic level of SVG usage

Chaals McCathie Nevile
In reply to this post by Rich Morin
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" <[hidden email]>:

> 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 [hidden email]
> 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
[hidden email] - - - Find more at http://yandex.com

Reply | Threaded
Open this post in threaded view
|

Re: Accessible chart and diagrams -- declarative topology (was SVG 2 review request)

Rich Morin
In reply to this post by David Dailey
> On Aug 17, 2016, at 10:35, David Dailey <[hidden email]> wrote:
> ... there has been some discussion (there really has, I'm not making this
> up!) here for several years about SVG "connectors"[1] that would have some
> graph theoretic properties. I think it is safe to say that it won't be a
> part of SVG2. On the other hand, there did seem to be some support and
> there was a good deal of discussion, since I was even present for some of it.

I'm not at all surprised to find that I wasn't the first person to have these
sorts of ideas, but I would also have had no easy way to find the best work.
Many thanks (to everyone) for the feedback, pointers, etc!


> I would hope that SVG2's approval moves along fairly smoothly ...

What he said.


> SVG 2 seems (to this "outsider") to have been a period of hunkering down ...

I think I understand your point.  However, I need to familiarize myself with
the basics of the proposed changes before criticizing anything in them.  The
specific details of SVG 2 are waaaaaaay beyond my competence (or interest,
really, except in specific cases) as a practicing programmer.


> SVG's inability to deal with connectivity (in maps, diagrams, traffic flow
> and topological constructs) has been the subject of many presentations ...

I can tell that I have even more reading to do. :)


> I've been working on a "theory of flow and drawing" that depicts such
> things as weave, underpasses, relationships, knots, visual paradox, and
> directionality; things that are currently difficult to accomplish with SVG.
> I have quite a corpus of material I've developed toward that end and am
> hoping to have it in some sort of presentable state by November.  I'm
> encouraged by the existence of concise notations for certain combinatorial
> structures like Venn diagrams, knots, tangles, and polyominoes. I think a
> declarative notation, such as you've advanced, can be brought to bear on
> problems that are fundamentally more topological and graph theoretic than
> strictly 2D and geometric. The level of abstraction and semantics would be
> higher.

  "It was my understanding that there would be no math."
  From the Saturday Night Live sketch, "Presidential Debate" in 1976.
  (Chevy Chase played Gerald Ford).
  https://en.wikiquote.org/wiki/Chevy_Chase

Seriously, heavily theoretical approaches can present a steep learning curve,
so I hope you can make this stuff accessible to mathematically challenged
folks like me.  I'll also note that mathematical notation itself can be quite
a challenge to blind readers.  Some can make use of encodings such as Nemeth
Braille or LaTeX; others may simply give up on this sort of material.


> I don't know if the W3C or the SVG WG is able to entertain such development
> of "declarative topology" or not.

The IETF famously gets by on "rough concensus and running code":

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

If proof of concept examples exist or can be created, along with a supporting
theory, that might convince some.  Meanwhile, propose a _de facto_ standard.

-r

 --
http://www.cfcl.com/rdm           Rich Morin           [hidden email]
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841

Software system design, development, and documentation



Reply | Threaded
Open this post in threaded view
|

RE: semantic level of SVG usage

Sean Murphy (seanmmur)
In reply to this post by Rich Morin
Is there any examples of accessible diagrams using SVG? As I find this difficult to understand how the final product will be accessible to a screen reader user who cannot see the screen. Described diagrams are something that someone has to interpret and then explain in a way the end-user can understand. Look at any network l2 or l3 topology diagram, programming logic flow chart, work flow complex flow chart, etc which has multiple paths and exit/entry points. Very quickly the diagram becomes difficult to understand from a blind persons point of view if the diagram hasn't been carefully transcribed.

Bar charts, Pye charts and simular charts from Excel showing data  is far easier to be made accessible.

So is there any examples of complex SBG diagrams that I could see using the SVG concepts discussed here?

Sean Murphy
Accessibility Software engineer
[hidden email]
Tel: +61 2 8446 7751 Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com
 
 Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.


-----Original Message-----
From: Rich Morin [mailto:[hidden email]]
Sent: Thursday, 18 August 2016 2:21 AM
To: [hidden email]
Cc: www-svg <[hidden email]>
Subject: semantic level of SVG usage

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           [hidden email]
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841

Software system design, development, and documentation





Reply | Threaded
Open this post in threaded view
|

Re: semantic level of SVG usage

Rich Morin
> On Aug 17, 2016, at 22:13, Sean Murphy (seanmmur) <[hidden email]> wrote:
> Is there any examples of accessible diagrams using SVG? ...

My wiki page on accessible diagrams of graphs contains several versions
of a seven-node graph: image, descriptive text, DOT, and Cypher.  I don't
know how well any of these approaches would scale to a larger graph.

What I can say is that most diagrams of graphs become hard to interpret
visually as the number of nodes increases past a dozen or so.  With very
few exceptions (e.g., architectural and circuit diagrams, maps), a graph
with more than 100 nodes mostly results in "wow, isn't that complicated".

So, my take is that some sort of interactive navigation is the only real
answer to absorbing large graphs.  That said, feel free to give feedback
on the versions in the page:

  http://wiki.cfcl.com/Projects/AxAp/Graphs

And, if you think of anything that might work better, bring it up!

-r

 --
http://www.cfcl.com/rdm           Rich Morin           [hidden email]
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841

Software system design, development, and documentation



Reply | Threaded
Open this post in threaded view
|

Re: semantic level of SVG usage

Chaals McCathie Nevile
In reply to this post by Sean Murphy (seanmmur)
Hi Sean,

18.08.2016, 07:21, "Sean Murphy (seanmmur)" <[hidden email]>:
> Is there any examples of accessible diagrams using SVG? As I find this difficult to understand how the final product will be accessible to a screen reader user who cannot see the screen. Described diagrams are something that someone has to interpret and then explain in a way the end-user can understand. Look at any network l2 or l3 topology diagram, programming logic flow chart, work flow complex flow chart, etc which has multiple paths and exit/entry points. Very quickly the diagram becomes difficult to understand from a blind persons point of view if the diagram hasn't been carefully transcribed.

Yes, these things are hard to understand. For a sighted user as well - and that's assuming the actual graphics were well designed for easy understanding, which often they aren't.

Essentially, working out how to break down structures in the right way is difficult, and can be audience-dependent. The sort of CSS techniques I used in the process diagrams - as Rich pointed out, the link was wrong but he corrected it in his mail already - can be used with e.g. a diagram of a car or a camera, to provide layers of structure that can be explored - enabling the user to get a sense of what is there at different levels of detail from an overview to a detailed look at some structure.

As a kid I had some books that did this with transparent or semi-transparent overlays, but what we can do with SVG is more powerful because of the ability to provide animation and interactivity. This is the sort of stuff that graphic communication and instructional design covers, and there are millions of people in those fields who could teach something to those of us who are experts in back-end programming, front-end aesthetics, translating things to web technology, or analysing Web accessibility...

> Bar charts, Pye charts and simular charts from Excel showing data is far easier to be made accessible.
>
> So is there any examples of complex SBG diagrams that I could see using the SVG concepts discussed here?

I don't know of any. I got some diagrams from Boeing, which are in the SVG-access use cases repository but I haven't been able to understand them well enough to try playing with the SVG - and I have had very limited time.

By the way, the use-cases repo is full of diagrams, and the idea is that anyone is free to try making them more accessible however they think they can. Throw your tools at them, hand-craft improvements - which is what I do, although largely in my spare time - whatever you think can show us a way forward even if it's a one-off demonstration of an idea.

cheers

> Sean Murphy
> Accessibility Software engineer
> [hidden email]
> Tel: +61 2 8446 7751 Cisco Systems, Inc.
> The Forum 201 Pacific Highway
> ST LEONARDS
> 2065
> Australia
> cisco.com
>
>  Think before you print.
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
>
> -----Original Message-----
> From: Rich Morin [mailto:[hidden email]]
> Sent: Thursday, 18 August 2016 2:21 AM
> To: [hidden email]
> Cc: www-svg <[hidden email]>
> Subject: semantic level of SVG usage
>
> 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 [hidden email]
> 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
[hidden email] - - - Find more at http://yandex.com

Reply | Threaded
Open this post in threaded view
|

Re: semantic level of SVG usage

Steve Schafer
In reply to this post by Rich Morin
Pursuant to the recent discussions of both animation and accessibility
in SVG, I think this real-world (sort of) example may be useful:

https://glebbahmutov.com/draw-cycle/

It is an animated visual depiction of button-click events traveling
through a simple cyclical dataflow network. (Click the Increment and
Decrement buttons to see it in action.) Its purpose is pedagogical; it
is intended to help programmers understand how the Cycle.js reactive
programming framework works.

Source code and documentation are here:

https://github.com/bahmutov/draw-cycle

The graphics are displayed using SVG, but the animation is performed via
JavaScript (using Raphael.js).

This raises some interesting questions:

1) Can this be done with SVG only (either currently or in the future)?

2) Should the capability of creating something like this even be a goal
of SVG?

3) Is it plausible to make something like this understandable to a
person using non-visual assistive technology?

-Steve Schafer

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


Reply | Threaded
Open this post in threaded view
|

Re: semantic level of SVG usage

Amelia Bellamy-Royds
In reply to this post by Cohn, Jonathan
Regarding Jonathan Cohn's question:

Is the labeling of SVG supported by the primary screen readers at this time? Would your proposal mean that all screen readers would need to implement a second approach to providing information?

At this time, screen reader support of SVG is limited, but it has been getting much better in the past year, primarily because of improvements in the way the browsers expose the document.

What we had seen previously was that browsers tended to expose ARIA attributes on SVG elements, but not SVG's native alternative text elements (which use child text-container elements to describe the parent graphic element).  SVG 2 and SVG-AAM now require both types of alternative text to be supported, with the ARIA attributes taking precedence when they are present.  Therefore, any graphic that was made accessible through the addition of ARIA attributes will remain accessible in the same way.  

But in addition, we expect to see an improvement in accessibility of many graphics which included alternative text consistent with the SVG 1 model, but which weren't being correctly exposed to assistive tech.  Furthermore, because SVG 1 used a child element for alternative text, instead of an attribute, SVG 2 was able to define multiple alternatives in different languages.

At the screen reader level, there should be no change in implementations: the differences would be handled at the browser level, in how they compute the accessible name and description for the shape elements.

Once the browsers get better at exposing SVG documents in a consistent manner, then more advanced screen reader features may be possible, allowing two-dimensional exploration of the graphic.  This could be especially useful once more complex semantics are defined for data charts, maps, and flow charts.  Some demonstration software exists showing how this could work, but the interaction is controlled entirely with scripting, rather than using native screen reader features, so we do not have to worry about backwards compatibility.

~Amelia Bellamy-Royds

12