CORE-AAM 1.1: Create macOS mappings for aria-details

[richschwer]

Moved from this action in tracker: https://www.w3.org/WAI/ARIA/track/actions/2119

[cookiecrook]

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

[richschwer]

James, aria-details is in place to provide a link to alternative content that in many cases cannot be stringified. This was the concession the digital publishing community put in place that allowed them to agree to remove longdesc. It was the understanding, as you were not objecting, that this was acceptable. Having the major EPUB rendering platform iBooks not be able to handle this is going to cause an interoperability issue. It will be supported in Chrome as it is supported in Firefox. We have a new relationship for it. It in no way must be stringified. I read your webkit comment: https://bugs.webkit.org/show_bug.cgi?id=165842. I urge you to reconsider. Please provide a mapping of some kind other than no mapping.

[cookiecrook]

This was the concession the digital publishing community put in place that allowed them to agree to remove longdesc. It was the understanding, as you were not objecting, that this was acceptable.

"No objection" is not the same as "intent to implement." I don't see harm in supporting it. It's just not as high a priority as some of the other bugs and features. I mentioned in the WK tracker that, "If someone were to present a more compelling use case, or if it starts getting wider adoption, WebKit should pick it up."

It will be supported in Chrome as it is supported in Firefox.

Please comment in the WK bug once it starts gaining critical mass.

Any of the following would do:

1. Two browsers, two APIs, and two screen readers. Or…
2. Many websites (or a few major ones)
3. Many epubs (and/or a few major publishers)

[cookiecrook]

By the way, when will the AAM docs be living standards? That's a much better choice than Rec track standards for mapping docs.

[richschwer]

To my knowledge w3c does not do living standards and this is orthogonal to finishing the existing core-aam which is not a living standard. That is something the chairs and w3c management could take up later - maybe during 1.2 development.

[cookiecrook]

@stevefaulkner Isn't the HTML mapping guide intended to be a living standard?

[cookiecrook]

Clearing myself as an assignee because I don't expect WebKit implementation of this feature for 1.1. If there are two other implementations, it can advance. If not, it should be postponed until a later release or until such a time as the AAM docs transition from Rec track to Living Standards.

[joanmarie]

[...] I don't expect WebKit implementation of this feature for 1.1.

Fair enough. But at the risk of seeming (being?) obsessive: What is the official mapping for this feature for your platform? Possibilities include, but are not limited to:

• "not mapped"
• "to be determined by Apple" (perhaps with an accompanying note)
• "AXARIADetails"

The reasons I want a mapping/decision from you/Apple include:

• Eliminating the "TBD" because that suggests to readers (including the Director) that the Working Group may have forgotten something. We haven't.
• Google Chrome and Firefox have browsers which implement NSAccessibility and work with VoiceOver. They might want to include support for this property on all platforms, including yours. In order to do so, they need to know what the correct mapping is for your platform. If that mapping is known already by Apple, let's document it so that Google and/or Mozilla can implement support correctly. If that mapping is not yet determined by Apple -- or if the mapping is "not mapped" -- that's fine too. Let's document that in the Core AAM so that Google Chrome for macOS and Firefox for macOS don't stick it in some NSAccessibility property where it doesn't belong.

If you could help me clear this "TBD" (even if it's with a more formal "to be determined by Apple" and a proper/appropriate-for-a-spec note) I would really (really, really) appreciate it.

[cookiecrook]

"Not mapped" is fine.

[joanmarie]

"Not mapped" is fine.

Done (6021b77). Thanks!