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

Please be careful not to confuse the future direction and discussion of ARIA with specific implementations. I do need to address a few points inline though.

On Feb 2, 2014, at 8:22 AM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 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? You’re starting two major OS releases out-of-date. As I requested Steve do several years ago when he started the HTML5 Accessibility site, please always test the most current versions of software, including nightly builds if available.

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

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

Did I read this correctly?

> ~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?”  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

>>> 	• 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, which in this case may be marked as presentational. 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.

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.

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

>>> This topic was originally raised by a WG member, Microsoft Member Representative, Kelly Ford. 
>>> 
>>> Quoting Kelly from https://www.w3.org/WAI/PF/Group/comments/details?comment_id=166
>>>> We believe that role=presentation is problematic, beginning with the word "presentation", continuing on to possible misinterpretation of what should be presentation, and possible mis-use of role=presentation by authors who want to avoid extra effort, thereby hiding real information from AT who respect that role.
>>> End quote.



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

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

James

Received on Monday, 3 February 2014 19:04:50 UTC