[Bug 21579] Empty @alt should not imply role="presentation" if the <img> has @usemap

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21579

--- Comment #5 from steve faulkner <faulkner.steve@gmail.com> ---
(In reply to Leif Halvard Silli from comment #3)
> (In reply to comment #2)
> 
> > Can you provide a concise description of the chnages you think need to be
> > made?
> 
> Concise change proposals:
> 
>    (1) Make it an authoring error for img elements with the usemap attribute
> set to leave the @alt attribute empty.
> 
>    (2) Say that Aria-hidden="true" on on an img element with the usemap
> attribute set, should disable the entire image map (including aria links).
> (Currently, in VoiceOver on OSX 10.7, setting @hidden on the img element,
> disables the image map, whereas setting aria-hidden="true", does not disable
> it. (Note that the very <map> element should not be disabled - as it could
> be used by another <img> element - it is the very <img> with usemap that
> should be disabled.
> 
>    NOTE: Current thinking is (I believe) that role="presenation" is not
> supposed to impact interactive elements/content. So my proposals regarding
> role=presentation are nullfied. However the thinking I applied to
> role="presentation" is still valid if aria-hidden="true" is set for the img
> element.
> 
> Justification:
> 
>    This bug is much older than from April 2013 ... Thinking it through
> today, this is how I see it:
> 
>    An analogy to what an img@usemap with an empty @alt represents, 
>    would be an img link where the alt is empty: 
> 
>    <a href=foo><img src="abc" alt="" /></a>
> 
>    In an image link, if the <img> element has empty alt, then the
>    img *does* have presentaton role. However, it is an authoring
>    error to have empty alt inside an image link, when the image is
>    the link’s sole content.
> 
>    Now, an img element with the usemap attribute set, is a bit tricky to
> analyse: It *is* an interactive element. And, w.r.t. CSS, then its borders
> *are* supposed to become green if you do  img:link{border:green solid 3px;}.
> (Last check, only some browsers implemented it.) However, from ARIA’s point
> of view, an <img> with usemap, does not have link role - the link role is
> instead linked (sic) to the area elements.
> 
>    Since I filed this bug, I believe there has been some clarification with
> regard to whether role="presentation" should have an effect on interactive
> content. Namely, I think that role="presentation" on interactive content, is
> not supposed to have any effect on interactive elements. However, it still
> stands that if you e.g. add @hidden to the <img>, the entire image map
> should be disabled. And thus, it follows that the same should happen if you
> add aria-hidden="true" to the <img>.

Hi Leif, 

>    (1) Make it an authoring error for img elements with the usemap attribute
> set to leave the @alt attribute empty.

sounds reasonable, will do

>    (2) Say that Aria-hidden="true" on on an img element with the usemap
> attribute set, should disable the entire image map (including aria links).
> (Currently, in VoiceOver on OSX 10.7, setting @hidden on the img element,
> disables the image map, whereas setting aria-hidden="true", does not disable
> it. (Note that the very <map> element should not be disabled - as it could
> be used by another <img> element - it is the very <img> with usemap that
> should be disabled.
> 

this sounds like this is an implementation issue, setting aria-hidden on an
<img> should remove the img from the acc tree, so the image map should not be
represented in the acc tree (for the for the aria-hidden <img>. will look into
it, but suspect the HTML spec is not the place for this to be specified.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 8 December 2013 10:42:21 UTC