This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12590 - @role=presentation for IMG should also require that @title is empty
Summary: @role=presentation for IMG should also require that @title is empty
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P3 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/content-...
Whiteboard:
Keywords:
Depends on: 8171
Blocks: 10066
  Show dependency treegraph
 
Reported: 2011-05-03 17:35 UTC by Leif Halvard Silli
Modified: 2012-01-13 18:39 UTC (History)
10 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2011-05-03 17:35:52 UTC
The #table-aria-strong table currently says that

]]
       img element whose alt attribute's value is empty
   = presentation role    [[

There seems to be agreement (see message from Richard [1]) that, in addition to @alt being empty, the @title attribute must also be absent or empty.  We also have a disputed Decision which says that a non-empty @title should be counted as equal to a non-empty @alt: Even if the Decision is disputed, the Decision anyhow supports the view that a non-empty @title makes the IMG non-presentational. AT behaviour also supports this view - see JUSTIFICATION sectoin below.

Thus, please update the  #table-aria-strong table to say something like the following:

]]
       img element whose alt attribute's value is empty
       and whose @title attribute is empty or omitted
   = presentation role    [[

JUSTIFICATION:

It is too simplistic to draw a direct link beween empty @alt and role=presentation. As explained in bug 12587, the effect of applying <img title="Lorem ipsum" role=presentation> is - in praxis - different from using an empty <img title="Lorem ipsum" alt="">: In the former case the IMG is completely hidden. In the latter case, the @title might be presented to the AT user.

For example VoiceOver treats <img title="Lorem ipsum" alt=""> as non-presentational, due to the presence of @title, which it reads to the user. Also, inside links, the IMG's title is used by VoicOver (and probably also several other AT, see Steve's research from 2005 [2] ) if there is no @alt. The same goes for @alt in <area> elmements, where it seems VoiceOver actually prefers @title over @alt.

Bug 12587 points to an example in the wild [3] which examplifies the issue: 

<a href="[link]">
  <img src="http://images.apple.com/support/iknow/images/i_call_adv.png"
   alt=""  title="Apple Support Express Lane">
</a>

[1] http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0042
[2] http://www.paciellogroup.com/resources/articles/WE05/forms.html
[3] http://support.apple.com/kb/HT3669
Comment 1 Leif Halvard Silli 2011-05-10 12:41:31 UTC
Note that the spec itself shows 2 code examples where an IMG element has an empty @alt in combination with non-empty @title. 

For the first example, see section '4.8.1.1.6 A graphical representation of some of the surrounding text':

]]
   In many cases, the image is actually just supplementary, and its presence merely reinforces the surrounding text. In these cases, the alt attribute must be present but its value must be the empty string. 


   A flowchart that repeats the previous paragraph in graphical form:

    [ code example: ]
      <p>The network passes data to the Tokenizer stage [snip] </p>
      <p><img src="[URL-snip:] parsing-model-overview" alt=""></p>

   In these cases, it would be wrong to include alternative text that consists of just a caption. If a caption is to be included, then either the title attribute can be used, or the figure and figcaption elements can be used. In the latter case, the image would in fact be a phrase or paragraph with an alternative graphical representation, and would thus require alternative text.

    <!-- Using the title="" attribute -->
    [ code example: ]
      <p>The network passes data to the Tokenizer stage [snip] </p>
      <p><img src="[URL-snip:] parsing-model-overview" alt=""
                title="Flowchart representation of the parsing model."></p>

[[ http://dev.w3.org/html5/spec/embedded-content-1#a-graphical-representation-of-some-of-the-surrounding-text


For the second example, see directly under '4.8.1 The img element', where we find this example: 

]]  

  <aside><img src="fluffy.jpg" alt="" title="Fluffy"></aside> 

