- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Mon, 28 Sep 2015 13:45:32 -0500
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Cc: Fred Esch <fesch@us.ibm.com>, SVG-A11y TF <public-svg-a11y@w3.org>
- Message-ID: <OFAEF404E7.DB61E068-ON86257ECE.0066FD1F-86257ECE.00670BBE@us.ibm.com>
Yes, it is a new feature in SVG2. I had not tried it out but there are not
supposed to be any restrictions.
Rich Schwerdtfeger
From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Fred Esch/Arlington/IBM@IBMUS, SVG-A11y TF
<public-svg-a11y@w3.org>
Date: 09/28/2015 01:30 PM
Subject: Re: SVG AAM
The <iframe> in SVG is a new feature in SVG 2. As far as I know, it is not
supported in any browsers yet.
Thanks for all the edits Richard. I'll try to find time to review them by
Friday, and then hopefully we can make a resolution to publish during the
telcon.
ABR
On 28 September 2015 at 14:11, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
There should not be a restriction on using an IFrame in SVG. It sounds
like a paste problem with the IBM Wiki. Did you look at the DOM after you
pasted it in with Firebug?
Rich
Rich Schwerdtfeger
Inactive hide details for Fred Esch---09/28/2015 01:03:16 PM---Rich, I
like the revised text.Fred Esch---09/28/2015 01:03:16 PM---Rich, I like
the revised text.
From: Fred Esch/Arlington/IBM
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-svg-a11y@w3.org
Date: 09/28/2015 01:03 PM
Subject: Re: SVG AAM
Rich,
I like the revised text.
Isn't there any restrictions on iframe use in an SVG? What I was doing
was calling a Brunel interactive chart in the iframe. The iframe snippet
comes from Brunel, and if you paste the iframe snippet in an HTML page
you get an interactive chart on you web page. Pasting the iframe snippet
in IBM wiki's works too, but the iframe snippet does not in W3C wikis.
Is it OK to use iframes in SVG in this way? It seems allowable, but since
I didn't see the Brunel chart render in the SVG and d3 threw an error I
assume that it would not be easy to make charts in iframes in SVG work
well.
Regards, Fred
Fred Esch
Accessibility Focal, Watson Solutions
AARB Complex Visualization Working Group
Chair
W3C SVG Accessibility Task Force
IBM Watson
Inactive hide details for Richard Schwerdtfeger---09/28/2015 12:47:37
PM---Hi Fred, IFrames are treated seemlessly in browsers Richard
Schwerdtfeger---09/28/2015 12:47:37 PM---Hi Fred, IFrames are treated
seemlessly in browsers today. Giving them an object
From: Richard Schwerdtfeger/Austin/IBM@IBMUS
To: Fred Esch/Arlington/IBM@IBMUS
Cc: public-svg-a11y@w3.org
Date: 09/28/2015 12:47 PM
Subject: Re: SVG AAM
Hi Fred,
IFrames are treated seemlessly in browsers today. Giving them an object
would be bad by default. IFrames in web pages today are more used in
mashups to isolate script more than they are for treating entirely
different content. When you tab into an IFrame it becomes part of the
seemless keyboard navigation order from its container.
I see your point on IFrame on the following. That is the exception rather
than the rule. Although IFrame is in SVG it really comes from HTML.
How about the following as replacement text:
With the exception of an IFrame, user agents MUST NOT include any
elements, or their descendant content, as an accessible object in the
accessibility tree that are indicated as no accessible object created in
the SVG Element Mapping Table. User agents SHOULD also exclude any
element defined by a future SVG specification or module which
specifically indicates that the element is never directly rendered.
In the case of an IFrame, user agents MUST NOT include an accessible
object in the accessibility tree unless a role of application, document,
or img is applied to the IFrame.
Rich
Rich Schwerdtfeger
Inactive hide details for Fred Esch---09/28/2015 09:49:38 AM---Rich, All
geometric primitives (circles, ellipse, line..) have aFred
Esch---09/28/2015 09:49:38 AM---Rich, All geometric primitives (circles,
ellipse, line..) have a note about switching from the img r
From: Fred Esch/Arlington/IBM
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-svg-a11y@w3.org
Date: 09/28/2015 09:49 AM
Subject: Re: SVG AAM
Rich,
All geometric primitives (circles, ellipse, line..) have a note about
switching from the img role to a graphics-symbol role. However, if the
definition of graphics-symbol is that is represents something but does
not necessarily physically look like what it represents, then
graphics-symbol wouldn't be a better role for the primitives.
Why are iframes treated differently than canvas, foreignObject, groups or
images? I don't understand why iframes don't produce an accessible
object, but can have a role of application, document or img? Furthermore,
5.1.1 Excluding Elements from the Accessibility Tree second paragraph -
User agents MUST NOT include any elements, or their descendant content,
as an accessible object in the accessibility tree that are indicated as
no accessible object created in the SVG Element Mapping Table. User
agents SHOULD also exclude any element defined by a future SVG
specification or module which specifically indicates that the element is
never directly rendered.
So an iframe not producing an accessible object and 5.1.1 indicates
nothing in the iframe will get in the accessibility tree.
Are there limitations on using iframes inside an SVG? I tried to include
a Brunel chart using an iframe inside an SVG and it caused an error for
the d3 renderer used by the Brunel chart and the Brunel chart wasn't
drawn. I didn't notice where there were any limitations on using iframes
and their content in the SVG documentation, are there limitations on
iframes is a spec? Can someone point to them?
Regards, Fred
Fred Esch
Accessibility Focal, Watson
Solutions
AARB Complex Visualization Working
Group Chair
W3C SVG Accessibility Task Force
IBM Watson
Inactive hide details for Richard Schwerdtfeger---09/25/2015 07:09:47
PM---I updated the document. I felt we should keep the AcRichard
Schwerdtfeger---09/25/2015 07:09:47 PM---I updated the document. I felt
we should keep the Accessibility API section but I dramatically
From: Richard Schwerdtfeger/Austin/IBM@IBMUS
To: public-svg-a11y@w3.org
Date: 09/25/2015 07:09 PM
Subject: SVG AAM
I updated the document.
I felt we should keep the Accessibility API section but I dramatically
simplified it. The core group could benefit from a similar undertaking.
I modified the section on Excluding Elements from the Accessibility tree
to reference the mapping table (reducing its size) but I also modified
the mapping table to replace not mapped with no accessible object
created. It was clear we need to differentiate not creating a
corresponding accessible object from the tree from how we impact the
accessible name and description.
I am going to take up the discussion about hidden elements with the
core-aam team. There is a fundamental difference over HTML where
attributes are limited to being applied on elements wheeas in SVG these
can be child elements such as in <desc> and <tittle>. These are really
attributes more than they are "programmatically hidden" content such as
when display:none is applied. Thanks for flagging that Amelia.
http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html
I also removed references to UIA Express. This API has been abandoned
with IE 11 and no further work is being done on it or IE itself in terms
of accessibility. We will focus on UIA for Edge. AT vendors can access
the SVG markup from the DOM like they do with IE today.
I would like to do a heartbeat draft soon. There have been extensive
modifications from the first draft earlier this year.
Rich
Rich Schwerdtfeger
Attachments
- image/gif attachment: graycol.gif
- image/jpeg attachment: FA734325.jpg
- image/jpeg attachment: FA733068.jpg
Received on Monday, 28 September 2015 18:46:07 UTC