I believe role="presentation" is allowed on img, see the table here:
http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria

However, <img role="presentation"> is still required to have alt, or one of the other alternatives.

Laura, I assume you meant that an <img> element with role="presentation" should be allowed to not have allt specified. Is that correct?

(In reply to comment #1)
> an <img> element with role="presentation" should
> be allowed to not have allt specified. Is that correct?

The WAI CG doc specifies:

<img> is only valid when at least one of the following is true:

    * @alt is present (empty or non-empty) OR
    * @aria-labelledby is present (non-empty only) OR
    * the <img> is located within a <figure> that has a non-empty <legend> OR
    * @role="presentation"

http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

I'm taking that as a "yes". Thus, requesting expedited processing of this one too.

Assuming the request is:

   "An <img> element with role="presentation" should be allowed to not have alt specified."

...then the request doesn't make sense to me. If we know the image is presentational, surely we equally know that the empty string is appropriate alt text, and it would be inappropriate therefore to annotate the image as missing required alternative text.

Why would we want to allow authors to avoid giving alternative text for images that they know are presentational? Could you give an example of where role=presentation would be appropriate but alt="" would not be?

(I may be wrong in assuming that the request is the above. While it is what Maciej appears to assume the bug is requesting, it doesn't seem, to me, to match the other comments made in this bug. However, I do not understand what the other comments mean. The spec allows any role="" value to be specified when on <img> elements, unless the alt="" value is empty, in which case it is required to be role="presentation".)

(In reply to comment #4)
> Assuming the request is:
> 
>    "An <img> element with role="presentation" should be allowed to not have alt
> specified."
> 
> ...then the request doesn't make sense to me. If we know the image is
> presentational, surely we equally know that the empty string is appropriate alt
> text, and it would be inappropriate therefore to annotate the image as missing
> required alternative text.
> 
> Why would we want to allow authors to avoid giving alternative text for images
> that they know are presentational? Could you give an example of where
> role=presentation would be appropriate but alt="" would not be?

I think the premise of the bug is not that alt="" would be inappropriate, but rather that it would be redundant. Empty alt and role="presentation" will have essentially the same effect in non-visual media, at least in modern UAs. Or to put it another way, it does not seem like there is harm in allowing role="presentation" to appear without alt, at least none that is obvious to me.

(I don't personally feel strongly about this issue, I am just trying to do my best to clarify the intent.)

(In reply to comment #4)

> The spec allows any role="" value to be specified when
> on <img> elements, unless the alt="" value is empty, in which case it is
> required to be role="presentation".)

I believe the bug is about ensuring that all the following minimum variants are allowed ("at least one of the following is true"): 

    1) <img role="presentation" alt="" src="img" > 
    2) <img role="presentation" src="img" >
    3) <img alt="" src="img" >

Ian: Is it your view that all the above are already permitted?

The HTML5 spec text currently says, that there is an exception w.r.t. what roles that are allowed, when a HTML feature has "strong native semantics", but it doesn't clearly say (could be clearer at least), that the consequense of the exception is that only the exact role  that is listed in the table, is permitted:

]]
Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below.
[[

When I say "except where", then I would also expect a "then such an such rules applies".  I think the quote above could be made cleared by adding something like this:

]]
When an element/feature has strong native semantics, then the only that role which is in line with the strong native semantics is permitted.
[[

Or perhaps by changing the title of the second column in that table to say "implicit and permitted role values" instead of only "implicit". 

May be this solves parts of Laura's issue. 

As to your question about whether another role than presentation is thinkable: perhaps CAPTCHAs is a situation where one could potentially use another role than "presentation", even if the alt is emtpy. What is it that permits you to not use whether @role or the alt attribute in the CAPTCHA example in the spec? At the very least, a role="captcha" is something that has been put forward:

http://www.w3.org/mid/9B88E254-B0C5-4024-BF7E-F42A4EB5FF6E@adobe.com

(Another way to solve this bug could be to list the forbidden role values, instead of listning the permitted role values. )

I don't understand why we would make:

   <img role="presentation" src="img">

...valid (and implying alt=""), when we already have:

   <img alt="" src="img">

...which is valid, means the same thing, and implies role="presentation". What is the benefit?

(In reply to comment #7)
> I don't understand why we would make:
> 
>    <img role="presentation" src="img">
> 
> ...valid (and implying alt=""), when we already have:
> 
>    <img alt="" src="img">
> 
> ...which is valid, means the same thing, and implies role="presentation". What
> is the benefit?

Assuming that we agree that both <img alt="" src="img"> and <img ALT="" alt="" src="img"> would be correct, then I agree that it should not be recommended to not supply alt="<emptystring>" in this case. 

I think Steve has been saying that it should never be an error to use role="*" - and in that context we dicussed use cases for when another role than the one the spec currently require for <hn> elements, was correct. (I had to agree with him that other roles than "heading" could bee needed). Thus to say that the presence of role="presentation" loosens the requirement to supply a correct alt attribute, is not how I see it.

The consensus document that Laura cites seems to treat the issue differently: It creates a link between role="presentation"  and a looser requirements w.r.t. to supplying a correct alt="". I guess I have to say that where I stand today, I disagree with the consensus document here.

(In reply to comment #8)
> (In reply to comment #7)

> Assuming that we agree that both <img alt="" src="img"> and <img ALT="" alt="" src="img"> …

Correction:  … both <img alt="" src="img"> and <img ROLE="presentation" alt="" src="img"> …

(In reply to comment #7)
> I don't understand why we would make:
>    <img role="presentation" src="img">
> ...valid (and implying alt=""), when we already have:
>    <img alt="" src="img">
> ...which is valid, means the same thing, and implies role="presentation". What
> is the benefit?

a point to consider:
role="presentation" on  <img> means the browser removes the <img> from
the accessible tree

alt="" is not removed by the browser, its left up to the assistive

tech to remove it from what it presents to the user.

> a point to consider:
> role="presentation" on  <img> means the browser removes the <img> from
> the accessible tree
> 
> alt="" is not removed by the browser, its left up to the assistive
> tech to remove it from what it presents to the user.

That is incorrect. Per HTML5, alt="" does exactly the same thing as role=presentation. The former actually implies the latter.

(In reply to comment #11)
> > a point to consider:
> > role="presentation" on  <img> means the browser removes the <img> from
> > the accessible tree
> > 
> > alt="" is not removed by the browser, its left up to the assistive
> > tech to remove it from what it presents to the user.
> 
> That is incorrect. Per HTML5, alt="" does exactly the same thing as
> role=presentation. The former actually implies the latter.
> 

If the former implies the latter, it seems reasonable to let the latter imply the former. Unless there's some specific harm from markup that says <img role="presentation" src="foo.jpg"> without an alt attribute. (It could be argued that just having more than one way to do it is harmful, but there's other things that there is more than one way to do.)

<img src="foo" alt="bar"> means "I have an image that means bar".
<img src="foo" alt=""> means "I have a presentational image that isn't important".
<img src="foo"> means "I have an important image but I don't know what it is".

From an architectural point of view, this is the semantic layer of HTML. It defines the meaning of the language.

On top of this we can put ARIA, which are a way to adjust the semantics for the AT layer, just like CSS is a way to adjust the semantics for the presentational layer.

So:

<img src="foo" alt="bar" role="baz">
  ...means "I have an image that means bar and whose accessibility role is baz".
<img src="foo" alt="" role="baz">
  ...means "I have a presentational image that isn't important but whose accessibility role is baz".
<img src="foo" role="baz">
  ...means "I have an important image but I don't know what it is except that it is a baz role".

Making alt="" be implied by role="presentation" would IMHO therefore be a layering violation, making the accessibility layer imply semantic meaning at the HTML layer. It would IMHO be analogous to having the CSS or JS layers affect the conformance of markup. I believe doing this would be a design mistake.

Sometimes, language design pales in importance compared to larger goals, such as making a particular action possible, or addressing compatibility issues. However, in this particular instance, it does not appear that adding this hack would actually improve authoring matters at all: it is far easier for authors to say alt="" than role-"presentational". Since this therefore provides no benefit to authors and no benefit to implementors, it seems that language design is relevant, and we should avoid such layering violations.

It would be helpful if Laura (the bug reporter) could confirm that we are talking about what she meant when she filed the bug, though. The original comments don't really match what we're talking about as far as I can tell.

(In reply to comment #11)
> > a point to consider:
> > role="presentation" on  <img> means the browser removes the <img> from
> > the accessible tree
> > 
> > alt="" is not removed by the browser, its left up to the assistive
> > tech to remove it from what it presents to the user.
> That is incorrect. Per HTML5, alt="" does exactly the same thing as
> role=presentation. The former actually implies the latter.


i beg to disagree, in browsers as implemented it is correct.
i am talking about what happens in real world browser implementations now and what happens is as i described.

Sure. But the point here is to improve matters, not stick with the status quo.

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: Accepted
Change Description: no spec change
Rationale:

Looking at the original bug description:

> In the conformance Guidance for conformance checkers section allow
> role="presentation" on img. It is important to be able to convey
> programmatically to assistive technology that an image is presentational and
> not of interest. 

role="presentation" is already allowed on <img>.
It is already possible to programmatically convey to assistive technology that an image is presentational and not of interest. 

Therefore this seems to already be solved.

This bug also had apparently unrelated comments but they were responded to above (in particular in comments 13 and 15).

Adding TrackerIssue keyword as this bug is part of Issue 31

A Change Proposals have been written:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707

Adding TrackerIssue keyword as this bug is part of Issue 31

A Change Proposals have been written:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706

http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0124.html

The bug triage sub-team believes the HTML A11Y TF should take up this bug. Additional notes may follow in a separate comment.

Bug triage sub-team thinks this is fixed. Assigning to Steve to verify fix; if so, please change status to "verified", otherwise ping bug triage sub-team.

(In reply to comment #20)
> Bug triage sub-team thinks this is fixed. Assigning to Steve to verify fix; if
> so, please change status to "verified", otherwise ping bug triage sub-team.

Hi Michael,

This bug isn't fixed as @role="presentation" isn't a part conformance criteria in HTML5. WAI CG recommended that it should be in their "Consensus Resolutions on Text alternatives in HTML 5" document.
http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

This bug is part of Issue 31. The TrackerIssue keyword has already been applied. The Change proposal has been written:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126

(In reply to comment #21)
> (In reply to comment #20)
> > Bug triage sub-team thinks this is fixed. Assigning to Steve to verify fix; if
> > so, please change status to "verified", otherwise ping bug triage sub-team.

> This bug isn't fixed as @role="presentation" isn't a part conformance criteria
> in HTML5. WAI CG recommended that it should be in their "Consensus Resolutions
> on Text alternatives in HTML 5" document.
> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

Laura, 

so far you have not offered any direct response to Ian's resolution in comment #16, other adding tracker request etc.  

Because of this, I find it hard to know whether I agree or disagree that this bug is solved.  I think it could be helpful if you pinpointed the exact things you disagree with in his resolution.

If you could also show a code example, and explain the problems with the way HTML5 currently requires  conformance checkers to check that piece of code, then that would be helpful too.

Thanks.


PS: This is how I understand the conflict betweent the Consensus Document and HTML5:

Per the Consensus Document, then the very presence of role="presentation" - irrespective of empty @alt, non-empty @alt or no alt attribute at all,  would make the <img> valid. 

Whereas, in contrast, HTML5, section 4.8.1.1.14 (Guidance for conformance checkers) fails to list presence of role="presentation" as a condition when it would be permitted to not add the @alt attribute.  (Quote: "A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies:" )

Thus, i suppose you want @role="presentation" to  make <img> elements which lack  any ue of @alt, as valid.

(In reply to comment #16)

Hi Ian,

This bug isn't fixed as @role="presentation" isn't a part conformance criteria
in HTML5. WAI CG recommended that it should be in their "Consensus Resolutions
on Text alternatives in HTML 5" document.
http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

This bug is part of Issue 31. The TrackerIssue keyword has already been
applied. The Change proposal has been written:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > Bug triage sub-team thinks this is fixed. Assigning to Steve to verify fix; if
> > > so, please change status to "verified", otherwise ping bug triage sub-team.
> 
> > This bug isn't fixed as @role="presentation" isn't a part conformance criteria
> > in HTML5. WAI CG recommended that it should be in their "Consensus Resolutions
> > on Text alternatives in HTML 5" document.
> > http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
> 
> Laura, 
> 
> so far you have not offered any direct response to Ian's resolution in comment
> #16, other adding tracker request etc.  
> 
> Because of this, I find it hard to know whether I agree or disagree that this
> bug is solved.  I think it could be helpful if you pinpointed the exact things
> you disagree with in his resolution.
> 
> If you could also show a code example, and explain the problems with the way
> HTML5 currently requires  conformance checkers to check that piece of code,
> then that would be helpful too.
> 
> Thanks.
> 
> 
> PS: This is how I understand the conflict betweent the Consensus Document and
> HTML5:
> 
> Per the Consensus Document, then the very presence of role="presentation" -
> irrespective of empty @alt, non-empty @alt or no alt attribute at all,  would
> make the <img> valid. 
> 
> Whereas, in contrast, HTML5, section 4.8.1.1.14 (Guidance for conformance
> checkers) fails to list presence of role="presentation" as a condition when it
> would be permitted to not add the @alt attribute.  (Quote: "A conformance
> checker must report the lack of an alt attribute as an error unless one of the
> conditions listed below applies:" )
> 
> Thus, i suppose you want @role="presentation" to  make <img> elements which
> lack  any ue of @alt, as valid.

Yes, per WAI CG's Doc:

<quote>

NOTE: These recommendations assume that ARIA features referenced in this document are included in HTML 5.

   1. <img> is only valid when at least one of the following is true:
          * @alt is present (empty or non-empty) OR
          * @aria-labelledby is present (non-empty only) OR
          * the <img> is located within a <figure> that has a non-empty <legend> OR
          * @role="presentation"
      NOTE: The intent here is twofold.
         1. to allow different methods to be used for providing short text alternatives (e.g. ALT or LABELLEDBY or LEGEND)
         2. to note that short text alternatives are not needed for content that is "presentational" as defined by ARIA
   2. That
          * the proper use of @role="presentation" be taken from ARIA 1.0
          * and that an <img> without a @role attribute is assumed to be the equivalent of <IMG @role="img"> (and would follow the rules in #1 above)

      NOTE: 'Presentation' should not be defined to be broader than what is defined by ARIA
   3. For cases in which it is appropriate for user agents to ignore the presence of an image (e.g. when the image is used for decoration, for formatting, or when the image is invisible), one or both of the following may be used:
          * @role="presentation"
          * @alt="" (also see (4))

      INTENT: That it is VALID to use either ROLE and/or ALT="" to mark "presentational" content.
   4. alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)

      INTENT: To encourage the use of role=presentation - by encouraging (but not requiring) its use even when alt="" is used.
   5. We suggest new mechanisms for short text alternatives (e.g. aria-labelledby, <legend>) should be capable of handling structured content. Our primary concern is that short text alternatives be able to support inline text structure, such as abbreviations, language changes, emphasis, etc.

      RATIONALE: It would be helpful for the short alternative text mechanism to support structured text.

</quote>

http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

Thanks. Formally, you have now responded to Cooment #16. The exact point in you change proposal which speaks to this bug, is found under the heading called role="presentation" Attribute.

 http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#role.3D.22presentation.22_Attribute

That section does indeed confirm that you want <img role="presentation"  src="foo" /> to be valid, despite that there is no @alt attribute inside.  Thus, this this bug relates to the question about how ARIA is permitted to be used inside HTML5, this bug seems also very related to bug 10066 - "replace section 3.2.6 with the alternative spec text provided (ARIA)".  I think that the correct context to solve this problem, should be the context of 10066.

It surprises me that you want the lack of @alt to be valid, since the entire working group earlier have heard you explain how an <img> in lack of @alt  should not in any way be considered valid.

Below follows my evaluation of the 3 arguments you use in the Change Proposal:


1st argument:  ]] It is specified and implemented to do what alt="" is specified to do. [[

    Evaluation:  This is argument doe not hold true, because:

     (1) role="presentation" has no effect in user agents which do not support ARIA. 
     (2) Whenever the @alt attribute is non-empty, then role="presentation" will - in ARIA supporting user agents, overrule the @alt: to ARIA supporting AT, then for example this element: <img alt="foo" role="presentation">, will not be presented to the user. Whereas the user not accessing the page via AT will, in case the @src attribute is incorrect or the user agent does not have image display, willl get to see the @alt text as fallback. 

3rd argument: ]] As per the rules specified in current spec pertaining to its use [24], the use of role="presentation" is not dis-allowed on the img element it is in fact stated that it is the only role that can be applied to an img that has an alt="", so you can do this: <img role="presentation" alt=""> and no where in the aria section [24] does it state you can't do this: <img role="presentation"> but it will result in a conformance error, which appears both incongruous and illogical. [[ 

     Evaluation: I feel that 3rd argument, except for emphasizing logic, is just a variant of the 1st argument. However, since 1st argumetn does not hold true, I won't comment it anymore.


2nd argument: It is non specific, it works on all elements.

     Evaluation: this, in my view, is the best argument  that you offer. In fact, I think it is a quite good argument in favor of allowing @role="presentation" also on images that *does* have @alt text. For instance, it is thinkable that Ian could turn the ASCII art of his e-mail signature into an image, and insert it into HTML documents with the IMG element, using the ascii art as fallback content inside the @alt attribute, like this:

<img src="cat-image-signature" role="presentation"  alt="
  )\._.,--....,'``.    fL
 /,   _.. \   _\  ;`._ ,.
`._.-(,_..'--(,_..'`-.;.'
" >

However, the current editors draft *does* allow role="presentation" even when the @alt contains text. Hence the 2nd argument really is largly already met. 


Conclusions:

(1) If an author *only* wants to focus on users which use ARIA supporting AT to read web pages, then I agree that adding role="presentation" to an image which is lacking @alt text, could be considered enough - to inform the author that the page lacks @alt will not offer anything.  Just as the spec currently operates with the loophole that authors may drop the @alt in private communication, I think it is logical that one could also drop the @alt in favor of role="presentation" whenever one knows that the consumer(s) use ARIA supporting AT. However, you don't argue in favor of any such ARIA related "loophole", but argue generallly. Your opposition agains the private communication loophole, which I too oppose, does not make it logical that you want anther loophole.

(2) Thus, having considered your arguments,  the only thing left is that if the author removes the @alt attribute, then the addition of @role="presentation" does not affect the validity of the <img>. But considering your previous strongly voiced argumentation in favor of saying that no <img> element should be considered valid, unless it contains the @alt attribute, I think you should reevaluate your position regarding @role="presentation" - and thus also remove that point from your change proposal.

(In reply to comment #24)
> (In reply to comment #22)

> > Thus, i suppose you want @role="presentation" to  make <img> elements which
> > lack  any ue of @alt, as valid.
> 
> Yes, per WAI CG's Doc:
> 
> <quote>
> 
> NOTE: These recommendations assume that ARIA features referenced in this
> document are included in HTML 5.
> 
>    1. <img> is only valid when at least one of the following is true:
>           * @alt is present (empty or non-empty) OR
>           * @aria-labelledby is present (non-empty only) OR
>           * the <img> is located within a <figure> that has a non-empty
> <legend> OR
>           * @role="presentation"
>       NOTE: The intent here is twofold.
>          1. to allow different methods to be used for providing short text
> alternatives (e.g. ALT or LABELLEDBY or LEGEND)

Strictly speaking, the first intent is not met: HTML5 does not say that you can skip using @alt, as long as @aria-labelledby is present. However, I have not seen that you have raised any issue/bug about this.

>          2. to note that short text alternatives are not needed for content
> that is "presentational" as defined by ARIA

The second intent is met.


>    2. That
>           * the proper use of @role="presentation" be taken from ARIA 1.0
>           * and that an <img> without a @role attribute is assumed to be the
> equivalent of <IMG @role="img"> (and would follow the rules in #1 above)
> 
>       NOTE: 'Presentation' should not be defined to be broader than what is
> defined by ARIA

I think *you* are stretching ARIA: Your change proposal says about @role="presentation" that: It is specified and implemented to do what alt="" is specified to do.
However, ARIA does not say that role="presentation" does what an empty  @alt="" does. And empty @alt does somet of what role="presentation" does. But role="presentation" does not affect how the <img> element is presented to users which do not use AT.


>    3. For cases in which it is appropriate for user agents to ignore the
> presence of an image (e.g. when the image is used for decoration, for
> formatting, or when the image is invisible), one or both of the following may
> be used:
>           * @role="presentation"
>           * @alt="" (also see (4))
> 
>       INTENT: That it is VALID to use either ROLE and/or ALT="" to mark
> "presentational" content.

This intent is met: you *can* have text inside the @alt attridbute *and* simultaneously use role="presenation".  I believe that *this* is the *real* intent that the Consensus Document was thinking about. (Perhaps you or someone could ask some of those who authored the document?)

 The only thing that you can't do is that you can't completely ommit the @alt attribute. But I do not understand why you want that to be valid.  And I am not certain that the Consensus Document wants it either.

>    4. alt="" WITHOUT an accompanying role="presentation" triggers a
> non-critical validator warning recommending use of role="presentation" (but
> @alt="" remains technically valid)
> 
>       INTENT: To encourage the use of role=presentation - by encouraging (but
> not requiring) its use even when alt="" is used.

This is *not* met. However, you haven't raised any issue/bug about it either, or have you?

[ snip ]

(In reply to comment #26)
> (In reply to comment #24)
> > (In reply to comment #22)

> >    4. alt="" WITHOUT an accompanying role="presentation" triggers a
> > non-critical validator warning recommending use of role="presentation" (but
> > @alt="" remains technically valid)
> > 
> >       INTENT: To encourage the use of role=presentation - by encouraging (but
> > not requiring) its use even when alt="" is used.
> 
> This is *not* met. However, you haven't raised any issue/bug about it either,
> or have you?


The authors of the ARIA 1.0 specification have created an XHTML 1.1 based DTD.  One should think that if it was crucial that an <img> without any @alt attribute was considered valid, whenever the <img> has role="presentation", then the ARIA 1.0 authors would have offered a DTD which allowed you to ommit the @alt attribute when role="presentation" is present. 

However, as you can verify for yourself, by pasting the the mini-document below into the validator at http://validator.w3.org, the DTD for XHTML1.1 +ARIA 1.0, does not allow you to do that. Thus either the Consensus Document is simply not specific enough to avoid all possible confusion about what it suggests (that's what I think) or they simply go further than the ARIA 1.0 spec allow itself to go.

Docuent Example with ARIA 1.0 DTD:


<!DOCTYPE html SYSTEM "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head><title></title></head><body>

<p> <img src="foo" role="presentation" /></p>
    
</body></html>