[css-speech-1] CSS Speech 1 should not move to Rec until there are at least 2 implementation combinations of 2 combinations of "user agent + platform API + assistive technology" for every feature

[cookiecrook]

[css-speech-1] CSS Speech 1 should not move to Rec until there are at least 2 implementation combinations of 2 combinations of "user agent + platform API + assistive technology" for every feature

Perhaps this requirement should go without saying, but I'm listing it here as a blocking issue for css-speech-1 because:

• CSS 3 Speech went to PR/TR without implementations.
• Since that time (6+ years?), there have been few implementations of a few features, and no implementations of many features.
• As far as I know, most css-speech-1 features remain unimplementable by the user agents on most platforms because there is a lack of Accessibility API support. That could change, but it would need an incubation effort.

Unlike most CSS features, Speech is rarely (if ever) rendered by the user agent. As an example, fallback fonts are handled by the UA rendering engine so it can implement, or not, without dependency. Speech in most (perhaps all?) mainstream assistive technology is not rendered by the UA. Speech generated from web pages requires the rendering engine to expose certain properties or features through the platform accessibility API. The API in turn is accessed by the assistive technology, which renders the speech.

I’m not aware of API support for fallback voice electives (and many other CSS Speech features) in accessibility APIs so there is a gap here. Some AT supports language fallbacks because the lang attribute is exposed (e.g. as AXLanguage in the Mac AX API), but in this case, the AT can’t render what is not exposed, and the UA has no way to expose it. I believe the same is true on other platform APIs.

Again, this could change, but it would need an incubation effort to convince a combination of at least 2 platform API maintainers and 2 assistive technology developers that this is a priority. The "2 implementations" requirement applies to 2 combinations of "user agent + platform API + assistive technology." ARIA went through a similar testing requirement.

[frivoal]

CSS 3 Speech went to PR/TR without implementations.

TR ("Technical Reports") is where we publish specifications, regardless of status or maturity.

CSS-speech would indeed be inappropriate to publish as a PR (Proposed Recommendation), but that is not what happened.

In order to publish a few corrections that had been made to the previous publication as CR, It was re-published as CR (a few years after the decision to do so, after a getting lost in publication limbo for a few years due to various publication / deployment mishaps) as representing the best thinking of the WG at the time the decision to publish was taken.

For the reasons you said, it cannot progress beyond that stage at the moment. It can linger at CR for a while longer, it can be revised (a little or a lot) and be republished as a CR (or an earlier maturity should we chose that), or it can be abandoned, but it will not proceed to REC unless fully implemented twice (or more). So while the points you raise are absolutely valid, there is no need to be concerned it would accidentally be pushed to REC as things stand today. It cannot and will not.

[cookiecrook]

Thanks. I always thought TR was "Technical Recommendation" as in the final stage of Rec track after CR/PR. I'll adjust my vocabulary accordingly.

Thanks for confirming it cannot move to PR without complete implementations. However, perhaps it's not mature enough to move to CR either? @LJWatson expressed an interest in attempting a new working draft to resolve the larger issues.

[frivoal]

Going to CR doesn't mean it's finished, it means the WG has answered all the issues it could raise itself, asked for external feedback, and addressed (not necessarily agreed with) all the feedback it got, and thinks that it's as good as its going to get without getting additional feedback, presumably although not necessarily derived from implementation attempts. It seems to me that these conditions were met at the time the resolution to update the CR was taken. (The fact that there was a multi-year lag between taking that decision and doing the publication blurs things quite a bit).

