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

Compatibility with platform accessibility APIs? #88

Open
minorninth opened this issue Jun 1, 2021 · 3 comments
Open

Compatibility with platform accessibility APIs? #88

minorninth opened this issue Jun 1, 2021 · 3 comments
Labels
Browsers Browsers Vendors

Comments

@minorninth
Copy link

Do we have any input from (1) the owners of accessibility APIs, such as IAccessible2, UI Automation, ATK, NSAccessibility, Android, etc. on how this information could be conveyed to AT by the user agent?

I believe that both Android and macOS already have technical ways to specify pronunciation rules in text that's returned from a user agent via accessibility APIs. I think this specification wouldn't be complete until it contained a complete and comprehensive implementation guide for how to transform the specified SSML into those platform-specific representations.

@alia11y
Copy link
Collaborator

alia11y commented Jun 30, 2021

Thank you for your comments, Dominic. we are seeking inputs from the owner of a11y API.

@alia11y alia11y added the Browsers Browsers Vendors label Oct 13, 2021
@leo60228
Copy link

As a disclaimer, I don't have any background in platform accessibility APIs, and I'm looking at this spec from the perspective of a web developer trying to ensure correct pronunciation from screen readers. However, as far as I can tell, only UIAccessibility on iOS has existing support for pronunciation, though SwiftUI's speechPhoneticRepresentation method is listed as supported on macOS 12.0+.

On iOS, there are five speech attributes for text as part of UIAccessibility. Of these, only accessibilitySpeechIPANotation maps cleanly to the spec (data-ssml-phoneme-ph). accessibilitySpeechLanguage specifies the language of the content, which is explicitly the lang attribute's job. accessibilitySpeechPitch is conceptually the same as data-ssml-prosody-pitch, but the former is a 0.0-1.0 scale and it's not clear how the latter should be mapped to this. accessibilitySpeechPunctuation is a boolean for whether punctuation should be spoken. The SSML spec implies that this would map to data-ssml-say-as-detail, but the note on say-as values doesn't back this up. The final attribute is accessibilitySpeechQueueAnnouncement, which from my understanding is only relevant to notifications.

@leo60228
Copy link

I think this specification wouldn't be complete until it contained a complete and comprehensive implementation guide for how to transform the specified SSML into those platform-specific representations.

Emphasizing that I don't have background experience with platform accessibility APIs, but I feel like this should be specified by them. I'm not sure how easy it'd be to get in touch, but maybe at least the GNOME people could be interested?

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

No branches or pull requests

3 participants