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
|

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

There are two areas that I think would be of concern:
* text [2]
* language based selection via switch [3]

I don’t believe there should be any new i18n issues as a result of the changes to these sections.
In SVG 2, we mostly defer to CSS for text layout.
Regarding language selection, this is not new to SVG 2, but we have changed selection slightly based on the SMIL allowReorder behaviour.

If you find issues, please raise them on our Github issue tracker:
https://github.com/w3c/svgwg/issues

Or if you’ve been following along the development of SVG 2 and 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/
2. https://svgwg.org/svg2-draft/text.html
3. https://svgwg.org/svg2-draft/struct.html#SwitchElement
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
|

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

Phillips, Addison-2
In reply to this post by Nikos Andronikos
Hello Nikos,

Thanks for the note regarding SVG2. I have added your document to our Review Radar [1].

> In the SVG WG, we have reached the point where we feel we’re ready to go
> to CR with SVG 2.

It's usually a Bad Idea to withhold your I18N review until this late in your development process. Issues raised at this point will delay your CR. Do you have a specific schedule or due date for our comments? Please be advised that reviews require at least two weeks, since the WG must review issues in our Thursday (1500UTC) teleconference and time must be provided to actually read your document.

Best regards (for I18N),

Addison

[1] http://w3c.github.io/i18n-activity/radar/

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.




> -----Original Message-----
> From: Nikos Andronikos [mailto:[hidden email]]
> Sent: Monday, August 08, 2016 9:30 PM
> To: [hidden email]
> Cc: www-svg <[hidden email]>
> Subject: SVG 2 review request
>
> 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
>
> There are two areas that I think would be of concern:
> * text [2]
> * language based selection via switch [3]
>
> I don’t believe there should be any new i18n issues as a result of the changes
> to these sections.
> In SVG 2, we mostly defer to CSS for text layout.
> Regarding language selection, this is not new to SVG 2, but we have changed
> selection slightly based on the SMIL allowReorder behaviour.
>
> If you find issues, please raise them on our Github issue tracker:
> https://github.com/w3c/svgwg/issues
>
> Or if you’ve been following along the development of SVG 2 and 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/
> 2. https://svgwg.org/svg2-draft/text.html
> 3. https://svgwg.org/svg2-draft/struct.html#SwitchElement
> 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

r12a
On 09/08/2016 16:35, Phillips, Addison wrote:
> Please be advised that reviews require at least two weeks, since the WG must review issues in our Thursday (1500UTC) teleconference and time must be provided to actually read your document.

Btw, to my mind the time crunch really comes if we find something we
believe needs to be changed.  The review itself is usually much less
time-consuming than the  explanations, discussions, tracking, etc that
are involved in addressing issues that arise.

Just wanted to mention that so that it doesn't come as a surprise.

cheers,
ri


Reply | Threaded
Open this post in threaded view
|

Re: SVG 2 review request

Nikos Andronikos

> On 10 Aug 2016, at 4:53 PM, r12a <[hidden email]> wrote:
>
> On 09/08/2016 16:35, Phillips, Addison wrote:
>> Please be advised that reviews require at least two weeks, since the WG must review issues in our Thursday (1500UTC) teleconference and time must be provided to actually read your document.
>
> Btw, to my mind the time crunch really comes if we find something we believe needs to be changed.  The review itself is usually much less time-consuming than the  explanations, discussions, tracking, etc that are involved in addressing issues that arise.
>
> Just wanted to mention that so that it doesn't come as a surprise.
>
> cheers,
> ri
>
>

Thanks, we understand the situation.
Because of our deferral to CSS for any of the new text layout features, I think that any issues that arise specifically on SVG 2 will be minor.

A two week review period is fine.

Cheers,
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

David Dailey

I think the Working Group’s willingness to consider interactivity in SVG inside HTML <img> [reference to previous discussions on listserv]

as well as the ability to deform text (and glyphs) to shapes (as cited in 2.0)  can also be cited as examples of progress on accessibility. The less often authors need to make bitmaps to display their meaningful intentions, the better for accessibility (at least until the Turing test for vision has been passed). Similarly, the less often animated GIF is needed to display the semantics of animation, the better!

 

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 of proximity, connectedness, number of points in a polygon, canonical descriptions of movement around a circle, etc. *are* accessibility. [1]

 

cheers

David

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

 

From: Amelia Bellamy-Royds [mailto:[hidden email]]
Sent: Thursday, August 11, 2016 4:36 PM
To: Rich Morin
Cc: [hidden email]; Nikos Andronikos; www-svg
Subject: 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 <[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">+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 David Dailey
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 David Dailey
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

David Dailey
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

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: Interactive Images (was: SVG 2 review request)

Amelia Bellamy-Royds
Since this debate seems to be re-starting again, can we please keep it to the www-svg list, and not continue to spam the WAI list.  Olaf Hoffman previously tried to rename & re-focus this thread [1], but it didn't catch.


If you haven't read that note, please do; it outlines many of the security concerns.

As I think I've said before on this topic, I would not support changing the behavior of SVG in image tags.  As it is, most social media platforms and content management systems do not support SVG in images, in part because of security concerns, in part because of inconsistent rendering between browsers, and in part just because of legacy ideas about what an image is.  

If we gave SVG in images additional behavior inconsistent with other image types, such as interaction (even non-scripted) and external resources (such as web fonts) we would be even less likely to convince the developers of these platforms that SVG can be safely used like any other image format.

Furthermore, interactive SVG in an img tag could not easily be made accessible.  The accessible representation of an HTML <img> is supposed to be fully described by its markup, particularly the alt attribute.  Yes, we could change how SVG images are exposed, but at the cost of up-ending all author expectations.  When WebKit started making the full content of embedded SVG graphics available to screen readers last year (similar to an embedded SVG object), it actually broke the accessibility of many pages, because the metadata in the external files was not a proper replacement for the alt text.

As Tab notes, if you want an interactive, accessible SVG embed in HTML, you can use the <object>, <iframe>, or <embed> tags.

If you are sharing SVG files in a platform that allows SVG in images but not embedded objects, you can always suggest that readers use the context menu to open the image in a new tab, which will open it as a fully interactive independent document.

This feature, though convenient for our purposes, is actually one of the remaining security concerns with user-uploaded SVG images.  They are security restricted while embedded as <img>, but have full scripting access to the host domain if opened as independent documents.  HTTP content security directives can be used to safely sandbox the file from the host server, regardless of how the file is accessed, but they are not supported in some older browsers still in use.

If you're interested in the existing security concerns with SVG images, and possible solutions to them, there is a good discussion in the comments to this recent blog post on SVG in WordPress: https://bjornjohansen.no/svg-in-wordpress

Again, I think any effort to increase the functionality of SVG in HTML <img> would have the opposite effect to what is desired.  Instead of increasing the availability of platforms for sharing interactive SVG, it would lead to even fewer platforms for sharing any sort of SVG.

Regardless, it isn't really our call.  So long as the HTML spec defines that <img> embeds a "non-interactive, optionally animated, image resource that is neither paged nor scripted", that's all it will be.

~Amelia

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





12