Open Bug 1700174 Opened 4 years ago Updated 4 years ago

Firefox ignores alt="" for images if title is supplied

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
Firefox 86
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: barry, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Steps to reproduce:

Visit this test page: https://www.tunetheweb.com/experiments/img-title/which has the following:
<img alt="" title="this is a title" src="isnotfound.jpg">

Actual results:

The broken image icon and title is not displayed because of the blank alt (I'm not sure if this is correct or if the alt="" means it shouldn't be displayed).

However the bigger concern is the accessibility tree IS including the image with the title as the accessible name. alt="" is not the same as no alt, and is an explicit signal to not add to the accessibility tree, so this seems incorrect to behaviour to me. It is also inconsistent to what is displayed visually.

Expected results:

Firefox should not have added the image with alt="" to the accessibility tree.

And I'm unsure if it should have shown a broken image - neither Chrome nor Safari shows the broken image either so maybe this is correct?

Now, arguably, the markup is incorrect, and the specs are a little unclear here.
https://www.w3.org/TR/html-aam-1.0/#img-element states the order is:
5.10.1 img Element Accessible Name Computation
If the img element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and
Description: Computation and API Mappings 1.1.
Otherwise use alt attribute.
Otherwise use title attribute.
If none of the above yield a usable text string there is no accessible name.
But doesn't explicitly say what to do with alt="", and arguably "" is not a usable text string, so maybe it's right to go on to title?

But then it does state that alt="" is explicitly given the role="presentation": https://www.w3.org/TR/html-aam-1.0/#details-id-54 so IMHO it shouldn't go in the accessibility tree.

https://www.w3.org/TR/wai-aria/#presentation states that:
Authors SHOULD NOT provide meaningful alternative text (for example, use alt="" in HTML) when the presentation role is applied to an image, but it's a SHOULD not a MUST so think Firefox should handle this better.

Regardless to all this, it's inconsistent between the visual display and the accessibility tree so seems like a bug to me.

Sorry missed a space in the link. The correct link for the test case is: https://www.tunetheweb.com/experiments/img-title/

And full HMTL (in case that ever goes down) is:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
</head>

<body>
<p><code><img alt="" title="this is a title" src="isnotfound.jpg"></code></p>
<img alt="" title="this is a title" src="isnotfound.jpg">
<hr>
<p><code><img title="this is another title" src="isnotfound.jpg"></code></p>
<img title="this is another title" src="isnotfound.jpg">
</body>
</html>

Was just informed this was discussed here: https://github.com/w3c/accname/issues/27
And PR has now been filed to fix the spec to state that alt="" wins and so it shouldn't be added to the accessibility tree, in which case this is a bug in Firefox: https://github.com/w3c/html-aam/pull/322

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Disability Access APIs
Product: Firefox → Core