[[http://dev.w3.org/html5/spec/embedded-content-1#the-img-element

Note as well, that according to the Fangs, the JAWS emulator, then not only VoiceOver, but JAWS too will treat those images as non-presentational. 
Fangs: http://sourceforge.net/projects/fangs
Comment 2 Leif Halvard Silli 2011-05-10 12:50:05 UTC
I suppose that this bug should be seen as blocking bug 10066.
Comment 3 steve faulkner 2011-05-10 13:09:30 UTC
(In reply to comment #1)

> Note as well, that according to the Fangs, the JAWS emulator, then not only
> VoiceOver, but JAWS too will treat those images as non-presentational. 
> Fangs: http://sourceforge.net/projects/fangs

the reason why voiceover does what it does is that the default mapping has not been implemented
try this and check with the mac accessibility inspector

<img src="x" role="presentation" title="poot">

The img gets removed from the accessibility tree. 

fangs does not emulate JAWS faithfully in many aspects.
try it WITH JAWS, you will get the same result when role=presentation is used the element is removed form the accessibility tree no information about the img is passed to a11y APIs

if you don't think this is the correct behaviour, file a bug against wai-aria 1.0
Comment 4 Leif Halvard Silli 2011-05-10 13:57:54 UTC
(In reply to comment #3)
> (In reply to comment #1)
> 
> > Note as well, that according to the Fangs, the JAWS emulator, then not only
> > VoiceOver, but JAWS too will treat those images as non-presentational. 
> > Fangs: http://sourceforge.net/projects/fangs
> 
> the reason why voiceover does what it does is that the default mapping has not
> been implemented
> try this and check with the mac accessibility inspector
> 
> <img src="x" role="presentation" title="poot">

That is: they don't read the @title in that case? Do you have a list of AT which behave different from VoiceOver? 

I have checked your table with 'Screen reader software support for the TITLE attribute' from 2005, and for some reason, for the IMG element it says "not tested":
http://www.paciellogroup.com/resources/articles/WE05/forms.html

> The img gets removed from the accessibility tree. 
> 
> fangs does not emulate JAWS faithfully in many aspects.
> try it WITH JAWS, you will get the same result when role=presentation is used
> the element is removed form the accessibility tree no information about the img
> is passed to a11y APIs

According to Fangs. then @title is read as the text of the img. So Fangs is wrong then, you say, when it gives this impression of JAWS?  However, the presentation of what Jaws does is not complete merely by looking at a single IMG: What about the example from the Apple web side inside comment #0 ? Does Jaws read that @title as the link text of that link? 

> if you don't think this is the correct behaviour, file a bug against wai-aria
> 1.0

Can you point to the fragment in WAI-ARIA19 which it would be relevant to file a bug against?

I am reluctant to file anything against WAI-ARIA10, for the following 3 reasons:

* Firstly, I don't see how I can file a bug against WAI-ARIA 1.0 when the issue is HTML5. 
* Secondly, I filed this bug because you asked me to  - I have already filed another bug that relates to ARIA implementation in HTML (http://www.w3.org/TR/html-aapi/)  - see bug 12587. 
* Thirdly, one of the previous editors of WAI-ARIA, Richard, agrees with me that an IMG with a non-empty @title in combo with a empty @alt *is* non-presentational: http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0042  Though he is very clear in that message, I have also given my intepretation of what he said, upfront, and he has not taken his statement back or refined it: http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0047

Frankly, it is difficult to  read what you above and *not* think about your attitude towards @title in general: It would fit very well into your picture of how things should be, if an empty @alt would make the @title inaccessible.

Note that this bug is not about what is *valid*. It is about what implicit *role* an image with a non-empty @title in combination with an empt @alt does get.
Comment 5 steve faulkner 2011-05-10 14:12:59 UTC
(In reply to comment #4)
>That is: they don't read the @title in that case? Do you have a list of AT
>which behave different from VoiceOver? 

correct, any AT that use an accessibility API to convey image information.

>According to Fangs

forget about fangs it is of no use in this context.

>I have checked your table with 'Screen reader software support for the TITLE
>attribute' from 2005, and for some reason, for the IMG element it says "not
>tested":
>http://www.paciellogroup.com/resources/articles/WE05/forms.html

thats because i didn't get around to testing it at the time.

>Note that this bug is not about what is *valid*. It is about what implicit
>*role* an image with a non-empty @title in combination with an empt @alt does
>get.

as specced it gets no role.
Comment 6 Leif Halvard Silli 2011-05-10 14:17:14 UTC
(In reply to comment #5)

> >Note that this bug is not about what is *valid*. It is about what implicit
> >*role* an image with a non-empty @title in combination with an empt @alt does
> >get.
> 
> as specced it gets no role.

Hence this bug.
Comment 7 Leif Halvard Silli 2011-05-10 14:20:26 UTC
(In reply to comment #5)
> (In reply to comment #4)
> >That is: they don't read the @title in that case? Do you have a list of AT
> >which behave different from VoiceOver? 
> 
> correct, any AT that use an accessibility API to convey image information.

But you have, according to what you write below, no tests which show this.

> >I have checked your table with 'Screen reader software support for the TITLE
> >attribute' from 2005, and for some reason, for the IMG element it says "not
> >tested":
> >http://www.paciellogroup.com/resources/articles/WE05/forms.html
> 
> thats because i didn't get around to testing it at the time.

So you actually have *no* documentatation of the most important issue.

You also  "forgot" to answer what happens to the Appple web site example in Comment #0. Giving that IMG the role=presentation would take away the link text from the AT user.
Comment 8 Martin Kliehm 2011-05-10 15:36:36 UTC
Bug-triage sub-team adding the a11yTF keyword because this issue is already discussed in the TF and related to ongoing work regarding @alt validation.
Comment 9 Leif Halvard Silli 2011-05-10 18:32:35 UTC
WAI-ARIA editor and VoiceOver developer James Craig's personal opinion: http://lists.w3.org/Archives/Public/wai-xtech/2011May/0013.html

Excerpt:

]]
In my opinion, the presentation state would only apply if one of the following were true:

 the author explicitly provided a role of presentation on the img tag, <img role="presentation">
 the host language labeling mechanism (in this case @alt) equaled an empty string, *AND* the ARIA text alternative computation [1] equaled an empty string.

[ snip ]

1. ARIA text alternative computation: http://www.w3.org/TR/wai-aria/complete#textalternativecomputation
[[

My comment: 

1) The ARIA text alternative computation does count in the @title attribute.
2) James's comment supports the view I have expressed by filing this bug.
Comment 10 Leif Halvard Silli 2011-05-10 19:38:11 UTC
(In reply to comment #5)

So, I tested JAWS 12. 

SUMMARY: Except in the third test below, JAWS does *not* implement that empty alt="" equals role="presentation".

= Tests and test results. =

== 1st part: pure image tests==

<!--empty alt-->
<img src=i alt="" aria-label="Lorem. " title="Ipsum.">
JAWS: doesn't present img to user, despite the @aria-label, which it - according to ARIA text alternative computation rules, should have read.

<!--whitespace in alt-->
<img src=i alt="      " title="Ipsum.">
JAWS: doesn't present img to user, despite that the @alt is filled with white-space and thus is non-empty.

<!--whitespace in alt + aria-label -->
<img src=i alt="       " aria-label="Lorem." title="Ipsum.">
JAWS: reads the @aria-label. So in this, single case, the non-empty @alt is interpreted equal to role=presentation.


==2nd part: img inside anchor element==

<!--empty alt-->
<a href=l><img src=i alt=""     title="Lorem Ipsum."></a>
JAWS: despite the empty @alt, it reads the @title as the link text. (It says "link graphic: text".)


<!--whitespace in alt-->
<a href=l><img src=i alt="        " title="Lorem Ipsum."></a>
JAWS: doesn't present the link and doesn't present the img. Total failure, in my view.

<!--whitespace in alt + aria-label -->
<a href=l><img src=i alt="       " aria-label="Lorem" title="Ipsum."></a>
JAWS: The aria-label is read as the link text. (It says "link graphic: text")
Comment 11 Leif Halvard Silli 2011-05-10 19:44:07 UTC
(In reply to comment #10)

I'm sorry. The results are correct. But my comments were sometimes meaningless. Please look away from my interpretative comments and read the results. The main conclusion, that JAWS doesn't really implement what HTML5 says about empty @alt still stands.
Comment 12 Leif Halvard Silli 2011-05-10 22:23:35 UTC
(In reply to comment #0)

> Thus, please update the  #table-aria-strong table to say something like the
> following:
> 
> ]]
>        img element whose alt attribute's value is empty
>        and whose @title attribute is empty or omitted
>    = presentation role    [[


Updated request, based on input from James Craig: http://lists.w3.org/Archives/Public/wai-xtech/2011May/0035

THE NEW REQUEST: Please update the #table-aria-strong table to give the following conditions for when an IMG can be seen as having presentation role:

]]
        img element whose alt attribute's value is empty
        and whose ARIA text alternative computation [1]
        equals an empty string
        [1] http://www.w3.org/TR/wai-aria/complete#textalternativecomputation

    = presentation role    [[

Note: I don't mind that @title is mentioned especially, howeve to point to the ARIA text alternative computation means that @title is formally covered.
Comment 13 steve faulkner 2011-05-11 09:05:41 UTC
Hi leif I am closing this bug marking as invalid since it is not a bug against the HTML mapping guide, but against the HTML5 specification. If you want to re-open the bug please formulate your bug in relation to the HTML api mapping document.
Comment 14 steve faulkner 2011-05-11 09:14:38 UTC
(In reply to comment #11)
> (In reply to comment #10)
> 
> I'm sorry. The results are correct. But my comments were sometimes meaningless.
> Please look away from my interpretative comments and read the results. The main
> conclusion, that JAWS doesn't really implement what HTML5 says about empty @alt
> still stands.

It is not expected the AT will implement the mapping of alt="" to role=presentation, that happens or not in the browser, the AT looks at the accessibility tree provided via the a11y API in the browser.

It is not dispated that the mapping of role=presentation to alt="" has NOT been implemented in any browser yet, but it has been defined in HTML5.

so your results for JAWS are wholely expected.
Comment 15 Leif Halvard Silli 2011-05-11 10:55:58 UTC
sorry. As evident elsewhere, this bug was intended as filed against the main spec and not against the a11y api spec.
Comment 16 Leif Halvard Silli 2011-05-11 13:09:12 UTC
(In reply to comment #3)

> <img src="x" role="presentation" title="poot">

Please partly ignore my reply in comment #4. I was responding to what I think you said rather than what is actually said. In this case, I did not realize that you placed 'role=presentation' inside the image ... 

Correct response: I don't understand how that example is relevant to the issue. Of course the AT should ignore @title - and anything else - inside the IMG if the IMG has role=presentation, there is no doubt about that (provided we accept what ARIA 1.0 specifies.)

The issue dealt with in this bug is whether @title should be ignored when the alt="" is empty. If AT treats empty alt="" as a synonym for role="presentation" - as you suggest and as the HTML5 spec suggests, then we force AT to ignore the @title in cases such as this  one, where looking at the @title could have helped creating a useful link text: 

<a href=l ><img src=foo alt="" title="Lorem ipsum" /></a>

(In reply to comment #14)

> It is not dispated that the mapping of role=presentation to alt="" has NOT been
> implemented in any browser yet, but it has been defined in HTML5.
> 
> so your results for JAWS are wholely expected.

I read your comment about JAWS as something you presented in support of the HTML5 specification's claim that empty alt="" should be seens as synonymous with role="presentation".  Given that you interpreted this bug as filed against the HTML A11Y API Guidelines, it all became wrong.

Let it be clear: this bug is about the isssue that it is a bug of HTML5 to treat empty @alt="" as a synonym for role="presentation". It is a bug because it is not in line with WAI-ARIA 1.0's alternative text computation rules: http://www.w3.org/TR/wai-aria/complete#textalternativecomputation

Also, if you disagree with WAI-ARIA 1.0, wanting it to treat empty alt="" as equal to role="presentation", then you should file a bug against WAI-ARIA 1.0.
Comment 17 Michael[tm] Smith 2011-08-04 05:00:46 UTC
mass-moved component to LC1
Comment 18 Michael[tm] Smith 2011-11-21 22:47:53 UTC
posted a message to the a11y TF list asking for feedback on this request -
http://lists.w3.org/Archives/Public/public-html-a11y/2011Nov/0137.html
Comment 19 Ian 'Hixie' Hickson 2011-12-02 18:03:33 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: You can have a perfectly presentational image (alt="") which still has a caption (title="..."). So, no.
Comment 20 steve faulkner 2012-01-13 09:56:31 UTC
removed a11y keywords as is resolved wontfix and has not been escalated