Re: Effect of role=presentation on img elements with svg

"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 ..."

It does seem like the topic of images has somewhat hijacked the thread.

I believe the original topic was to introduce a name for the role of 
presentation that more closely indicated what its intended purpose was 
supposed to be within the spec, not necessarily about the buggy ways that it 
might be implemented in some cases.

Still, as far as I'm aware, the purpose of presentation within the spec is 
to nullify a particular element within the accessibility tree, and to leave 
all child nodes alone if present.






----- Original Message ----- 
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>; <jason@jasonjgw.net>; <wai-xtech@w3.org>; 
<w3c-wai-pf@w3.org>
Sent: Sunday, February 02, 2014 8:22 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 Sunday, 2 February 2014 21:31:45 UTC