Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

Post reply on HN
Print view View original

391–400 of 507 posts

Re: GUIs should be fully keyboard-driven

#391

Post by MrVandemar »

stillpointlab wrote: post #279
MrVandemar wrote: post #275

Earlier quoted context omitted.

> It is a business opportunity as well. I worked at a company that paid for an audit before LLMs. There is tremendous cost savings possible here. Do you know one of the most underemployed groups are disabled people? And do you know where a number of disabled people get employment? Disability audits (unsurprisingly they're extremely good at this). Congratulations on recommending further marginalising an extremely marg…

I suppose it is a question of balance between: the entire web being better for all those that require accessibility vs. a subsection of that community holding their jobs. And it raises the possibility that the increased accessibility could lead to more job opportunities. But I'm not really a consequentialist and think of things in virtue ethics terms. And using technology to scale benefits to a wider group of people…

It's not "virtue ethics". It's a fact: turning accessibility testing over to "AI" will deprive a group of low-income low-agency people with skin in the game of employment.

If society were perhaps more compassionate, and supportive of this group, then perhaps it wouldn't be so much of a problem.

As to your point about significantly improving accessibility of the web, we could do that right now, all of us, without "AI". We could have done that yesterday. Use semantic HTML, instead of injecting div-soup using Javascript into ad-riddled dark-patterned user hostile slop-pages.

"AI" (or accessibility audits themselves) are a bandaid after the fact. Accessibility needs to be baked in.

Re: GUIs should be fully keyboard-driven

#393

Post by eviks »

ckardaris wrote: post #388
eviks wrote: post #363

Earlier quoted context omitted.

But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation And more pressure from more options doesn't follow, you only need to study if you actually want to diverge

> But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation. The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut. true This is…

> The developer needs to know what to do.

No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed)

> What if the developer creates an unorthodox menu

What is he draws a circle instead of using a letter O? What of it?

Re: GUIs should be fully keyboard-driven

#394

Post by zelphirkalt »

Timwi wrote: post #379
zelphirkalt wrote: post #354

Earlier quoted context omitted.

I have a traditional desktop app/GUI app, where I have a table (treeview) of words with their translations and pronunciation (like a dictionary). There can be thousands of words in there. Also there is a filter/search field, where one can input any string to filter the table while typing, or confirming pressing enter/return. The words in the table can be in any language, if the configuration of the application is adj…

1. Make sure that the tree view control has screen reader support and that it has all the normal keyboard commands (such as right/left arrow for expanding/collapsing a parent node). 2. Make sure that the text box has a label that says “search” or “filter” and not just a magnifying glass icon. You can only get away with an icon if the GUI toolkit allows you to give it an alt text. 3. Make sure that this label has a ho…

Hm OK thanks for the pointers.

Point 1: I don't know whether tkinter's treeview has screen reader support. I will have to look into that. But what I did already do is to make it focusable, which it wasn't by default, I believe, and add controls like: up, down to select rows, pos1/home and end to go to first row or last row, space to select/highlight a row, I left right and left arrow key for opening and collapsing items, added enter and various other keys to trigger actions for focused row or all selected rows.

Point 2 I definitely have.

Point 3: I defined a shortcut (ctrl+f) that always focuses the text input widget of the filter, but I don't have a letter underlined in the label. The label is actually "Quick search" and not "Quick filter", which means I couldn't underline an "f". But also underlining any letter might indicate, that one could press ALT+letter to focus the input. Maybe I should add another shortcut to facilitate that and then truly underline the appropriate character. Maybe change the label to simply read "Filter" and use the "F".

Point 4 I have. The filter is directly under the treeview/table, and only one TAB away.

Point 5 I don't have, because as the user starts typing in the filter input field, the treeview/table is already being filtered concurrently. Pressing enter is just for when you want to repeat a search and not change the filter term. For example, when the words have changed concurrently due to other actions. There is no dialog to close, because this is all in the main window. I have been thinking about adding a dialog that displays a progress bar, or adding a progress bar in the bottom status bar of the application. There a stop button might be useful. But so far the searching/filtering finishes in milliseconds, so no one would have time to click that stop button.

Re: GUIs should be fully keyboard-driven

#395

Post by charcircuit »

spankibalt wrote: post #373
robomartin wrote: post #245

Earlier quoted context omitted.

