Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider listing known downstream AT support in AAMs, to avoid shipping speculative or otherwise unsupportive API mappings #238

Open
cookiecrook opened this issue Oct 24, 2024 · 2 comments

Comments

@cookiecrook
Copy link
Contributor

cookiecrook commented Oct 24, 2024

Background for this Core-AAM request here:

Consider listing known downstream AT support in AAMs, to avoid shipping speculative or otherwise unsupportive API mappings.

As an example, seems easy to throw a new property bag at Windows APIs and Linux API using the following pattern, but that doesn't mean the new ARIA feature is supported by any assistive technology. In full disclosure, I'm using colindextext/rowindextext as the examples b/c I think it's unlikely to be widely supported by Windows AT, I know it's not supported by VoiceOver on Mac, and I'm not sure about Orca on Linux.

MSAA + IAccessible2: Object Attribute: colindextext:
UIA: Property: AriaProperties.colindextext: 
ATK/AT-SPI: | Object Attribute: colindextext:

I would propose that, potentially as a prerequisite to shipping new ARIA features and AAM mappings, the AAMs list known AT support as a requirement. Ideally AT support on two platforms, similar to the "two implementations" requirement for general web features.

@aleventhal
Copy link
Contributor

I'd be concerned about having a big lag between us landing support for something and it being in the docs.
Or with another vendor implementing support in their API, but us not seeing in the Docs and thus not knowing how to support it (e.g. WebKit + VO).

What would 2 implementations mean? Are we talking about 2 browsers, 2 platform APIs or 2 ATs? Do Edge and Chrome count as separate browsers?

@aleventhal
Copy link
Contributor

A thought: should we have a deep dive where we discuss the lifetime of an ARIA feature, how it happens, who's involved, etc. so that we can make the entire process better? My initial feeling about this was that it's potentially good, because it would maybe create more involvement and awareness, both from AT vendors who would be needing to write a public stance, as well as from ARIA WG members, who currently don't have much insight into some of the work behind the scenes. Maybe if we take a step back and look at the big picture we can find multiple areas for improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants