Consider exempting title attribute participation in <abbr> accname

[rahimabdi]

Currently, html-aam states for <abbr> accname computation:

1. If the 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 the title attribute.
3. If none of the above yield a usable text string there is no accessible name.

From quick testing of common AT/browser combinations with default verbosity settings (<abbr title="..."> test):

• iOS 18.6.2 & Safari = does not announce title
• macOS 15.6.1 & Safari = does not announce title
• JAWS 2025.2504.98 & Chrome 139.0.7258 = announces title
• NVDA 2025.2 & Firefox 142.0.1 = does not announce title

To investigate:

• Should title for <abbr> be exposed given verbosity concerns? See WebKit bug #145879 - AX: tag does not expose title= information to VO.
• If it were not exposed as accName, could it optionally map to accDescription when provided?

[rahimabdi]

From Sept 4 2025 ARIA WG meeting:

• title attr should not contribute to accname
• needs platform mappings for html-aam

[aardrian]

More testing results from the bygone era of 2024:

These are all with default settings. I highlighted the 5 cases where title is exposed, and in each case I believe it's a worse experience for users (based on human testing).

Firefox 121 / NVDA 2023.3

• When using read-all, does not announce title.
• When using virtual cursor, does not announce title.
• Does not expose title in Braille display.

Chrome 120 / JAWS 2024.2312.53

• When using read-all, does not announce title.
• When using virtual cursor, does not announce title.
• Does not expose title in Braille display.

Edge 120 / Narrator / Windows 11 23H2

• When using read-all, does not announce title.
• When using virtual cursor, announces title and then requires another keypress to announce visible text.

Safari 17.2.1 / VoiceOver (macOS 14.2.1)

• When using read-all, does not announce title.
• When using virtual cursor, announces visible text and then title.
• Does not expose title in Braille display.

Firefox 115 / Orca (Ubuntu 22.04.2 LTS)

• When using read-all, does not announce title.
• When using virtual cursor, does not announce title.

Firefox 121 / TalkBack 14.1 (Android 14)

• When using read-all, does not announce title.
• When swiping through content, does not announce title.
• When using explore-by-touch, does not announce title.

Chrome 120 / TalkBack 14.1 (Android 14)

• When using read-all, only announces title.
• When swiping through content, only announces title.
• When using explore-by-touch, only announces title.

Safari 17.2 / VoiceOver (iPadOS 17.2)

• When using read-all, does not announce title.
• When swiping through content, does not announce title.
• When using explore-by-touch, does not announce title.

[aardrian]

I just checked JAWS 2025.2505.43 / Chrome 139.0.7258.155:

• When using read-all, announces the visible text and the title (in that order).
• When using virtual cursor, announces the visible text and the title (in that order).
• In the Braille display it shows the visible text and the title (in that order).

I have no insight into what prompted JAWS to enable this by default. This matches what Rahim reported.

[cookiecrook]

@aardrian you may want to update your test results for VoiceOver... As far as I know, the below worked for at least a decade but portions of it seems to have regressed more recently. In any case, VO users could get to speech expansions before, and I am still hearing speech expansions (now by default).

The help tag contents, (tooltips, title hovers, etc) should-be* exposed as AXHelp [Update: possibly AXExpandedTextValue]. Depending on user setting, this is available after a delay (screen shot below shows VoiceOver Utility settings) and as a shortcut. The "Help Tag (tooltip)" keyboard shortcut for VoiceOver on Mac is VO+Shift+H or Caps+Shift+H, again depending on user settings.

Recently, there seems to have been a shift to expand it via title (it is spoken, and the computedlabel in your test case), but I think that's a regression, and doesn't follow the VO settings expectation. (The problem I hypothesized about appears to be shipping.)

Also, VoiceOver doesn't have a "virtual cursor" like the JAWS-style screen readers. The cursor is always live. There isn't really the same concept of an offline cache. I think what you mean by "virtual cursor" on the VoiceOver results is "element navigation."

[cookiecrook]

WebKit/VO bug tracker: https://bugs.webkit.org/show_bug.cgi?id=298446
More test cases: https://bug-298446-attachments.webkit.org/attachment.cgi?id=476655