alt vs title: HTML-AAM and accname specs have conflicting requirements

[sideshowbarker]

Given an img with an empty alt attribute and a non-empty title attribute, the HTML-AAM spec requires using the empty alt value as the accessible name. But the accname spec requires ignoring that empty alt and instead using the non-empty title value.

Details

At https://w3c.github.io/html-aam/#img-element-accessible-name-computation the HTML-AAM spec says this:

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.
   Note: 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.

Note in particular, the even if its value is the empty string language.

But at https://w3c.github.io/accname/#comp_host_language_label, the accname spec says this:

E. Host Language Label: Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

Because an alt attribute with the value of the empty string (alt="") marks the element as presentational, then a reasonable reading of that accname requirement cited above is:

When the alt value is the empty string, the algorithm reaches the unless the element is marked as presentational part — in which case the requirement is to not return the alternative, but instead fall through (skip) the E. Host Language Label step, and so then move on to using the title value.

In other words, the accname spec says to ignore the empty alt, but the HTML-AAM instead requires using it.

Link to the version of the specification or documentation you were looking at at.

• https://w3c.github.io/html-aam/#img-element-accessible-name-computation
• https://w3c.github.io/accname/#comp_host_language_label

---

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?

Yes

[Jym77]

Because an alt attribute with the value of the empty string (alt="") marks the element as presentational, then a reasonable reading of that accname requirement cited above is:

That is not completely true, since empty alt only marks as presentational if there is no name (ARIA ni HTML), although HTML AAM doesn't reflect that.
And ARIA in HTML mentions "another image naming method" which links back to HTML AAM stating to use alt even if empty, before using title.

[sideshowbarker]

OK — so maybe I can instead interpret “unless the element is marked as presentational (role="presentation" or role="none")” to mean “unless the element has a role attribute with the value presentation or none”?

Because an alt attribute with the value of the empty string (alt="") marks the element as presentational, then a reasonable reading of that accname requirement cited above is:

That is not completely true, since empty alt only marks as presentational if there is no name (ARIA ni HTML)

But that “unless the element is marked as presentational” condition is in a step for computing the name, right?

So it seems like I can’t determine if I have an “empty alt only marks as presentational if there is no name” case without first computing a name — which would seem to require recursively calling back in the algorithm for computing the name, and ending up infinitely recursing.

So if what the editors really intended here is “unless the element has a role attribute with the value presentation or none”, then I hope the spec can be updated to actually say that instead.

[scottaohara]

@sideshowbarker HTML AAMs steps are meant to take priority here.

I can sort of see why this is reading weird, though... i think the "unless the current node is exposed as presentational (role="presentation" or role="none")." likely needs to be clarified. (also not sure why your quoted text is different than the latest draft i pulled this from - e.g., your text says 'marked' but the accname spec says 'exposed')

For instance, that text is likely meant to cover these cases:

<svg role=none><title>foo</title></svg>
<img role=none alt=foo>

where because these are marked as role=none the element's roles are meant to be ignored and thus it wouldn't be expected for a name to be exposed for an element whose role is ignored.

Building on the point that presentational items aren't meant to be named - by this point the aria-label/aria-labelledby step which would have triggered the conflict resolution for presentational items, has already occurred. So, I think it's a misinterpretation to read this and think that per this step, if an element has role=none (marked or explicit) that one would even continue on with the naming algorithm. Again, HTML AAM's specific naming steps for img is meant to make this clear. alt="" means the image has no name, it is also pulling double duty and exposing the element as role=none.
But, to help clarify further, html aam has the note:

An img with an alt attribute whose value is the empty string is mapped to the presentation role. It has no accessible name.

Maybe clarification for something like this might also help with w3c/accname#250 - where a more overt statement to check/refer to host language's steps for more specifics vs the generalized accname spec is in order?

[sideshowbarker]

Building on the point that presentational items aren't meant to be named - by this point the aria-label/aria-labelledby step which would have triggered the conflict resolution for presentational items, has already occurred.

Thanks, I see. However, it’s quite possible I’m just really confused, but it’s not clear to me how that’s actually relevant to what I’ve brought up.

What I mean is: The concrete cases I’m concerned with at these two:

1. from http://wpt.live/accname/name/comp_tooltip.tentative.html

   <img data-expectedlabel="" alt="" title="title"
   data-testname="img with tooltip label with empty alt" class="ex"
   src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==">

2. from http://wpt.live/html-aam/roles-contextual.html

   <img data-expectedrole="image" alt title="x"
   data-testname="el-img-empty-alt-title"
   class="ex"
   src="[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==](view-source:data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==)">

Aren’t both of those the same markup case? That is, they’re both an img with an empty alt and a non-empty title.

But the expected result for the first case seems to be that it has no name — while the expected result for the second case seems to be that it instead has a name (and therefore is role=image).

So concretely: I’m just trying to get my implementation to pass both of those tests. But if I attempt to make it pass the first test, then I fail the second test. And if I instead attempt to make it pass the second test, then I fail the second test.

So is there something I’m missing here?

Or are those two test written to conform to different/conflicting spec requirements?

So, I think it's a misinterpretation to read this and think that per this step, if an element has role=none (marked or explicit) that one would even continue on with the naming algorithm.

I’m not interpreting the spec. I’m attempting to strictly implement what it actually says. So based on what I have implemented, it’s not clear to me if/when any implementation that actually follows the spec is actually going to have determined what the element’s role is.

But then, see w3c/html-aam#570 — which is about the fact that, as far as I can see, the HTML-AAM spec as currently written seems to require that in order to compute a role for an img, you must compute its accessible name. But in order to compute its accessible name, you need to compute its role.

[Jym77]

Aren’t both of those the same markup case? That is, they’re both an img with an empty alt and a non-empty title.

But the expected result for the first case seems to be that it has no name — while the expected result for the second case seems to be that it instead has a name (and therefore is role=image).

So concretely: I’m just trying to get my implementation to pass both of those tests. But if I attempt to make it pass the first test, then I fail the second test. And if I instead attempt to make it pass the second test, then I fail the second test.

So is there something I’m missing here?

The second of these tests has been recently added by me, without noticing the first 🙈 (nor remembering the fact that "no alt" trumps "title" in terms of image naming…) So I guess it is the one we need to update.
I was carried over by the fact that the others "no role if no name" cases (aside, region) can be named by title because they do not have the intermediate "empty alt" case…

[sideshowbarker]

The second of these tests has been recently added by me, without noticing the first 🙈 (nor remembering the fact that "no alt" trumps "title" in terms of image naming…) So I guess it is the one we need to update. I was carried over by the fact that the others "no role if no name" cases (aside, region) can be named by title because they do not have the intermediate "empty alt" case…

Ah, OK — that clears up that part at least.

I’ve gone ahead and opened web-platform-tests/wpt#51593. As I mention there, if you can accept the invite to join the web-platform-tests and the reviewers team, I can set you as the reviewer for that PR. And that’ll also enable requesting review from you on future PRs.

[scottaohara]

Yeah, seeing those two tests helps clear this up a lot…

That second test should be removed (or changed to indicate the expected role is generic, as the PR to adjust had done/has been merged) since it’s essentially a dupe of the first but expecting a result that doesn’t match the spec…

[rahimabdi]

But the accname spec requires ignoring that empty alt and instead using the non-empty title value.

@sideshowbarker I've submitted an accname PR to clarify treatment of alt="", and would welcome your and @scottaohara's thoughts on ensuring this is clearer as part of the host language label step: https://github.com/w3c/aria/pull/2486/files.