[html-aam] Make HTML img accname use “title” text if alt is empty

[sideshowbarker]

This change updates the accessible-name computation steps for the img element to require that in the case of an alt="" (empty alt) img element which has a non-empty title attribute, the value of the title attribute is included in computation of the element’s accessible name.

Otherwise, without this change, the spec as written doesn’t match the behavior as implemented in existing UAs, nor the corresponding requirements in https://w3c.github.io/accname/#comp_host_language_label in the AccName spec — specifically, the requirement to skip past the “Host Language Label” step in the alt="" case, and to move on to subsequent steps, culminating in the “Tooltip” step, which for HTML elements requires using the value of any title attribute, if present.

Also, without this change, the spec doesn’t match the expectations in https://wpt.fyi/results/accname/name/comp_tooltip.html for the “img with tooltip label with empty alt” subtest.

Test, Documentation and Implementation tracking

• "author MUST" tests: N/A
• "user agent MUST" tests: https://wpt.fyi/results/accname/name/comp_tooltip.html
• Browser implementations (link to issue or commit): WebKit, Gecko, and* Blink all implement the if-alt-is-empty-use-title behavior in this patch.
• Does this need AT implementations? No
• Related APG Issue/PR: N/A
• MDN Issue/PR: N/A

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	84dadf6
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/673ae4588386a00008c94570
😎 Deploy Preview	https://deploy-preview-2378--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[scottaohara]

well, this is the opposite outcome that had been decided about 2.5 years ago - w3c/html-aam#322.

[cookiecrook]

Unfortunately I missed this addition in review... web-platform-tests/wpt#42093

Actually, despite the typo... It seems I suggested this new test in review.

• Update /accname/name/comp_tooltip.html web-platform-tests/wpt#42093 (comment)

Sorry.

[cookiecrook]

Since the browsers aligned on this variant that conflicts with the HTML-AAM spec, I think we should get UA implementor consensus to remove the WPT test and roll back this change. We'll do it in a way that does not affect the current Interop 2024 Focus Area.

We need comments from the following re: willingness to roll it back:

• @nmlapre and/or @jcsteh
• @aleventhal and/or @tranjocelyn (cc @benbeaudry)
• @twilco

[scottaohara]

Unfortunately I missed this addition in review... web-platform-tests/wpt#42093

Actually, despite the typo... It seems I suggested this new test in review.

• Update /accname/name/comp_tooltip.html web-platform-tests/wpt#42093 (comment)

Sorry.

no reason to apologize - looking at that wpt PR, you gave me plenty of pings to come review, and i missed every one of them.
and it does seem that there were parallel efforts to work on this overarching issue, but both of the specs / the related issues were not being considered together. shrug. things happen, and opinions can change, but I just want to make sure that what was resolved by the working group and reflected in HTML AAM was considered, since it seems maybe that was missed when the test was created.

[nmlapre]

I think we should get UA implementor consensus to remove the WPT test and roll back this change

Are we talking about removing the "img with tooltip label with empty alt" test? What change are we considering rolling back? From my perspective, what the browsers are doing now is desirable behavior, which seems to make the <img title="label" alt="" data-expectedlabel="label"> test valid (albeit not by the current wording of the spec).

[scottaohara]

@nmlapre for mozilla specifically, there would be no rollback, per se, as Firefox was the browser that originally treated a title=foo as the name for an image that had alt="". Whereas back when the HTML AAM issue/PR began, Chromium and Webkit did not algin with Firefox's behavior and did not use title as a means to re-expose an image that had alt="". (or if memory serves, webkit did still 'name' the image with the title attribute, but also marked the image as ignored in the a11y tree due to the existence of the alt="")

The linked HTML AAM issue has a lot of back and forth on whether or not title should be a naming mechanism for this contradictory markup. I'm personally not interested in redebating that - so everything here after is not me trying to change one's opinion, but providing some summary/rational that maybe everyone didn't read the first time around - hence this discrepancy in what was put into the spec, vs browsers aligning on different behavior seeming after the spec clarification was made.

