"Image button has non-empty accessible name" [59796f] - clarification about input type image with empty alt but non-empty title

[giacomo-petri]

• Starting URL: https://www.w3.org/WAI/standards-guidelines/act/rules/59796f/
• Highlighted element: input type image, empty alt attribute and non-empty title attribute <input type="image" src="test.png" alt="" title="non-empty value">
• Description: should we add an example for input type image with empty alt attribute and non-empty title attribute that clearly identify it as a failure?
  • per failed example 2 The image button has an empty alt attribute, and no other attributes that can give it an accessible name, hence its name is the default “Submit Query”. <input type="image" src="/test-assets/shared/search-icon.svg" alt="" /> the input is failing due to the absence of an accessible name.
  • per passed example 3 The image button has an accessible name through the title attribute. note: The title attribute may not always be accessibility supported. <input type="image" src="/test-assets/shared/search-icon.svg" title="Search" /> input has an accessible name thanks to the title attribute and title attribute can give it an accessible name.
• Concerns:
  • from failed example 2 The image button has an empty alt attribute, and no other attributes that can give it an accessible name, actually, per passed example 3, the title attribute seems a valid attribute to give the input type image an accessible name. I understand that in this context, can give it means that the resulting accessible name is non-empty, but might not be fully clear.
  • following the accessible name computation instructions, the empty alt attribute should force the accessible name to be empty. That said, on Firefox, the title attribute is used as fallback even if the alt attribute is empty, as per screenshots attached:
• Conclusion: Do you think might be helpful to include explicitly scenario above in Image button has non-empty accessible name rule?

Giacomo

[WilcoFiers]

Description: should we add an example for input type image with empty alt attribute and non-empty title attribute that clearly identify it as a failure?

Interesting. I did not realise there's a difference between having an empty alt and having no alt attribute here. Looking at the Chromium AXTree, there clearly is. I think that's it'd be a good idea to add that example. We should also put something about how Firefox handles this in the accessibility support section.

Would you be up for opening a pull request for this?

[Jym77]

As per HTML AAM, accessible name computation, steps 2 and 3 the alt attribute should be used if present and otherwise the title attribute should be used. However, step 4 has this "if the previous steps do not yield a usable text string" where I'm not sure if an empty string should count as a "usable text string" or not 🤔

Quick check, both Chrome seems to give no name to <input type="image" src="test.png" alt="" title="non-empty value"> (i.e. consider the empty alt as a "usable text string"); but Firefox gives it a name (i.e. does not consider empty alt as a "usable text string").

So we definitely need an Accessibility Support note to mention that…

And with <input type="image" src="test.png" aria-label="" title="non-empty value"> (replacing the alt by an aria-label), Chrome uses the title to give a name (this time considering the empty aria-label as not being an "usable text string") while Firefox defaults to "Submit query" (this time just ignoring the title because 🙃).

At this point, they seems to both interpret the AAM in different ways, but each in its own inconsistent way 🤷 🤦

[giacomo-petri]

And with <input type="image" src="test.png" aria-label="" title="non-empty value"> (replacing the alt by an aria-label), Chrome uses the title to give a name (this time considering the empty aria-label as not being an "usable text string") while Firefox defaults to "Submit query" (this time just ignoring the title because 🙃).

@Jym77 I've performed some test too using different browsers but I cannot replicate your experience with Firefox (version 101.0.1). It seems behaving consistently.

Firefox (version 101.0.1)

• <input type="image" src="test.png" alt="" title="non-empty value"> has "non-empty value" as accessible name
• <input type="image" src="test.png" aria-label="" title="non-empty value"> has "non-empty value" as accessible name too.

I've also tested the other html elements that support the alt attribute (img, input type image and area) and only the area element is inconsistent in Firefox:

• <area shape="rect" coords="x1,x2,y1,y2" alt="" title="non-empty value" href="test1.htm"> returns "non-empty value" as accessible name
• <area shape="rect" coords="x1,x2,y1,y2" aria-label="" title="non-empty value" href="test2.htm"> returns the href value as accessible name (inconsistent)

Chrome (version 102.0.5005.61)

I experienced the same behaviour on Chrome (version 102.0.5005.61), that is consistent for every element (img, input type image and area), using the title value as accessible name if aria-label is empty and setting empty accessible name if used in combination with the empty alt attribute (alt="").

Safari (Version 15.4)

Safari is behaving pretty inconsistently.

Images behaviour:

• <img src="image.jpg" alt="" title="non-empty value"> returns "non-empty value" as accessible name
• <img src="image.jpg" aria-label="" title="non-empty value"> returns "non-empty value" as accessible name

Inconsistent inputs type image behaviour:

• <input type="image" src="test.png" alt="" title="non-empty value"> returns default "Submit Query" as accessible name
• <input type="image" src="test.png" aria-label="" title="non-empty value"> returns "non-empty value" as accessible name

