4 ms·

> 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 diffe

> 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
  > At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Framework to .NET Core. That would be true if it were common for applications to directly support alternative UI modalities, but that's not how accessibility generally works. An application implements a GUI, including support for the platform accessibility API (hopefully with the help of the GUI framework), and it's up to a separate assistive technology, such as Narrator (for screen reading) or Dragon NaturallySpeaking (for speech input), to use that generic accessibility support to adapt the UI for a specific need. So if any assistive technologies are using .NET Framework, they might have a bit of difficulty converting to .NET Core. But that's a small number of applications, and in my experience, most Windows ATs use native code anyway. And using SAPI via COM interop isn't hard; you don't have to get down and dirty with P/Invoke or anything similarly low-level.
  - Lariscus 6y ago
    This little discussion got me curious about how hard it actually is to use COM interop with .NET. Using Visual Studio its just a right click on your dependencies, selecting 'Add COM Reference...' and choosing the library you want to use. I was then able to call SAPI very easily like this: var voice = new SpeechLib.SpVoiceClass(); voice.Speak("Hello World!"); The documentation for SAPI could use some love though. The sample code that is supposed to be there is nowhere to be found.

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
> At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Framework to .NET Core. That would be true if it were common for applications to directly support alternative UI modalities, but that's not how accessibility generally works. An application implements a GUI, including support for the platform accessibility API (hopefully with the help of the GUI framework), and it's up to a separate assistive technology, such as Narrator (for screen reading) or Dragon NaturallySpeaking (for speech input), to use that generic accessibility support to adapt the UI for a specific need. So if any assistive technologies are using .NET Framework, they might have a bit of difficulty converting to .NET Core. But that's a small number of applications, and in my experience, most Windows ATs use native code anyway. And using SAPI via COM interop isn't hard; you don't have to get down and dirty with P/Invoke or anything similarly low-level.
- Lariscus 6y ago
  This little discussion got me curious about how hard it actually is to use COM interop with .NET. Using Visual Studio its just a right click on your dependencies, selecting 'Add COM Reference...' and choosing the library you want to use. I was then able to call SAPI very easily like this: var voice = new SpeechLib.SpVoiceClass(); voice.Speak("Hello World!"); The documentation for SAPI could use some love though. The sample code that is supposed to be there is nowhere to be found.