I think both points of view are valid - and can be beneficial to users - depending on the use cases. (e.g., <img alt="" title="useful information"> is important to expose. but <img alt="" title="garbage info, like the file name of the image that the CMS automatically adds, but the author wanted this to be decorative, hence why the alt is empty"> is unfortunately not uncommon, and not generally useful.

As an FYI, accessibility checkers such as IBM's a11y assessment tool, ARC Toolkit, the Wave Evaluation tool and the ssa.gov ANDI accessibility checker identify instances of img alt="" title=foo" as "decorative" images and raise alerts/errors for using these attributes together in this way. That leads me to believe that none of these tools are aware of the changes that browsers made here - and i mention this not as an argument to say what browsers have done here is wrong, but more to point out it doesn't match how these tools / developers have been led to believe these attributes are meant to behave when used together - particularly since with the guidance, predating ARIA, that alt="" is to indicate an image is decorative (for better or worse).

So, if the decision is to keep this new unified behavior - and the spec needs to be adjusted to reflect that, then I'd submit there's also a need to make this update more widely known so that guidance can be updated and so that checkers aren't sending people warnings/alerts about what have become false positives (or change their messaging to point out that authors have provided conflicting information and that something should be done to address that).

[sideshowbarker]

Since the browsers aligned on this variant that conflicts with the HTML-AAM spec, I think we should get UA implementor consensus to remove the WPT test

You mean the test at https://wpt.fyi/results/accname/name/comp_tooltip.html that all the UAs are currently passing? If so, I guess I’m confused. Why do we want to remove a test that everybody’s passing?

and roll back this change

You mean roll back the https://github.com/w3c/html-aam/pull/322/files change? If so, that’s what the https://github.com/w3c/aria/pull/2378/files patch in this new PR is doing, right?

[scottaohara]

@sideshowbarker

If so, I guess I’m confused. Why do we want to remove a test that everybody’s passing?

I’ll try explaining this again…
The test was written with a passing expectation that was the opposite of what HTML AAM defined.
Specificity the test <img title="title" data-expectedlabel="title" alt="" data-testname="img with tooltip label with empty alt" class="ex" src="...">, asserted that the “passing” result expects the name of the image to be "title" - but that is an inaccurate assertion since HTML AAM stated the img with the alt's empty string is to be used, and noted the image should be treated as role=presentation without a name.

As mentioned, at the time of the HTML AAM PR being written and then (after a long time/discussion) update, WebKit and Chromium were in alignment with the spec. Now they pass this test but not the spec they previously aligned with. Thisis why in the original html aam pr, there was only a linked bug for firefox, as neither webkit nor chromium needed a change to match the spec.

The change to roll back (if agreed that is the course that should be taken) would be the change browsers made (specifically WebKit and Chromium), reverting them to match the previous reality which is what HTML AAM's PR clarified.

And to be clear again, while I have my preference, I am not trying to advocate for one way or the other. It is up to those @cookiecrook mentioned to weigh in as to what should happen. I’m more pointing out that something went askew here (partially my fault for not catching the errant test result when asked to review last year) and that browsers made changes that moved away from what the spec / aria wg had resolved on, and instead align to a WPT that didn't match a spec it should have been validating against.

Edit:
Another thing to mention here, but if browsers do not roll back to match the spec, and this PR needs to go through, then what is changed in this PR is not enough.

The mapping table(s) for img would also need to be updated to better reference this change (specifically the img alt="" mapping table that states an img with an empty alt is supposed to be treated as role=none. This needs to be clarified now that alt does not always behave this way if the title attribute is used along with it - though previously this clarification wasn't thought to be necessary, since in ARIA's UA conflict resolution for role=none, the title attribute was not meant to be considered. So maybe that's a change that needs to occur in ARIA as well... if i recall correctly, that was another one of the reasons the ARIA wg talked about, how we didn't want title to behave that way, and therefor to be consistent with other elements we didn't want to special case images that were marked as implicit role=none (alt="") but also given a title that could undo that.

Additionally, ARIA in HTML would also need to be updated to align with this change. I can handle that if that's the way this shakes out.