Area behaviour:

• <area shape="rect" coords="x1,x2,y1,y2" alt="" title="non-empty value" href="test1.htm"> returns "non-empty value" as accessible name
• <area shape="rect" coords="x1,x2,y1,y2" aria-label="" title="non-empty value" href="test2.htm"> returns No Accessibility Information (but using VO, it announces "link, non-empty value".

[Jym77]

@giacomo-petri Interesting 🤔 I've been using the following code:

<input type="image" src="test.png" alt="" title="empty alt">
<input type="image" src="test.png" aria-label="" title="empty aria-label">
<input type="image" src="test.png" aria-labelledby="foo" title="empty aria-labelledby">

<span id="foo"></span>

And here is what I see in Chrome (102.0.5005.115) and Firefox (101.0.1), plus NVDA output on them.

So, Chrome is using the empty alt in the first case, but defaults to title in the two other cases. And Firefox somehow uses the title in the first case, but hides the button from NVDA 🤔 and defaults to "Submit Query" in the two other cases.

---

Aha 💡 This actually depends whether the image loads 💥 With a loaded image, I get the following results.

So when the image does load, Firefox is indeed defaulting to title in all three cases while Chrome only uses it after an empty aria-label but not after an empty alt or aria-labelledby.

---

Combined, this makes even less sense and everything is even more inconsistent, it feels 🙃

[giacomo-petri]

@Jym77, thanks for this input about images not loaded.

Based on our previous comments that highlight inconsistency between different browsers but also within the same browser, assuming that some of these inconsistent scenarios will be updated in the future, should we update the rule saying something like: "Combinations of passed examples do not guarantee the fulfilment of this rule. For example ..."

Otherwise might be hard to cover all scenarios and keep it updated.

[Jym77]

@giacomo-petri We might actually want to investigate browser side (and HTML AAM side) whether they consider these are bugs and want to fix them… Is it something you want to do (investigate if there are open issues and open them if needed)?

Maybe there are some good reason why they behave that way and we just can't figure them out. It's also interesting to have the HTML AAM opinion on what the "good" way should be (so we can write our rule that way and claim the moral higher ground).

[giacomo-petri]

@Jym77,

sure, I'm creating a html file containing the entire list of examples for every element that supports alt (img, input type="image" and area) with the combination of title and other properties (title + empty alt, title + empty aria-label and title + empty aria-labelledby) with both images loaded and invalid.

I'll highlight what we've discussed here, asking for recommendations and opinion from HTML AAM. I'll also open tickets for every single browsers, asking for details.

[giacomo-petri]

Attaching file for reference with all scenarios: img-inputimg-area-examples.zip

note: I've attached a compressed file due to the need of adding valid images to compare with non-loaded images.

[giacomo-petri]

Request to the HTML AAM group submitted. Once we have an answer with good practices, if still valid I'll ping browser side to understand if they consider highlighted scenarios as bugs and if they are interested solving them.

I'll keep the issue updated.

[giacomo-petri]

Updates:

per HTML AAM https://github.com/w3c/accname/issues/27#issuecomment-802138411 the intent was:

if there's an alt="" that would indicate that the image is meant to be "hidden", and therefore the steps would stop at 2.

The HTML AAM topic was referring to images in general that are, by themselves, non-operable user interface components; here instead we are talking about input type="image", which are operable user interface components. That said, considering that the HTML AAM topic also included images wrapped within links, I'm assuming it can be consistently applied to input type images.

Related pull request (Pull) changed:

`img` Element Accessible Name Computation

1. 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.
2. Otherwise use `alt` attribute.
3. Otherwise use `title` attribute.
4. If none of the above yield a usable text string there is no accessible name.

into

`img` Element Accessible Name Computation

1. 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.
2. Otherwise use `alt` attribute, even if its value is the empty string.
   An `img` with an `alt` attribute whose value is the empty string is mapped to the `presentation` role. It has no accessible name.
3. Otherwise, if there is no `alt` attribute use the `title` attribute.
4. Otherwise there is no accessible name.

Topic was not completely closed, and further considerations for naming / exposing images is available here: https://github.com/w3c/html-aam/issues/404

[giacomo-petri]

Updates:

In light of @scottaohara clarification at https://github.com/w3c/html-aam/issues/414#issuecomment-1178384158, https://github.com/act-rules/act-rules.github.io/pull/1865#discussion_r916355347 and https://github.com/act-rules/act-rules.github.io/pull/1865#discussion_r916544922 the combination of empty alt attribute and non-empty title attribute gives the input type image a non-empty accessible name through the title attribute.

In particular, empty alt does not provide a "usable string" for input element with a type image.

In the meantime I've opened a bug for Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1342873