What? This description makes no sense. Nothing changed with at-spi2, that is X.org/Wayland independent. The only think which got added (and is already suppored by Kde) is a protocol to inform the screen reader about keyboard events, as it previously used the "anyone in my session can read my keyboard" capability of X.org.
You would need the accuracy of these models to be way, way, better than today (so you do not lie to the user which has no idea about the fact that the output is a lie, because he can't compare the model output with the input, because he can't see that), their hardware requirements way, way, lower (so you don't need a game rig for useful computing in these groups), so, no, I can't agree, this A.I. approach will not save you from correct semantic markup.
Definitely much better now, in a day-to-day usage I found a crash situation only once in this year.
Note: I am a visually impaired Linux user and developer, I actually did the work on the shortcuts capturing API.
I definitely agree. Much more if you need support for screen readers, then you can't use the slowly emerging alternatives even for a test drive, because either the a1y stack is not a priority, or the supporting libraries are not featureful enough.
That's partially true, but fortunately not completely. There are widely use open-source screen readers for Windows and, of course, there's no proprietary screen reader on Linux.
And, definitely, there are standard APIs which are used to communicate the accessibility tree between an app and a screen reader. Yes, they are specific for each platform, and Windows has multiple of these, but they are standardized at least for each platform.
The basics work, however for example screen readers do not anounce context menus under Windows, treeviews are not providing all the information they could see (https://bugreports.qt.io/browse/QTBUG-81874?jql=text%20~%20%...), etc. But in the end, if you need somewhat more advanced widgets (tables etc.) and you do not want to implement the gui on each platform or use Electron or similar, you have no choice.
Agreed, making the divs article tags or adding an article role would help, but personally, as a blind user, i don't care as much, the content is interesting enough that it's not a big deal. You can deduce the tree structure anyway, at least most of the time.
Personally, i would not call Gnome as the most accessible as of now. From personal experiences, Mate fares better in this regard. Of course, it has its quirks as well.
Unfortunately, this is missing the semantic metadata about the fact that it's a tree. It might be fine in some cases, but in general you would want to add some Aria attributes. But i'm not sure whether you could generate the entire thing server-side.
I might start to be grateful for the screen reading software - these tricks fortunately don't work when you use NVDA or Orca, because they have its own virtual buffer and they intercept the copy command soon enough that the browser has no idea about it.
Agreed. And some accessibility related work would also help, for now, i doubt i would have any chance convincing any of my visually impaired friends to use the keybase apps.
Generally speaking, yes, they do. But the answer is, as always, more complex than that.
Firstly, some types of games (text adventures, MUDs etc.) are more favorable for enjoynment by visually impaired people. When it comes to the traditional genres, it usually ends up being an issue, e. g. the mainstream games more often than not are not playable, but there's an entire genre of games which do not rely on visual information and instead use audio (usually stereo + might be some HRTF tricks).