You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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.
The text was updated successfully, but these errors were encountered: