Earlier quoted context omitted.
I have my opinion on aesthetics of additional ways of repeating information already available by color coding. But to each their own. Other than that, is enabling/disabling any of the aforementioned features ever a question of aesthetics?
For example, opting to not enable high-contrast mode is a question of aesthetics. Arguably reading text would become easier for the user, but they prefer to sacrifice a little of the readability in favor of looks.
GUIs should be fully keyboard-driven
521–530 of 534 posts
Re: GUIs should be fully keyboard-driven
#522Earlier quoted context omitted.
> showing the relevant keyboard shortcuts in the UI can be overwhelming Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.
This works poorly if you intend to localise your application. Great if you don't though.
Re: GUIs should be fully keyboard-driven
#523Earlier quoted context omitted.
> accessibility is just usability. all it is is making sure your product is as usable by as many people as possible. Not always. There are things that increase usability for fully abled people but decrease it for disabled people. Color-coding is a common one. Another is using smaller font size to make more info visible at once, or advanced touch gestures that can be accidentally triggered by shaky hands. Then there a…
> Another is using smaller font size to make more info visible at once This doesn't sound very usable to me.
Re: GUIs should be fully keyboard-driven
#524Earlier quoted context omitted.
once again, I get to cite the IBM AS/400 CallPath system demonstrated here https://youtu.be/5pY6Xxptp9A?t=2083 which almost brought a tear to at least one viewer's eye
Pretty cool video. I would love to know more about the internal design of the as400 platform and how people thought and designed user interfaces. I can't shake the feeling that these interfaces are so lean they're satisfying. Also, I feel that a lot of interfaces today are wasting resources.
Re: GUIs should be fully keyboard-driven
#525Earlier quoted context omitted.
Dlangui is so niche that I am amazed to even see it here. DearImGui is intended for thowing together some slap-dash UI widgets for debugging things like interactive rendering. Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them.
> Dlangui is so niche that I am amazed to even see it here. Eh, I'm testing whether I can make it fully accessible, since I happen to like the D language itself. But the UI without my changes is entirely inaccessible. > DearImGui is intended for thowing together some slap-dash UI widgets for debugging things like interactive rendering. That's probably what it's intended for, but people use it for far more than that,…
Re: GUIs should be fully keyboard-driven
#526Re: GUIs should be fully keyboard-driven
#527Earlier quoted context omitted.
This is where using a common framework pays dividends. For example, on the desktop I can disable animations for all GTK applications.
I stopped using GNOME after 3, but there were still quite a few animations in the GNOME core programs despite having the disable animation setting set. I wonder if that's changed.
Re: GUIs should be fully keyboard-driven
#528Earlier quoted context omitted.
Nor just shape, so a warning icon + text message.
and, as is being increasingly forgotten, SOUND QUES. Seriously, I get they can be annoying but they make navigating and interacting with things so much easier if you can't see them. Sure, TTS exists but is far more inefficient and objectively less helpful in these kinds of circumstances
Re: GUIs should be fully keyboard-driven
#529Earlier quoted context omitted.
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 adjustm…
> 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…
Telle that to Anthropic, as Claude code doesn't let me copy any text from its TUI.
Re: GUIs should be fully keyboard-driven
#530Earlier quoted context omitted.
I had to keep accessibility in mind a lot in my previous job (web development for a university). The thing that I consistently found was that, the more accessible a website was, the better the experience for everyone , not just people with disabilities.
This is true in other fields too. Wheel-chair ramps are used by people with baby strollers. Subtitles work for deaf people, those who can't understand the spoken language, or simple folks in situations where someone is sleeping next to them. Pretty much every accessibility-oriented feature ends up helping out people beyond the original audience.