In the context of discussing TUI vs GUI (as the article does), the accessibility and keyboard control balance probably swings very strongly to native GUIs; in a TUI you’re at the whim of the TUI framework’s stabs at accessibility support, while on a full fledged native UI you have all the bells and whistles of focus management and text to speech and voice control and high contrast and magnification and motion adjustments…
The idea that it must be more accessible because it’s confined to a mono space typeface and communicates state mostly by changing the foreground and background color of the text it renders makes no sense to me.
It's very hard to make a TUI (or a web app) that has 0 screen reader accessibility. It's also much harder to make a TUI that has great screen reader accessibility (it's much easier for web apps). "native" apps are a much wider spectrum.
With a TUI or a web app, screen readers will always have some access, because no matter what you do, the text layer is always there. This may not be enough accessibility to use the app or to complete some specific workflow, but a screen reader user will at least have a rough idea of what's going on. For web apps, that's a good basis to start from once you finally realize that accessibility is something you need.
Desktop apps are much more of a mixed bag. Most frameworks draw their UI themselves, basically pixel by pixel, instead of using some text-based platform primitives. If your framework doesn't expose UI semantics to the OS, a screen reader user gets absolutely nothing, basically a blank window with no visible content or controls. If you're just a developer using that framework, it's a very difficult situation to get out of, once a11y becomes a business requirement.
GTK on anything but Linux is the major offender these days, so are many niche Rust frameworks and anything involving game or game-like UI. QT, Java Swing and Flash used to be this way historically.
> The idea that it must be more accessible because it’s confined to a mono space typeface and communicates state mostly by changing the foreground and background color of the text it renders makes no sense to me.
That's not why. It's because TUI apps have to be designed around the strong possibility that a mouse isn't even available.
Also in a TUI you never ever have that issue that some text isn't copy/pastable like some dialogue boxes, in which case the screen reader might have issues picking it up too.
And in a TUI you don't have to deal with that window management crap. Moving stuff around because something else is on top. Everything happens within that little square.
There's TUI and there's CLI. TUI has always been poor man's GUI, back in the day it was even literally called GUI. CLI on the other hand has zero similarities with GUI. You write the command and the command executes and that's it. Writing commands is inherently the most accessible form of controlling computers, second only to dedicated single-purpose buttons that don't mesh well with this whole "general purpose computing" thing.