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

James Craig, Mon, 03 Feb 2014 11:04:15 -0800:
 […]
> On Feb 2, 2014, at 8:22 AM, Leif Halvard Silli wrote:
>> 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.
> 
> Why would you base your conclusions on a 3-year-old system? [...]

I only concluded about 10.7. Not about 10.8 or 10.9.

>> 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 …
> 
> The term “fixed” can only be applied if you consider this a bug. I 
> assume you’re referring to the AXGroup role here instead of the ARIA 
> “group” role, and to my knowledge, the HTML5 mapping does not list 
> any platform-specific roles, nor should it.

Oh, I thought that the AX was Apple’s ”vendor prefix”. ;-) (Just 
kidding.) Yes I am aware of the mapping. 
(http://www.w3.org/TR/wai-aria-implementation/)

>> ~what in ARIA *permits* AT to look into the document src?
> 
> I will answer your question another question, “What in ARIA precludes 
> the AT from doing the right thing for the user?”

(First: this part of the debate is a deviation - and I myself am to 
blame - into what happens when <img> with SVG inside does *not* have 
role="presentation".)

The right thing for the user is of course also my focus. With my 3 year 
old equipment, when the SVG <img> had explicit "img" role, VoiceOVer 
would collect alternative text *both* form @alt *and* from the SVG. 
Such a thing could, I guess, lead to textual repetition. It was also 
surprising to myself, based on what we have discussed in HTML5. So, 
”best for the user” is not necessarily to ”collect as much alternative 
text as possible”. 

>  I assume you’re 
> referring to the text alternative computation, and if so, it’s this 
> part:
> 
> ARIA Text Alt Comp bullet 2C.
> http://www.w3.org/WAI/PF/aria/complete#textalternativecomputation


(Now we are firmly back to when the <img> element with SVG inside has 
role="presentation".)

I’m sorry, but I am uncertain where in that computation it fits in. I 
must be dumb. I have read it several times. However, based on what you 
said earlier in this exchange, about nullifying attributes that are 
specific to a particular role/element, I just said the following, to 
Bryan:

]]
The challenge is that the @src attribute doesn’t represent ”child 
nodes”. And further, one could argue that @src, just as @alt, is a 
specific img element feature, and that @srec therefore should be 
nullified, when img has presentation role. In my view, this makes 
sense, because the graphic is supposed be presentational for *all* 
users.
[[

>>>>  • If aria-labelledby and aria-label are both empty or undefined, 
>>>> and if the element is not marked as presentational 
>>>> (role="presentation"), check for the presence of an equivalent 
>>>> host language attribute or element for associating a label, and 
>>>> use those mechanisms to determine a text alternative. For example, 
>>>> in HTML, the imgelement's alt attribute defines a label string and 
>>>> the label element references the form element it labels. See How 
>>>> to Specify Alternate Text ([HTML], section 13.8) and HTML 5 
>>>> Requirements for providing text to act as an alternative for 
>>>> images ([HTML5], section 4.8.1.1).
> 
> Two host languages are at play here: HTML and SVG. The HTML text 
> alternative should be referenced (if available) when the AT focus is 
> “on” the HTML element,

Are you simply saying, that the following to examples are equal: ?

1) <h1 role=presentation><svg>[with accessible text]</svg></h1>

2) <img role=presentation src="svg-with-accessible-text">

> which in this case may be marked as 
> presentational.

Except that, when marked as presentational, the alt text should not be 
referenced anyhow.

> However, if there is accessibility information in the 
> DOM of the image, and those elements are visibly rendered and 
> otherwise accessible to the user, the SVG rules apply when the AT 
> focus navigates to those elements.

Is it possible to focus navigate presentational <img> elements?
Is it possible to focus navigate the referenced images of a 
presentational <img> element?

You seem to consider the referenced SVG image as virtually a child 
element of <img>. I have no problem with the ethics - the user should 
have the best. But if the author has tagged the <img> as 
*presentational* (because the *graphic* was presentational), then 
should it matter that the graphic is a SVG? If it should matter, then 
it means that for presentational SVG images served via <img>, it would 
not be enough to tag the <img> as presentational - one would also have 
to tag the very <svg> itself as presentational and/or to remove any 
textual content of the SVG. (Ore use aria-hidden="true" etc.)

> If the <img> had @aria-hidden="true" applied, I would agree with you 
> that all the sub-DOM contents should be removed from the 
> accessibility tree, but we’re not talking about aria-hidden, we’re 
> talking about the presentation role.

I understand your thinking w.r.t. svg served via <img>.

But to put this on an edge: As you know, for img elements, AT tend to 
announce them as ”image”, and if there is alternative text, then that 
is included too. Now, if - as you claim - applying role="presentation" 
does *not* ”flatten” the img-element-specific src attribute the way it 
flattens the img-element-specific alt attribute, then why is it only if 
the src attribute references a SVG that the grapchic is announced to 
the user? Why isn’t e.g. a JPEG also announced to the user, as an 
image? After all, if the src references a JPEG, it could still be 
announced as an image, to the user?

As for your thinking, it sounds like you consider the referenced SVG 
image of <img src="SVG"> as a ”descendant” of the image element. If if 
this is how the community behind ARIA thinks, then I suggest that the 
ARIA spec is updated with a definition of ”descendant” - in the first 
place where this is reflected so that we can have the same 
understanding of this matter.

Because Web authors as used to e.g. look at DOM inspectors, which never 
shows the DOM of SVGs inside the src attribute of an <img>. The DOM of 
a iframe document is included, but not the DOM of an image source. I 
also tried to check what HTML5 means by ”descendant” and could only 
find that it mind ”child element”. I am also pretty sure that I am not 
alone in thinking that there is a difference between embedding e.g. 
MatML or SVG directly in the HTML source, and referencing them via 
<img>. If ATs are supposed to look into the DOM also of images served 
via <img>, then the alt text rules of HTML5 seem outdated.

>> No doubt, this matter will confuse authors even more w.r.t. to the 
>> effect of role="presentation”.
> 
> I certainly agree with this statement. The presentation role is very 
> confusing, starting with the word, “presentation.” Quoting from the 
> original thread email.

Right now, it is more confusing to me a) whether ARIA considers the SVG 
of an <img> as a ”descendant” and b) whether @src is considered to 
carry ”implicit native role semantics” and thus are disabled by 
role="presentation".

I think, with the name "flatten", the *effect* of the role would come 
more to the front, so that we could clear up misunderstandings faster.

>> 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.
> 
> I disagree. The sub-DOM contents of SVG images apply like any other 
> sub-DOM contents, including shadow DOM Web Components, <iframe> 
> contents, MathML, and more.

May be I am special, but I *think* I am not alone in my thinking. So, 
once again, I suggest that ARIA clarifies what it means by ”descendant” 
and whether @src is part of img’s ”implicit native role semantics”.

>> 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 …
> 
> I’m sorry you’re annoyed, but again, I don’t believe this is pushing 
> any limits of the 1.0 definition. 

Well, I do think that it represents stuff that is not included in 
HTML5’s definition of a (conforming) document.
-- 
leif halvard silli

Received on Tuesday, 4 February 2014 00:43:19 UTC