Steps to reproduce:

1. Launch Voiceover.
2. Navigate Firefox to this website: https://a11ysupport.io/tests/html/aria/aria-haspopup_examples.html
3. Focus the aria-haspopup="true" and aria-haspopup="menu" buttons.

Actual results:

When focusing aria-haspopup="true", Voiceover reads "action, menu button, group".
When focusing aria-haspopup="menu", Voiceover reads "action, menu popup button".

Expected results:

The button with aria-haspopup="true" should be read out the same as aria-haspopup="menu".

Just quoting the relevant ARIA spec passage:

"To provide backward compatibility with ARIA 1.0 content, user agents MUST treat an aria-haspopup value of true as equivalent to a value of menu."

I wish I could provide the values Firefox exposes in the AX API, but I couldn't figure out how to measure AXPopupValue on Mac's accessibility inspector, and the Chromium's dump tree tool is crashing with all browsers that I tried on Mac for some reason (interestingly the tool still appears to work with Chromium's dump tree tests somehow....). I also don't see an entry for aria-haspopup="true" in what I think are Firefox's platform tests: https://searchfox.org/mozilla-central/source/accessible/tests/browser/mac/browser_aria_haspopup.js#97.

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

My guess is that this is because we're returning "true" for AXPopupValue. It looks like Chrome does the same thing, but Safari doesn't. Unsurprisingly, AXPopupValue isn't documented anywhere in the mapping spec, which is why bugs like this happen. :(

Note that despite the spec passage quoted in comment 1, the mapping spec explicitly states that IA2 and ATK should expose aria-haspopup="true" differently from aria-haspopup="menu". Therefore, this change will be a Mac specific change.

Just a heads up -- it looks like chrome exposes AXPopupValue:Menu for aria-haspopup="true", actually: https://source.chromium.org/chromium/chromium/src/+/main:content/test/data/accessibility/aria/aria-haspopup-expected-mac.txt

I looked and found "true" interpreted as "menu" in the platform agnostic code: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_node_object.cc;l=3619;drc=f2732aef3e95dca51f5d70c1242f0c7614a0b9aa;bpv=0;bpt=1

Sayan caught the lack of specification and just made a PR against core-aam :) https://github.com/w3c/core-aam/pull/188

Made an issue on CORE-AAM for the IA2/ATK case as well: https://github.com/w3c/core-aam/issues/189

(In reply to spectranaut from comment #4)

I looked and found "true" interpreted as "menu" in the platform agnostic code: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_node_object.cc;l=3619;drc=f2732aef3e95dca51f5d70c1242f0c7614a0b9aa;bpv=0;bpt=1

Oh interesting. So that Mac case for "true" is dead code, I guess. :) Thanks for the correction.

That also means Chrome exposes "menu" for ATK/IA2. I just checked and that indeed appears to be the case for IA2.

Given all of these findings, I think it makes sense to tweak Firefox to expose aria-haspopup="true" as "menu" on all platforms; i.e. do this in the cross-platform code.