- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 3 Mar 2014 19:34:53 +0100
- To: Richard Schwerdtfeger <schwer@us.ibm.com>, WAI-PFWG <w3c-wai-pf@w3.org>, WAI-XTECH <wai-xtech@w3.org>
(Resending, because I forgot to include w3c-wai-pf@w3.org and wai-xtech@w3.org) Richard Schwerdtfeger, Fri, 28 Feb 2014 07:57:17 -0600: > Leif, > > It is meant to mean any SVG element. Why would we have an SVG mapping > guide for one element? If the message is that there is no difference, then *that* should be the guidance. The reason that it is - it seems to me - built into the very logic of the <img> element that, unless the author has filled the @alt attribute with content, then users have not direct access to whatever the <img> element displays. If this is indeed different for <img> when it contains a <svg>, then it is worth pointing out. Authors’ perceptions might be colored by the fact that the <img> has the requirement to use the alt="", also when @src contains a SVG. And authors are used - and told - to treat the alt="" attribute as if it is the sole access to the image, for non-visual users. For <iframe src=svg>, it might also be worth pointing out. However, since authors are used to linking to markup documents (namely html) via <iframe>, it it does not come as the same surprise that the SVG of <iframe src=svg /> can be accessed directly. For <object data=svg>, on the other hand, then I think authors may easily have more or less the same expectations as for <img>. May be for the next generation of web authors, this won’t be necessary pointing out … :-) (I suspect will soon start with glasses.) But IMO, it is worth it, for the time being. (Feel free to reply on public-pfwg@, according to your previous recommendation.) Leif Halvard Silli > Leif Halvard Silli ---02/03/2014 05:03:05 PM---Richard Schwerdtfeger, > Sun, 2 Feb 2014 14:01:09 -0600: > While I understand what Apple has > implement > > From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: Steve Faulkner <faulkner.steve@gmail.com>, James Craig > <jcraig@apple.com>, Joanmarie Diggs <jdiggs@igalia.com>, Cynthia > Shelly <cyns@microsoft.com>, Bryan Garaventa > <bryan.garaventa@whatsock.com>, "T.V Raman" <raman@google.com>, > "jongund@illinois.edu" <jongund@illinois.edu>, "jason@jasonjgw.net" > <jason@jasonjgw.net>, "wai-xtech@w3.org" <wai-xtech@w3.org>, > "w3c-wai-pf@w3.org WAI-PFWG" <w3c-wai-pf@w3.org> > Date: 02/03/2014 05:03 PM > Subject: Re: Effect of role=presentation on img elements with svg > > > > > Richard Schwerdtfeger, Sun, 2 Feb 2014 14:01:09 -0600: >> While I understand what Apple has implemented (defaults to a group > role) we >> have not decided on a normative mapping for SVG across browsers. We will >> be creating an implementation guide for SVG. Here are the current outline >> drafts: >> www.w3.org/WAI/PF/wiki/Outline_Core_User_Agent_Implementation_Guide > > The ”SVG 2.0 User Agent Implementation Guide” section speaks about the > ”SVG element”. It does not speak about the IMG element or any other > elements via which SVG can be served. > >> At the last WAI-PF face to face in Toronto we agreed to develop these 3 >> specs. I have to do to get with Joseph Scheuhammer to do some further >> planning for this. We will be developing a core implementation guide for >> 1.1 to which the HTML5 and SVG specs. will refer to. Both SVG and HTML5 >> will have different name computation mechanisms that we need to agree on. >> Each host platform has different features that will contribute to the name >> computation. >> >> Both HTML5 and SVG will require different name computation algorithms. >> >> Also, I would encourage us to post comments to the new public-pfwg@w3.org. >> We no longer need xtexh and wai-pf (which is private) . > > OK. Interesting. > > Leif Halvard Silli > >> Rich >> >> >> Rich Schwerdtfeger >> >> >> >> From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> >> To: Steve Faulkner <faulkner.steve@gmail.com> >> Cc: James Craig <jcraig@apple.com>, Joanmarie Diggs >> <jdiggs@igalia.com>, Cynthia Shelly > <cyns@microsoft.com>, Bryan >> Garaventa <bryan.garaventa@whatsock.com>, "T.V Raman" >> <raman@google.com>, "jongund@illinois.edu" >> <jongund@illinois.edu>, "jason@jasonjgw.net" >> <jason@jasonjgw.net>, "wai-xtech@w3.org" <wai-xtech@w3.org>, >> "w3c-wai-pf@w3.org WAI-PFWG" <w3c-wai-pf@w3.org> >> Date: 02/02/2014 10:23 AM >> Subject: Re: Effect of role=presentation on img elements with svg >> >> >> >> Steve Faulkner, Sun, 2 Feb 2014 15:09:44 +0000: >>> https://dl.dropboxusercontent.com/u/377471/SVG/index.html >> >> Based on Safari 6 and VoiceOver for OSX 10.7, the conclusions for the >> SVG-via-img-element test are incorrect w.r.t. Safari+VoiceOver. See the >> test: >> >> https://dl.dropboxusercontent.com/u/377471/SVG/adobesvgtest4.html >> >> The claim, at that page, is that the <img> defaults to img role. >> However, it actually is given group role. Of course, for OSX 10.8 and >> 10.9, the Accesibility Inspector might show another result. It is a >> quite serious deviation from HTML5 to let <img> default to group role >> rather than img role … So may be it is fixed ... >> >> Note as well that the SVG image contains script, but that HTML5 says >> about <img>: ”However, these definitions preclude SVG files with >> script”. >> >> Anyway: The most interesting thing, here, is what, if anything - in >> ARIA - permits AT to look into the document referenced at @src for >> deciding the alternative text. And why is <svg> unique? After all, it >> is possible to embed meta data in other images as well. >> >> No doubt, this matter will confuse authors even more w.r.t. to the >> effect of role="presentation". But that said, is not more complicated >> than this: We need to decided if/how/where the document in src="svg" >> fits into the accessible name calculation. I would say, though, it >> would be a fundamental break with today’s ARIA. >> >> It is a little annoying that we are invited to a debate about the name >> of the presentation role. And then it ends up as debate about meaning >> of the presentation role/pushing its limits ... >> >> Leif Halvard Silli >> >>> has a range of tests, also see >>> >> > http://blog.paciellogroup.com/2013/12/using-aria-enhance-svg-accessibility/ >>> >>> -- >>> >>> Regards >>> >>> SteveF >>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> >>> >>> >>> On 2 February 2014 13:26, Leif Halvard Silli < >>> xn--mlform-iua@xn--mlform-iua.no> wrote: >>> >>>> Steve Faulkner, Sun, 2 Feb 2014 08:23:20 +0000: >>>>>> >>>>>> Effectively, what you are saying above, is that this: >>>>>> <img role="presentation" src="svg"> >>>>> >>>>> the subdom of an <svg> img is available: >>>>> >> https://dl.dropboxusercontent.com/u/377471/SVG/adobesimplesvgtest1.htmlfor >>>>> an example, >>>>> >>>>> the subdom of <img src=svg> does not appear to be available: >>>>> >>>>> https://dl.dropboxusercontent.com/u/377471/SVG/adobesvgtest4.html >>>> >>>> I am preparing some test page. >>>> >>>> Tou are perhaps more after deeper things rather than VoiceOver >>>> behavior. But an interesting expansion of your own tests could be to >>>> set the role of the directly emebedded <svg> element to "img" and see >>>> if that changes anything in VoiceOver. >>>> >>>> Leif Halvard Silli
Received on Monday, 3 March 2014 18:35:23 UTC