[Webkit-unassigned] [Bug 262895] AX: `aria-describedby` content hidden behind new interaction

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=262895

--- Comment #17 from James Craig <jcraig at apple.com> ---
> That is useful, but does not tell me why it was added/changed from existing behavior, just how it maps and is exposed.

Ah, you want the long version... When will we next be in the same zip code? 

This is tied to a fundamental UI difference between screen readers and platforms. IMO, SR UI differences are broader than most sighted people realize... Using Mac/Windows/XWindows(Linux) as a metaphor, the main details of sighted GUI interaction patterns stabilized in the 1980s... App windows, menus, toolbars, have differences but if you have experience with one platform, the bones of the interface are similar on all, albeit with a bunch of little details that are different. Cmd vs Ctrl being one of many.

On top of all those little differences in the OS details, the SRs are fundamentally different in too many ways to go into save one: Accessibility Extended Description (that is, not the name/label, and not the contents, but some other thing that is accessed on demand) was a Windows screen reader concept. VoiceOver has other concepts that NVDA/JAWS don't have, but aria-describedby (and more recently aria-description) was effectively a Windows API port into the Web Platform.

WebKit used to expose this as the help text (also used for tooltips when the tooltips aren't used for name/label) but there were always edges cases like, what happens when two (or more) things from a Windows-concept-converted-to-Web need to squeeze into the same property in the macOS Accessibility API (AX API)... Then there are new mechanisms that came from ARIA where there was no AAM on any platform (IIRC, aria-errortext was one of these)... 

On top of that, SRs that ship on multiple platforms and across UI frameworks (like iOS VO on UIKit/SwiftUI/Web, and Mac VO on AppKit/SwiftUI/Web) should ideally be framework-neutral. As much as possible, the AT and API should work the same way whether the app view is native, web, etc. AXCustomContent is one of many API updates that allows more flexibility over time.

So long story short: "why it […] changed" is because that it used to be exposed through a more rigid API, and WebKit now exposes it through the newer API.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20231103/1b609441/attachment.htm>