4 ms·

IIUC, System.Speech was simply a .NET wrapper for the Microsoft Speech API (SAPI), which has been part of Windows for a long time. If you want to move to .NET C

IIUC, System.Speech was simply a .NET wrapper for the Microsoft Speech API (SAPI), which has been part of Windows for a long time. If you want to move to .NET Core, you can use SAPI via COM interop. Disclosure: I currently work at Microsoft on the Windows accessibility team. We don't own SAPI or System.Speech, but we consume SAPI in Narrator (via COM in C++).

mmd45 6y ago
why doesn't MS just release the SAPI wrapper as a windows only nuget package since it already exists?
- mwcampbell 6y ago
  One thing I've learned in my time on the accessibility team at MS is that even at a company as large as Microsoft, any given team has limited resources and only so many person-hours in a day. So every task has to have a business justification. There probably hasn't been enough demand for releasing System.Speech as a NuGet package to justify it. That's just my guess though; I haven't talked to the speech or .NET teams about this.
  - mmd45 6y ago
    i understand that, but i'll bet if they would dump the source to dotnet/unsupported/system.speech the community would do the work for them to get squared up with dotnet core. it doesn't take a lot of demand, just 1 or 2 developers who view it as a blocking requirement for netcore migration.
  - ocdtrekkie 6y ago
    https://www.microsoft.com/en-us/accessibility https://www.microsoft.com/en-us/accessibility "Microsoft is committed to revolutionizing access to technology for people living with disabilities—impacting employment and quality of life for more than a billion people in the world." "To enable transformative change accessibility needs to be a priority. That’s why we have begun to manage it like a business and developed our Accessibility Evolution Model to track our progress." I feel if these statements are true, Microsoft executives should require good maintenance of APIs heavily depended on by accessibility features, and should direct the appropriate teams to prioritize this issue. Because today, in pushing developers to move to a platform that doesn't support System.Speech, Microsoft is moving backwards.
ocdtrekkie 6y ago
I recognize this. But so is WinForms and plenty of other Windows-specific APIs. System.Speech, being as you recognize, a crucial accessibility feature, and it should be considered extremely high priority, even if the usage percentage is low. Microsoft should prioritize fixing this over other tasks with .NET, if they value accessibility users. It'd be nice for a cross-platform local speech library to be available on .NET, and it'd be nice if the Speech team wasn't likely incentivized to push Azure, but at minimum, existing accessibility functionality should be understood to be crucial.
- mwcampbell 6y ago
  > System.Speech, being as you recognize, a crucial accessibility feature I'm the first to push for prioritizing accessibility when needed. But there's a difference between an accessibility gap that prevents a person with a disability from completing some task, and a missing convenience wrapper for an API that a developer could pretty easily use through generic COM interop. So I don't think it's appropriate to play the accessibility card in this case.
  - ocdtrekkie 6y ago
    I mean, nearly all outstanding documentation and tutorials on how to implement speech in Windows is conveyed via those APIs. I know I don't have the skills to replace my System.Speech calls with generic COM interop, I'm willing to bet that would ring true for a lot of .NET developers relying on the .NET Framework today. At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Framework to .NET Core. How many businesses are going to do that, versus say, drop that feature, presumably due to "low usage"? Is Microsoft really serving the accessibility community here? Making it harder to add accessibility to software is going to negatively impact accessibility being available in software. And if it's just a convenience wrapper, it should be trivial for Microsoft to reimplement it: And it'd be far less wasteful for Microsoft to do it for everyone than expect everyone who uses it for accessibility features to reimplement it themselves.
    - mwcampbell 6y ago

mmd45 6y ago

why doesn't MS just release the SAPI wrapper as a windows only nuget package since it already exists?

mwcampbell 6y ago
One thing I've learned in my time on the accessibility team at MS is that even at a company as large as Microsoft, any given team has limited resources and only so many person-hours in a day. So every task has to have a business justification. There probably hasn't been enough demand for releasing System.Speech as a NuGet package to justify it. That's just my guess though; I haven't talked to the speech or .NET teams about this.
- mmd45 6y ago
  i understand that, but i'll bet if they would dump the source to dotnet/unsupported/system.speech the community would do the work for them to get squared up with dotnet core. it doesn't take a lot of demand, just 1 or 2 developers who view it as a blocking requirement for netcore migration.
- ocdtrekkie 6y ago
  https://www.microsoft.com/en-us/accessibility https://www.microsoft.com/en-us/accessibility "Microsoft is committed to revolutionizing access to technology for people living with disabilities—impacting employment and quality of life for more than a billion people in the world." "To enable transformative change accessibility needs to be a priority. That’s why we have begun to manage it like a business and developed our Accessibility Evolution Model to track our progress." I feel if these statements are true, Microsoft executives should require good maintenance of APIs heavily depended on by accessibility features, and should direct the appropriate teams to prioritize this issue. Because today, in pushing developers to move to a platform that doesn't support System.Speech, Microsoft is moving backwards.

ocdtrekkie 6y ago

I recognize this. But so is WinForms and plenty of other Windows-specific APIs. System.Speech, being as you recognize, a crucial accessibility feature, and it should be considered extremely high priority, even if the usage percentage is low. Microsoft should prioritize fixing this over other tasks with .NET, if they value accessibility users. It'd be nice for a cross-platform local speech library to be available on .NET, and it'd be nice if the Speech team wasn't likely incentivized to push Azure, but at minimum, existing accessibility functionality should be understood to be crucial.

mwcampbell 6y ago
> System.Speech, being as you recognize, a crucial accessibility feature I'm the first to push for prioritizing accessibility when needed. But there's a difference between an accessibility gap that prevents a person with a disability from completing some task, and a missing convenience wrapper for an API that a developer could pretty easily use through generic COM interop. So I don't think it's appropriate to play the accessibility card in this case.
- ocdtrekkie 6y ago
  I mean, nearly all outstanding documentation and tutorials on how to implement speech in Windows is conveyed via those APIs. I know I don't have the skills to replace my System.Speech calls with generic COM interop, I'm willing to bet that would ring true for a lot of .NET developers relying on the .NET Framework today. At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Framework to .NET Core. How many businesses are going to do that, versus say, drop that feature, presumably due to "low usage"? Is Microsoft really serving the accessibility community here? Making it harder to add accessibility to software is going to negatively impact accessibility being available in software. And if it's just a convenience wrapper, it should be trivial for Microsoft to reimplement it: And it'd be far less wasteful for Microsoft to do it for everyone than expect everyone who uses it for accessibility features to reimplement it themselves.
  - mwcampbell 6y ago