> Democracy is about access No, not really. I know what you are trying to say, and I fully agree. We need to stop using "democracy" or "democratizing". Democracy, in it's purest form, is about mob rule --majority rule, if you want to say it in a softer/kinder way. "Democratizing" means giving a mob control of the thing, it does not mean making it accessible to all at all.

> Democracy, in it's purest form, is about mob rule --majority rule, if you want to say it in a softer/kinder way. You're just parroting an old urban myth. The terminus technicus for mob rule is ochlocracy [1]; democracy, per se , includes minority protections (i. e. if it doesn't then it isn't a democracy to begin with). 1. [ https://en.wikipedia.org/wiki/Mob_rule ]

>democracy, per se, includes minority protections (i. e. if it doesn't then it isn't a democracy to begin with).

Democracy has nothing to do with minority protections. I don't understand you can say it per se includes minority protections. Democracy includes whatever enough people think it should include. If people don't want such protections then there is no need for them.

If a democratic society does not want to live side by side violent murderers and thugs they can agree on ways to deal with that minority group like killing them or imprisoning them.

Re: GUIs should be fully keyboard-driven

#397

Post by opan »

djaro wrote: post #364
gregdeon wrote: post #326

Earlier quoted context omitted.

Yep. In accessibility research, they call these "situational disabilities". When you need to open a door with your arms full of groceries, you aren't so different from someone who is never able to open a door. Accommodations that help people with permanent disabilities also help other people in the right situations, too.

My touchpad broke and I couldnt download the touchpad driver to fix it on the spot because there was no way to get to the download button with tab and enter, you had to click it.

That's a funny example, reminds me of how often fresh Windows 7 or older installs were missing the ethernet driver so you had to move stuff over on a flash drive to get started really setting stuff up.

In your situation, a couple possible solutions come to mind. 1) turn on "mouse keys" which lets you use the numpad to move the mouse and click, 2) a vim addon for the browser (e.g. vimperator or tridactyl) likely could've clicked the button via the hints mode. It's in the past now so maybe these wouldn't have worked or you didn't know, of course, just fun to think of what I would've done.

Re: GUIs should be fully keyboard-driven

#398

Post by Cthulhu_ »

gramie wrote: post #177
rootedbox wrote: post #152

I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard. 1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a dis…

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.

Exactly; consider that only a percentage of users will actually be sitting at a desktop system using your application. Most people will visit your website on a mobile device, and a percentage of that will be in weird lighting conditions trying to operate the thing with just one hand. As just an example, and that's the people considered abled - anything that isn't the hip startup of the week aimed at 15-25 year olds will need to consider e.g. eyesight issues on top of everything else.

Anyway, it's not even an option anymore, under the European Accessibility Act, government and (since last year) public services (websites, apps, appliances, etc) all need to be accessible; for websites this means implementing WCAG 2.something to level AA, which includes things like minimum contrast requirements, captioned videos, and increasing font size without losing information.

And it's often considered an afterthought because by and large, designers and developers are relatively young, 20-40 some year olds working on Macbooks with 4K displays. Some may be wearing glasses but broadly speaking that's the extent of their disabilities.

Re: GUIs should be fully keyboard-driven

#399

Post by opan »

jameshart wrote: post #277
rootedbox wrote: post #152

I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard. 1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a dis…

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…

Besides the TUI program itself, you also have your terminal emulator (unless in a TTY) and possibly a multiplexer like tmux. I use irssi inside tmux from my phone a lot and you can get pretty precise control with keyboard shortcuts that make up for some of the flaws of a touchscreen. Like instead of mashing or holding the arrows to go back and fix a typo, I'll use the readline binds and hit esc and b a bunch of times to close most of the distance, then switch to arrows at the end if needed. The tmux copy mode is also pretty friendly in the same way, you can vary gradually adjust your selection start/end without having to hold anything down.

Re: GUIs should be fully keyboard-driven

#400

Post by Cthulhu_ »

rhdunn wrote: post #359
umpalumpaaa wrote: post #353

Earlier quoted context omitted.

Colors should be an OS feature. On iOS and macOS you can remap colors globally and it works in all native apps. There are presets fire the common cases: red/green issues, color blindness etc and you can make your own. This has its limitations though eg if you are not able to distinguish at least 5 or so colors… any colors.

That's why you don't just use colour for identification. E.g. include a warning icon next to a button/element in addition to using a warning colour.

Nor just shape, so a warning icon + text message.
Post reply on HN