some background: Firefox exposes image accessible regardless @alt attribute so it doesn't equivalent to role="presentation". the only difference is if the image has empty @alt attribute and accessible name is not specified otherwise (like @title attribute) then accessible name is null (what means AT shouldn't try to fix it).

that's why I think we don't need to have two items. Probably all we need is to mention this feature in img name computation part like if @alt is presented and empty value and name is not provided otherwise then name is null (AT shouldn't try to repair it).

or alternatively we can add an item like:

IA2/MSAA column:
Name: if @alt attribute is presented but empty and no name provided otherwise then name is NULL, return value is S_FALSE.

Sounds good? Which one do you like more?

(In reply to comment #1)
> some background: Firefox exposes image accessible regardless @alt attribute
> so it doesn't equivalent to role="presentation". the only difference is if
> the image has empty @alt attribute and accessible name is not specified
> otherwise (like @title attribute) then accessible name is null (what means
> AT shouldn't try to fix it).
> 
> that's why I think we don't need to have two items. Probably all we need is
> to mention this feature in img name computation part like if @alt is
> presented and empty value and name is not provided otherwise then name is
> null (AT shouldn't try to repair it).
> 
> or alternatively we can add an item like:
> 
> IA2/MSAA column:
> Name: if @alt attribute is presented but empty and no name provided
> otherwise then name is NULL, return value is S_FALSE.
> 
> Sounds good? Which one do you like more?

Hi alex, I don't mind merging the 2 always good to simplify. Note the HTML5 spec requires that an img with empty alt has a role=presentation [1] but this requirement is at risk for CR as no browsers have implemented it. I am unsure of the appropriateness of it anyway as the use of alt="" as a flag to indicate an img should be ignored by AT is widely supported already and it has the advantage of the img still being in the acc tree so AT could expose to users via preference if desired.



[1] http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics

(In reply to comment #1)
> some background: Firefox exposes image accessible regardless @alt attribute
> so it doesn't equivalent to role="presentation". the only difference is if
> the image has empty @alt attribute and accessible name is not specified
> otherwise (like @title attribute) then accessible name is null

Firefox is in good company when it uses the @title as the accessible name *both* when @alt omitted as well as when @alt is empty, see my test page from last year: 

     http://www.malform.no/testing/html5/img-role-vs-alt/

Under the circumstances tested in that page, there were almost zero difference between empty @alt and omitted @alt. In the test page, explicitly adding @role="img" to the <img>, made some browsers (the Webkit/Chrome based ones plus Presto) look at the file name of the image even if @alt was empty.
   
> (what means
> AT shouldn't try to fix it).

I disagree that this is what it means. OK, if you define "to fix it" "looking into the file name of the image in order to try to fix it", then I agree. However, in my opinion to fetch the accessible name from @title is a repair technique (or a try to fix it, as you call it), not? If we can agree on terminology, then perhaps we agree. :-)

In my test page above, VoiceOver+Safari would attempt look at the filename even when @title was present. But VoiceOver+Safari was also the only AT that would look into the file name under *any* of the tested circumstances.

> that's why I think we don't need to have two items. Probably all we need is
> to mention this feature in img name computation part like if @alt is
> presented and empty value and name is not provided otherwise then name is
> null (AT shouldn't try to repair it).

What if the img element has empty @alt in combination with explicit role="img"?

   <img role="fileName" alt=""/>

> or alternatively we can add an item like:
> 
> IA2/MSAA column:
> Name: if @alt attribute is presented but empty and no name provided
> otherwise then name is NULL, return value is S_FALSE.
> 
> Sounds good? Which one do you like more?

Btw, Steve seems to think that bug 12591 relates to this bug - and I agree, but I have not concluded how ... ;-)

I am happy if the empty @alt and role="presentation" are separated. That is: I am happy if empty @alt stops being promoted as synonymous with role="presentation".

(In reply to comment #3)

> What if the img element has empty @alt in combination with explicit
> role="img"?
> 
>    <img role="fileName" alt=""/>

Typo. Correct:

    <img role="img" alt="" src="fileName" />

(In reply to comment #2)

> Hi alex, I don't mind merging the 2 always good to simplify. Note the HTML5
> spec requires that an img with empty alt has a role=presentation [1] but
> this requirement is at risk for CR as no browsers have implemented it. I am
> unsure of the appropriateness of it anyway as the use of alt="" as a flag to
> indicate an img should be ignored by AT is widely supported already and it
> has the advantage of the img still being in the acc tree so AT could expose
> to users via preference if desired.

Ok, how do we want to proceed for now? i.e. should we copy what HTML5 says or should we write down what the browsers do?

(In reply to comment #4)
> (In reply to comment #3)
> 
> > What if the img element has empty @alt in combination with explicit
> > role="img"?
> > 
> >    <img role="fileName" alt=""/>
> 
> Typo. Correct:
> 
>     <img role="img" alt="" src="fileName" />

in that case Firefox says the image accessible name is empty on demand and AT shouldn't repair it like to use its src attribute. In case of

<img role="img" src="fileName" />

Firefox says there's no name and AT might want to use src as name alternative. But probably nobody does it.

(In reply to comment #6)

> >     <img role="img" alt="" src="fileName" />
> 
> in that case Firefox says the image accessible name is empty on demand and
> AT shouldn't repair it like to use its src attribute. In case of

In other words, there is no difference between an @alt attribute that is empty and an @alt attribute that is filled with whitespace: Both are empty, from a user’s point of view, at least.

> <img role="img" src="fileName" />
> 
> Firefox says there's no name and AT might want to use src as name
> alternative. But probably nobody does it.

VoiceOver+Safari does use @src. Or, if it is child of <a>, it under some conditions uses @href.

(In reply to comment #5)
> (In reply to comment #2)
> 
> > Hi alex, I don't mind merging the 2 always good to simplify. Note the HTML5
> > spec requires that an img with empty alt has a role=presentation [1] but
> > this requirement is at risk for CR as no browsers have implemented it. I am
> > unsure of the appropriateness of it anyway as the use of alt="" as a flag to
> > indicate an img should be ignored by AT is widely supported already and it
> > has the advantage of the img still being in the acc tree so AT could expose
> > to users via preference if desired.
> 
> Ok, how do we want to proceed for now? i.e. should we copy what HTML5 says
> or should we write down what the browsers do?

write down what browsers do in first instance

Steve, you want to take this into HTML-in-ARIA / AAM ??