Unicode and screen readers rarely mix well, unless non-Latin languages are represented to have a TTS engine use a Russian voice to speak... Oh, that's Ukrainian

Unicode and screen readers rarely mix well, unless non-Latin languages are represented to have a TTS engine use a Russian voice to speak... Oh, that's Ukrainian text... Oops. People spicing up their social media posts with Unicode mathematical italic text gives every screen reader a hard time. Screen reader developers are busy fixing operating system and app developers' accessibility issues much of the time, and barely have time to make text read correctly which wasn't designed with accessibility anywhere near the mind. We either need more accessibility "experts" working on screen readers and text-to-speech tools (try listening to ESpeak for a while. Yes, it's in your Linux package manager,) or more plain developers taking time to consider how a screen reader will read your button labeled only with a picture, or "submit@2xBTN." The problem with the first approach is that there are very few accessibility "experts." Experts, in this arena, are plain people that have done the work to learn how accessibility tools work, how HTML and JavaScript interact with those tools, and do work auditing websites or apps for accessibility, or working at a training center or something. Those people do demanding work that very few others are able to do, so are in short supply. They don't want to come home to dig into code others have written to find that they didn't label a button, or they didn't tag this div with a lang attribute so a TTS engine, if it even has more than the most popular European languages, will speak Ukrainian instead of Russian. Some screen readers don't even try to guess at a non-Latin language, they just read out "Serilic letter ER, Serilic letter U, Serilic letter S," and so on. Why? Because ESpeak, the TTS engine I have in mind, is an open source project that has no guarantees as to its usability in any context or purpose. And yet, because it has support for so many languages that no other TTS engine supports, it's used by Google. Just look at your ChromeBook's list of TTS engines. For the longest time, it was also used in Google Translate. Your open source project might just be used in a big company someday. Yet, how many people contribute to it? How many linguists are on the team? How many people try to make it sound better? The problem with the second approach is that developers aren't taught anything about accessibility, so feel woefully underprepared to face accessibility issues. So they punt to the "experts," of which there are very few. They don't begin looking at documentation, or look into NVDA source code to see how accessibility is done on a programatic level, or oh I don't know, ask disabled users to test their software cause what if they say no? Oh no maybe I'll offend a blind person! /s. So it goes nowhere. So, don't sit there and blame screen reader developers if you've not looked through their code and seen all the workarounds they do to get text to read as well as they do now, and the ESpeak code, now ESpeak-ng cause the old developer died or something, and seen how few maintainers it has. Now, big companies like Apple and Microsoft have little excuse for how crappy their TTS engines and screen readers are. Apple's TTS engine is one of the best, but the voice usually used, Alex, hasn't been updated in some time, although MacinTalk has filed down some of his rough edges. Still, those teams are also very small, not like the hundreds working on the iPhone's camera. Apple could, and should, hire more people in those rolls, especially as the bugs are piling up high at this point. But I doubt they will. They've lost their sense of design and beauty and are now just another enshittified tech company.