[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.

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?