I also think that looking at it now, it is also clear that there are more new issues are being raised, that old issues are being made newly relevant (for instance, due to largely giving up on media types, issues that were rejected because they weren't relevant to the speech media type should be reevaluated), that we as a community have learned more about how all these things fit together, and that therefore there's a bunch more things that should be addressed.

If this spec had never been at CR before, and someone were to propose to take it to CR now, I don't think it'd be appropriate. Given that it has been a CR already (since 2012!), whether we should fix the issues and update the CR, or take it back to Working Draft is an interesting question, not fully answered by the Process itself.

My take on it is that we should start by looking at the issues (and filing more if appropriate). If it looks like some moderate number of adjustments can resolve these issues, we should publish an updated CR with these adjustments in place. If it looks like this is going to require a fundamental redesign / rework of the whole thing, then it may be more appropriate to signal that we're taking this back to the drawing board by republishing at an earlier maturity (WD).

Overall, I think technical discussions should take the priority over process wrangling for now, and that we can look at how we should publish things again a little while later.

You have already filed a number of issues, and that's great. I think I want to file a few more myself. In a little while, the extent of the changes we want to do to the spec based on these issues will inform how we want to republish it.

[LJWatson]

A brief heads up to everyone here. It seems that events starting with the CR notification on CSS Speech has caused some upset in the APA WG. APA WG has a Pronunciation TF that is trying to solve the problem of how Text To Speech (TTS) handle the pronunciation of content. An important use case is the correct pronunciation of things like scientific terms, particularly in the educational context. The TF has considered several existing technologies including CSS Speech, SSML, ARIA and others, as possible solutions. They have narrowed it down to two possibilities: SSML in the browser or an SSML attribute with similar capabilities. The CR notification seems to have prompted concern that a specification APA believed to be dormant was surfacing again, and that somehow it represents a challenge to the work being done by the Pronunciation TF. I did my best to explain this wasn't the case and that CSS Speech should not have been published as a Note and that the re-publication as CR was intended to correct that course, but this led to questions about why it was going to CR when there were outstanding substantive issues raised against it. Alan, it wouldn't surprise me if this gets raised by the W3 team at some point. I'm afraid my offer to co-edit, which I thought would be a positive thing, has also ruffled a few APA feathers it seems. What's the phrase - "No good deed goes unpunished"? Anyway, I wanted to mention this because I suspect it's likely to surface in the following days/weeks and I didn't want any of you to be blind-sided like I was on the APA call today.

…

On 14/03/2020 03:38, Florian Rivoal wrote: Going to CR doesn't mean it's finished, it means the WG has answered all the issues it could raise itself, asked for external feedback, and addressed (not necessarily agreed with) all the feedback it got, and thinks that it's as good as its going to get without getting additional feedback, presumably although not necessarily derived from implementation attempts. It seems to me that these conditions were met at the time the resolution to update the CR was taken. (The fact that there was a multi-year lag between taking that decision and doing the publication blurs things quite a bit). I also think that looking at it now, it is also clear that there are more new issues are being raised, that old issues are being made newly relevant (for instance, due to largely giving up on media types, issues that were rejected because they weren't relevant to the |speech| media type should be reevaluated), that we as a community have learned more about how all these things fit together, and that therefore there's a bunch more things that should be addressed. If this spec had never been at CR before, and someone were to propose to take it to CR now, I don't think it'd be appropriate. Given that it has been a CR already (since 2012!), whether we should fix the issues and update the CR, or take it back to Working Draft is an interesting question, not fully answered by the Process itself. My take on it is that we should start by looking at the issues (and filing more if appropriate). If it looks like some moderate number of adjustments can resolve these issues, we should publish an updated CR with these adjustments in place. If it looks like this is going to require a fundamental redesign / rework of the whole thing, then it may be more appropriate to signal that we're taking this back to the drawing board by republishing at an earlier maturity (WD). Overall, I think technical discussions should take the priority over process wrangling for now, and that we can look at how we should publish things again a little while later. You have already filed a number of issues, and that's great. I think I want to file a few more myself. In a little while, the extent of the changes we want to do to the spec based on these issues will inform how we want to republish it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4871 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2WX2LPHS7PN6YBIBKP4M3RHL3Z7ANCNFSM4LGXJ5JQ>.

-- Director @TetraLogical

[astearns]

Thanks for the heads-up, @LJWatson. I'm hoping your co-editing css-speech will allow the APA to feel more engaged with the spec and where it ends up. If the Pronounciation TF has a better alternative, that should definitely factor in to how we handle this draft.

[LJWatson]

I'm hoping your co-editing css-speech will allow the APA to feel more engaged with the spec and where it ends up. If the Pronounciation TF has a better alternative, that should definitely factor in to how we handle this draft.> This is my hope too. I'm going to meet with the Pronunciation TF next week and will keep everyone posted.