the highlights are great. 2 lowlights:
- HttpClient/WebRequest ReadWriteTimeout is silently ignored which can result in infinitely hung sockets when doing synchronous network i/o
- System.Speech is unsupported
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++).
"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.
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.
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.
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.
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.
var voice = new SpeechLib.SpVoiceClass();
voice.Speak("Hello World!");
That pretty much means MS is deprecating it in favor of the Azure speech services...yeah, bummer.