Re: SVG AAM

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



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                                    
                                                                 
                                                                 







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

Received on Monday, 28 September 2015 18:12:58 UTC