(In reply to Barry Pollard from comment #0)

The broken image icon and title is not displayed because of the blank alt (I'm not sure if this is correct or if the alt="" means it shouldn't be displayed).

alt="" doesn't seem to make a difference here.

However the bigger concern is the accessibility tree IS including the image with the title as the accessible name. alt="" is not the same as no alt, and is an explicit signal to not add to the accessibility tree, so this seems incorrect to behaviour to me. It is also inconsistent to what is displayed visually.

The title is only not displayed for a broken image with no width and height. This is irrespective of alt="". If you give it a width and height, even with alt="", you will see the title:
data:text/html,<img src="notfound.png" width="100" height="100" title="test" alt="">

Broken images are weird, so let's consider a proper image. Then, even with alt="", you will see the title:
data:text/html,<img src="https://via.placeholder.com/100x100.png" alt="" title="test">

Firefox should not have added the image with alt="" to the accessibility tree.

So, while the spec now agrees with you, the concern I have is that (except in the case of a broken image with no width/height) an a11y user misses out on the title, even though it is visually displayed. That seems bad to me.

I'll comment on GitHub as well later this week.

Severity: -- → S4

alt="" doesn't seem to make a difference here.

It does for whether to display the broken image icon or not for some reason, as can be seen in examples 1 and 3. Interestingly looks like all three major browsers (Firefox, Chroe and Safari) differ slightly here.

But anyway, not too concerned about this.

The title is only not displayed for a broken image with no width and height. This is irrespective of alt="". If you give it a width and height, even with alt="", you will see the title:

Interesting! Hadn't considered that. However, not sure what you mean by "you will see the title"?

I've update the web page (https://www.tunetheweb.com/experiments/img-title/) with some examples with height and widths and also some examples with real images. It looks like Firefox NEVER displays the title on the page directly when alt doesn't exist (though it does show the title as a tooltip on hover). That's weird - I presumed it would be used as the fallback text to display if there was no alt text, but looks like Firefox doesn't use this (and neither does Safari btw, but Chrome does). Not sure who is correct here, or if there even is a "correct" answer but less concerned with this to be honest.

I'm more concerned with the explicitly alt="" being ignored and the image being added to the accessibility tree when that is used. The rest is just weirdness and noise (though interesting to see they are treated inconsistently in opinion).

So, while the spec now agrees with you, the concern I have is that (except in the case of a broken image with no width/height) an a11y user misses out on the title, even though it is visually displayed. That seems bad to me.

Well, as per above, the title isn't actually displayed (whether the image is broken or not), but I agree it is available on hover. Is that what you mean? In Chrome the title is actually displayed as the alternative text (whether height or width is given or not) but that's not the case in Firefox so not really understanding your point here?

To be honest I don't see how this is any different to a purely decorative image (which is exactly what alt="" is for) being visually displayed but ignored by a11y users?

BTW added another test case, with aria-hidden="true":

<img alt="" title="this is another title" height=50 width=100 src="image.png" aria-hidden="true">

In this case the image IS hidden from the accessibility tree, despite the title being present.

My understanding is that, for images, alt="" and aria-hidden="true" should be identical as far as a11y is concerned.

I meant the title is available on hover, sorry. But that still means it is "available" to a sighted user, which means it isn't purely decorative; it has some meaning beyond decoration.

Strictly speaking, it can be argued that you shouldn't combine alt="" with title for the above reason and that this should be considered authoring error. However, when mistakes like this are made (and they invariably are), I'd argue it's better in the real world to avoid hurting the user if we can (only of course if we can do so without breaking valid use cases). This is akin to what browsers do if you specify role="presentation" but also specify ARIA attributes:
data:text/html,<h1 role="presentation" aria-label="label">text

The question is: is there a valid use case for alt="" title="something"? If not, why take potentially useful info away from the user?

Well "available" is a loaded term given how inaccessible many people say title tooltips are :-)

Strictly speaking, it can be argued that you shouldn't combine alt="" with title for the above reason and that this should be considered authoring error. However, when mistakes like this are made (and they invariably are),

Agreed on both counts!

I'd argue it's better in the real world to avoid hurting the user if we can (only of course if we can do so without breaking valid use cases).

I guess it depends whether you take the view (as I do) that alt="" is an explicit signal to ask NOT to add image to the accessibility tree, akin to aria-hidden="true". Now that's not to say some people don't fill in a blank alt because they don't know better of course.

I agree, there are mixed signals here, but there also are for:
<img title="title" aria-hidden="true" src="...">
And in that case Firefox does not add to accessibility tree.

This is akin to what browsers do if you specify role="presentation" but also specify ARIA attributes:
data:text/html,<h1 role="presentation" aria-label="label">text

Interestingly in that case Firefox won't let you assign the presentation role to the h1 and will just ignore that attributes and leave it in the heading role.

Perhaps more interestingly nor will it allow you to assign that role to an <img> with a title (<img title="blah" role="presentation" src="...">) and will leave it as a Graphic, but it will allow you to assign it to an <img> with an alt (<img alt="blah" role="presentation" src="...">), in which case it will remove it from the AT. More fun!

Anyway, maybe we should pause this conversation until we see if that PR gets merged or not? And you mentioned above you were going to comment on it there (presumably to raise these issues).

(In reply to Barry Pollard from comment #8)

This is akin to what browsers do if you specify role="presentation" but also specify ARIA attributes:
data:text/html,<h1 role="presentation" aria-label="label">text

Interestingly in that case Firefox won't let you assign the presentation role to the h1 and will just ignore that attributes and leave it in the heading role.

That was my point; sorry if I wasn't clear. I mean that we avoid hurting the user here because the author's intentions are contradictory. Note that Chromium does the same in this case.

(In reply to Barry Pollard from comment #8)

I guess it depends whether you take the view (as I do) that alt="" is an explicit signal to ask NOT to add image to the accessibility tree,

Interestingly, even with that pull request, the naming spec says to use alt even if empty. It doesn't say to remove from the tree.

FWIW, Firefox doesn't remove alt="" from the tree, even without title. It does, however, expose the accName to clients in such a way that they can distinguish between alt="" and a missing alt. This has been the case for more than 10 years now and I worry that removing it from the tree altogether might cause problems for screen readers. That's a separate issue from whether we expose the title, though.

You need to log in before you can comment on or make changes to this bug.