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.

What evidence do you have to say that the accuracy right now is bad? UI recognition is generally much easier than photographic recognition. Additionally, per the original point re: boling the ocean, it is more likely that a person has a CV-based screen reader than every website they are visiting having ARIA tags.

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.

Unfortunately for the paid IDEs, even the accessibility for screen readers is much better in VSC.

That's so interesting seeing the somewhat usable language rise from the most basic elements.

Great overview, i am thankful that accessibility was mentioned as well.

Accessibility is the special focus of mwcampbell :)

To be clear though, I didn't write the post; I just spotted it and submitted it.

Fair enough, thanks for the clarification!

The argument would be that a new GUI toolkit will capture applications that would otherwise be made with an older, accessible toolkit. In that sense, it‘s a regression, not just a clear improvement.

I do agree about the idea though. We shouldn't shut down experiments just because they don‘t have a plan for it yet. I do see some of that on twitter etc. But once you‘re shipping software that users can‘t switch away from, because of network effects or because it‘s at work, it‘s not ok.

Also, yeah, I (not OP) depend on it.

Personally, i mostly use braille input for longer messages and for shorter ones speech recognition or the standard keyboard.

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.