SVG 2 review request

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

SVG 2 review request

Nikos Andronikos
Hi all,

In the SVG WG, we have reached the point where we feel we’re ready to go to CR with SVG 2.
To confirm this, I would like to request a review of the current draft [1].

To give an overview of what has changed in SVG 2, please see the following wiki page:
https://github.com/w3c/svgwg/wiki/SVG-2-new-features

Because of the work of the SVG A11Y TF, I hope that any issues have already been identified and resolved.
But, if you do find issues, please raise them on our Github issue tracker:
https://github.com/w3c/svgwg/issues

Or if you think everything is ok, please let us know as well.

Looking forward to hearing from you.
Thanks,
Nikos.

1. https://svgwg.org/svg2-draft/

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Nikos Andronikos
Hi again,

I forgot to mention, sending an email to [hidden email] is also an acceptable method for notifying the SVG WG of issues.

Thanks,
Nikos.



The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Katie Haritos-Shea GMAIL

Thanks Nikos!

Katie Haritos-Shea
703-371-5545


On Aug 9, 2016 8:10 PM, "Nikos Andronikos" <[hidden email]> wrote:
Hi again,

I forgot to mention, sending an email to [hidden email] is also an acceptable method for notifying the SVG WG of issues.

Thanks,
Nikos.



The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Rich Morin
In reply to this post by Nikos Andronikos
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           [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: SVG 2 review request

Amelia Bellamy-Royds
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 <[hidden email]> 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           [hidden email]
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   <a href="tel:%2B1%20650-873-7841" value="+16508737841">+1 650-873-7841

Software system design, development, and documentation





Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Rich Morin
> On Aug 11, 2016, at 21:33, David Dailey <[hidden email]> wrote:
>
> I think the Working Group’s willingness to consider interactivity in SVG
> inside HTML <img> ... as well as the ability to deform text (and glyphs)
> to shapes ... can also be cited as examples of progress ...


> 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 ... *are* accessibility.

Indeed!

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

Unfortunately, several of the image links in this paper are broken.

-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: SVG 2 review request

Rich Morin
In reply to this post by Amelia Bellamy-Royds
I just saw this cartoon, taken from http://TechnicallyFunny.com

  In Honor of John Venn's 180th Birthday
  https://www.facebook.com/photo.php?fbid=1430550676961544

It was a Venn Diagram (unfortunately, in JPEG rather than SVG format).
However, if it _had_ been in SVG, it could have been made accessible.
So, here's my attempt at a semantic interpretation (in mock Ruby :-).

  yo_180 = [ ... ]        # People Who Are 180 Years Old
  alive  = [ ... ]        # People Who Are Still Alive
  sa_180 = yo180 & alive  # empty set

  uvd = [ ... ]    # People Who Understand Venn Diagrams
  soh = [ ... ]    # People With a Sense of Humor
  gtj = uvd & soh  # People Who Get This Joke

Here's an interactive Ruby session, which may help the perplexed:

  >> a = [1,2]
  => [1, 2]
  >> b = [2,3]
  => [2, 3]
  >> c = a & b
  => [2]

-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: SVG 2 review request

Tab Atkins Jr.
In reply to this post by Amelia Bellamy-Royds
Diversion, but...

On Thu, Aug 11, 2016 at 9:33 PM, David Dailey <[hidden email]> wrote:
> I think the Working Group’s willingness to consider interactivity in SVG
> inside HTML <img> [reference to previous discussions on listserv]

Uh, this will never happen. Interactive SVG is already easily possible
in HTML via <iframe> or <object>.  <img> already has a
decently-defined processing model that eliminates any possibility of
interactivity.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Doug Schepers-3
Hey, folks–

For reference, here's an earlier thread that David might be talking about:

https://lists.w3.org/Archives/Public/www-svg/2015Mar/0121.html

Nothing conclusive, but it may be worth considering, before completely
dismissing the notion of interactive content in <img>.

I'd like to hear a more concrete explanation of why interactivity in
<img> must be disallowed.

Regards–
Doug

On 8/12/16 7:54 PM, David Dailey wrote:

> This is not at all consistent with previous discussions here.
>
> D
>
> -----Original Message----- From: Tab Atkins Jr.
> [mailto:[hidden email]] Sent: Friday, August 12, 2016 5:58 PM
> To: David Dailey Cc: Amelia Bellamy-Royds; Rich Morin;
> [hidden email]; Nikos Andronikos; www-svg Subject: Re: SVG 2
> review request
>
> Diversion, but...
>
> On Thu, Aug 11, 2016 at 9:33 PM, David Dailey
> <[hidden email]> wrote:
>> I think the Working Group’s willingness to consider interactivity
>> in SVG inside HTML <img> [reference to previous discussions on
>> listserv]
>
> Uh, this will never happen. Interactive SVG is already easily
> possible in HTML via <iframe> or <object>.  <img> already has a
> decently-defined processing model that eliminates any possibility of
> interactivity.
>
> ~TJ
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Patrick H. Lauke
On 13/08/2016 05:50, Doug Schepers wrote:

> I'd like to hear a more concrete explanation of why interactivity in
> <img> must be disallowed.

Maybe not a deeply technical explanation, but: I would argue that when
talking about an "image", people are thinking about something visual,
presentational, non-interactive (though possibly animated). The <img>
element is the HTML representation of this concept. In fact, the spec
(for convenience, just going to point to
https://www.w3.org/TR/html5/embedded-content-0.html#the-img-element) says

"[...] a non-interactive, optionally animated, image resource that is
neither paged nor scripted."

<img> is exposed to AT with a role of image, and again this is
understood (by users and AT) to be something non-interactive.

*IF* you wanted to add something interactive inside an <img>, you'd need
to signal this with at least the addition of a different role="..."
attribute (and then change user agent behavior, which would assume <img>
is non-interactive, so presumably doesn't cater for focusability etc).
But this still feels like a conceptual stretch...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Tab Atkins Jr.
On Sat, Aug 13, 2016 at 2:49 AM, Patrick H. Lauke
<[hidden email]> wrote:

> On 13/08/2016 05:50, Doug Schepers wrote:
>> I'd like to hear a more concrete explanation of why interactivity in
>> <img> must be disallowed.
>
>
> Maybe not a deeply technical explanation, but: I would argue that when
> talking about an "image", people are thinking about something visual,
> presentational, non-interactive (though possibly animated). The <img>
> element is the HTML representation of this concept. In fact, the spec (for
> convenience, just going to point to
> https://www.w3.org/TR/html5/embedded-content-0.html#the-img-element) says
>
> "[...] a non-interactive, optionally animated, image resource that is
> neither paged nor scripted."
>
> <img> is exposed to AT with a role of image, and again this is understood
> (by users and AT) to be something non-interactive.
>
> *IF* you wanted to add something interactive inside an <img>, you'd need to
> signal this with at least the addition of a different role="..." attribute
> (and then change user agent behavior, which would assume <img> is
> non-interactive, so presumably doesn't cater for focusability etc). But this
> still feels like a conceptual stretch...

Yup! And it's a completely *unnecessary* stretch, because HTML
*already* has elements that indicate interactive embedding of
resources: <iframe> and <object>!  There's zero need to fiddle with
<img>'s semantics.

~TJ

Reply | Threaded
Open this post in threaded view
|

Interactive Images (was: SVG 2 review request)

Doug Schepers-3
Hi, Tab, Patrick–

On 8/15/16 5:10 PM, Tab Atkins Jr. wrote:
> On Sat, Aug 13, 2016 at 2:49 AM, Patrick H. Lauke wrote:
>> On 13/08/2016 05:50, Doug Schepers wrote:
>>> I'd like to hear a more concrete explanation of why interactivity
>>> in <img> must be disallowed.
...

>> *IF* you wanted to add something interactive inside an <img>,
>> you'dneed to signal this with at least
>>  the addition of a different role="..."  attribute
>> (and then change user agent behavior, which would assume <img> is
>> non-interactive, so presumably doesn't cater for focusability
>> etc).
>> But this still feels like a conceptual stretch...
>
> Yup! And it's a completely *unnecessary* stretch, because HTML
> *already* has elements that indicate interactive embedding of
> resources: <iframe> and <object>!  There's zero need to fiddle with
> <img>'s semantics.

If you'll read the original thread, you'll see that the issue is more
subtle than that.

Many sites and services only use <img> because it bypasses the security
problems that using <object> or <iframe> would introduce.

In terms of user-expected behavior, most users are familiar with image
maps, where there is interactivity (specifically, link navigation); to
them, it doesn't matter if the link is specified in the HTML file or the
image file, they only know the UI behavior. Similarly, CSS ::hover
effects seem like interactivity on the image to users.

Allowing certain kinds of interactivity in <img>, such as link
navigation or declarative animation (like ::hover) or text selection,
but not script execution, would continue to match user and author
expectations about security and behavior, while also allowing more
interesting options for SVG images.

Regards–
Doug

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Mon, Aug 15, 2016 at 3:16 PM, Doug Schepers <[hidden email]> wrote:

> Hi, Tab, Patrick–
>
> On 8/15/16 5:10 PM, Tab Atkins Jr. wrote:
>>
>> On Sat, Aug 13, 2016 at 2:49 AM, Patrick H. Lauke wrote:
>>>
>>> On 13/08/2016 05:50, Doug Schepers wrote:
>>>>
>>>> I'd like to hear a more concrete explanation of why interactivity
>>>> in <img> must be disallowed.
>
> ...
>>>
>>> *IF* you wanted to add something interactive inside an <img>,
>>> you'dneed to signal this with at least
>>>  the addition of a different role="..."  attribute
>>> (and then change user agent behavior, which would assume <img> is
>>> non-interactive, so presumably doesn't cater for focusability
>>> etc).
>>> But this still feels like a conceptual stretch...
>>
>>
>> Yup! And it's a completely *unnecessary* stretch, because HTML
>> *already* has elements that indicate interactive embedding of
>> resources: <iframe> and <object>!  There's zero need to fiddle with
>> <img>'s semantics.
>
> If you'll read the original thread, you'll see that the issue is more
> subtle than that.
>
> Many sites and services only use <img> because it bypasses the security
> problems that using <object> or <iframe> would introduce.
>
> In terms of user-expected behavior, most users are familiar with image
> maps, where there is interactivity (specifically, link navigation); to
> them, it doesn't matter if the link is specified in the HTML file or the
> image file, they only know the UI behavior. Similarly, CSS ::hover
> effects seem like interactivity on the image to users.
>
> Allowing certain kinds of interactivity in <img>, such as link
> navigation or declarative animation (like ::hover) or text selection,
> but not script execution, would continue to match user and author
> expectations about security and behavior, while also allowing more
> interesting options for SVG images.

Note that "link navigation" is also potentially a security-conscious
behavior that sites might want to restrict, or at least would be
surprised if it was suddenly allowed.

<iframe sandbox> gives you guaranteed-safe SVG embedding, *and* lets
you more granularly shut down or enable a few more behaviors from the
defaults.  Using either <img> (for static images) or <iframe sandbox>
(for interactive images/documents) as you feel appropriate should be
all we need.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Rich Morin
In reply to this post by Nikos Andronikos
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
|

semantic level of SVG usage

Rich Morin
In reply to this post by Nikos Andronikos
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

Cohn, Jonathan
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: 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 Rich Morin
> 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



12