Order of "Submit Query" vs title attribute for <input type=image>

[zcorpan]

https://w3c.github.io/html-aam/#input-type-image-accessible-name-computation

This considers the title attribute before using the string "Submit Query".

But for <input type=submit> https://w3c.github.io/html-aam/#input-type-button-input-type-submit-and-input-type-reset-accessible-name-computation

the order is reversed, so "submit" is used even if there is a title attribute.

Should these be consistent?

[scottaohara]

Hi @zcorpan,

For the input type=image the title can serve as fallback accessible name for the image if there is not alt, just like standard images. This trumps the user agent provided "Submit Query" or "Submit" from being used, and the title can also be the fallback text printed to screen if the image were to not load.

For the input type=submit, if no value is set, the "Submit Query" or "Submit" text is visibly provided, and the title doesn't serve the same stand-in for an alt text fallback.

Does that clear it up?

[zcorpan]

This trumps the user agent provided "Submit Query" or "Submit" from being used, and the title can also be the fallback text printed to screen if the image were to not load.

The HTML spec doesn't allow the title attribute to be rendered as alternative text for input type=image.

The element does not represent an image and either:

• ...
• the element has no alt attribute, or
• ...
  The user agent is expected to treat the element as a replaced element whose content is the text that the element represents, if any, optionally alongside an icon indicating that the image is being obtained (if applicable). For input elements, the element is expected to appear button-like to indicate that the element is a button.

If the element is an input element that does not represent an image and the user agent does not expect this to change
The user agent is expected to treat the element as a replaced element consisting of a button whose content is the element's alternative text. The intrinsic dimensions of the button are expected to be about one line in height and whatever width is necessary to render the text on one line.

https://html.spec.whatwg.org/multipage/rendering.html#images-3

(This also doesn't say to use "Submit Query" in the rendering, but that may be a bug in HTML. It does say to use something for type=submit.)

Anyway, it's still not clear to me if the difference is intentional, and if it is, why.

[scottaohara]

@zcorpan

The HTML spec doesn't allow the title attribute to be rendered as alternative text for input type=image.

Safari, Chrome and Edge/Chromium all print the title's text as fallback content if no alt is provided. Maybe the HTML spec should be revised to match what the majority of browsers are doing?

IE11 / pre-Chromium Edge do not render any text for a broken image, but do get their accessible name from the title attribute. These results obviously being less relevant these days.

Firefox is the only one that prints "submit query" when an image is broken, and in that case doesn't use the title attribute for the accessible name, keeping it as descriptive text.

Test page

[zcorpan]

Woah. I didn't know those browsers did that. I'll raise an issue for HTML. Thanks.

[scottaohara]

To round out the response, as i realize I didn't address your last question about

it's still not clear to me if the difference is intentional, and if it is, why.

Beyond matching what most browsers are doing, in the event an image isn't broken title would still take precedence over the UA default text being used, which Firefox does respect (test 13).

With all this said, I'm now wondering if there might be a better way to word the algorithm so that this is more clear.

Thanks for bringing this up

[zcorpan]

I have ideas for how to make accname and html-aam clearer in general, but it would involve basically a complete rewrite. :-)

[zcorpan]

cc @spectranaut

[scottaohara]

Bug filed with Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1778726

As this is not an issue with this specification, and both webkit and chromium have implemented what's reflected here, it seems Firefox is what needs updating and possibly the HTML spec.

Closing this issue, but if any movement is made elsewhere that would require updates here, then we can start up that conversation in a new issue / re-open this one.