3 ms·

Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny th

Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny thing is that the former usually falls out of the latter. Part of the blame lands on the shoulders of popular UI frameworks (or in the case of those choosing to eschew use of such, the developers who made that choice). The older frameworks tend to make this fairly easy; for example, in Cocoa/AppKit (Mac native UI framework), one can pretty easily wire up their entire UI for proper keyboard navigation entirely visually (mostly just consists of connecting nextKeyView outlet between controls to produce a logical chain to tab-focus through). Defining key shortcuts is also simple; add a menu item for a command and set its corresponding shortcut (which in turn allows the user to rebind the shortcut in System Settings at will). That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.

pathartl 2mo ago
Funny that you bring macOS, because for _decades_ I've struggled with navigating it without a keyboard. Windows components however, especially old ones, are incredibly accessible
- cosmic_cheese 2mo ago
  As a system macOS definitely has some holes in keyboard navigation, as well as a couple corners which are KB-navigable but the way to focus them is not immediately obvious. On the app level, keyboard navigability depends on the developer. If they take the time to dot their I's and cross their T's it's between decent and great, but if they don't care it'll be bad.
  - dpark 2mo ago
    MacOS has intentional holes in keyboard support. You have to go into settings and turn on a config for keyboard navigation to reach all elements. Apple intends for most users to navigate with a mouse. It’s in the accessibility settings. https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/mac https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
    - burnte 2mo ago
      I cannot think of a single reason these would be disabled by default other than Apple stubbornness.
      - ChickeNES 2mo ago
        This is the company that popularized the mouse and GUIs, why are you shocked?
        burnte 2mo ago
        Because it's stupid. Why would accessibility features enabled by default on Windows and Linux be disabled by default in MacOS? There is literally zero advantage to disabling it, and it makes life harder on users. Same thing with tap to click. Once everyone else enabled tap to click Apple disabled it. They just HAVE to be different, even if it's bad for users, and that stubbornness is frustrating.
        dpark 2mo ago
        If you expect your users to mostly work with both mouse and keyboard, it can make sense. Dropping stuff from the tabbing order means that the stuff left is is quicker to tab through. I find it mostly annoying. Tap to click, though, that’s infuriating. I don’t know how people can stand it. I know people who insist they like it and then I see them accidentally “click” regularly and get annoyed by it.
        burnte 2mo ago
        No, keeping it disabled makes zero sense. There's no reason now to force people to enable it. Most people don't even know you can do it in windows so it's not like there's a huge problem for them. No reason not to leave it on here.
        danaris 2mo ago
        To a large extent, I believe it's a holdover from the earliest days of the Mac, when the mouse was brand-new, and many developers had to essentially be forced to even support it, let alone treat it as a first-class interface device. I agree that it would be nice if Apple would have more keyboard navigation available by default now than they did then, but given that it is readily available for those who want it, I don't really see it as a huge issue.
  - cyberax 2mo ago
    "Some holes"? That's an understatement. There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".
    - cosmic_cheese 2mo ago
      > There's no option to bring up a context menu with the keyboard. That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.
      - Muskwalker 2mo ago
        > Since at least macOS 15 the context menu key on typical keyboards is recognized and functions Apple's adding it to its own keyboards as well, at least on the third-generation Magic Keyboard with number pad (between F13 and forward delete).
    - kccqzy 2mo ago
      The philosophy was that anything visible in a context menu should also be in the app-wide menu bar. Instead of bring up a context menu and click Copy, you would find the Copy menu item in the menu bar. Therefore such menu items can be assigned any keyboard shortcut by the user. I quote from Apple https://developer.apple.com/design/human-interface-guidelines/context-menus https://developer.apple.com/design/human-interface-guideline...: > Always make context menu items available in the main interface, too. […] In macOS, an app’s menu bar menus list all the app’s commands, including those in various context menus. Therefore one can rightly conclude that there is no need for a key to bring up a context menu.
      - Tallain 2mo ago
        In this case it's not a context menu, it's just a menu. User experience is degraded, see GP's case. There is an expectation and a common paradigm which is intentionally ignored because the OS developers thought they knew better than the users. This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.
- AceJohnny2 2mo ago
  To reinforce your point, by default on macOS you can't use Tab to select different options in a dialog box. You have to enable that in System Settings -> Keyboard -> "Keyboard navigation" which is off by default.
- failbuffer 2mo ago
  My theory is that Mac was born with a mouse while Windows (and Windows apps) originally had to function on machines that might not have one. Thus, keyboard navigablity was prioritized, and that design sensibility stuck around longer.
  - marshray 2mo ago
    I think it probably has more to do with Mac's lack of adoption by the US Government and large corporations. Microsoft took accessibility of Windows and apps as a basic requirement. The fact that Windows is the daily driver desktop for the staff of the regulatory agencies that would bring complaints would not have gone unnoticed. But really, why wouldn't you? You almost get it for free if you use the standard widgets, and smooth keyboard navigation is far faster for experienced users than having to repeatedly move one's hand between keyboard and mouse.
  - nashashmi 2mo ago
    You would be baffled to know that after the creation of the mouse, Steve Jobs wanted to remove the arrow keys so developers would be forced to create mouse only interfaces.
    - quantified 2mo ago
      Not baffling at all. Wasn't he against the two-button mouse?
- nashashmi 2mo ago
  > Windows components however, especially old ones, are incredibly accessible Bing, Bing, Bing! I came here to vent how the new windows 10 and windows 11 interfaces (made by Mac enthusiasts, ughh) have omitted keyboard accessibility for a cleaner look. They also dropped drag and drop support (which I never knew about in windows 7) and I completely missed how useful it could be on Windows 10/11.
  - cosmic_cheese 2mo ago
    For whatever it's worth, the new W10/11 designs aren't in line with traditional Mac design philosophies either. They're more in line with those of iOS and Android with how they tend to bury and omit options entirely and prefer massive whitespace.
    - nashashmi 2mo ago
      Somehow that is a bigger insult: reducing a desktop to act like an iPhone.
  - pathartl 2mo ago
    Tons of built in winui3 stuff is still very accessible by the keyboard, metro era though what pretty rough.
    - nashashmi 2mo ago
      Yes the search feature plus using tabs and spaces bring about accessibility. Frequently it misses the underline letter , alt keyboard shortcut.
orbital-decay 2mo ago
>That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut. Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.
- ethin 2mo ago
  I know of at least 5 different UI frameworks in different languages which are partially accessible or completely inaccessible. Some include Dlangui, Tkinter (although this is getting better), DearImGui... Really any UI that decides to draw it's widgets by frame. QT also has some accessibility problems. In apps made with any of these, they are either impossible to use with assistive technology (and therefore the keyboard) or they are very difficult to use.
  - gmueckl 2mo ago
    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.
    - ethin 2mo ago
      > 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, which is a problem. Even if it weren't, it's inaccessibility is a problem. > Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them. Sometimes. Depends on the widget. I've had QLineEdit's crash apps when all-select-copy workflows have been used, or with NVDA on win32 you can't ordinarily read a multi-line QT QLineEdit or other multi-line input since the focus will remain on the first line, always. Webviews are entirely inaccessible at the moment.
RobotToaster 2mo ago
Are there any modern cross-platform GUI frameworks that do this well?
- layer8 2mo ago
  Unfortunately, the intersection between “modern” and “do this well” is pretty much the empty set.
trentor 2mo ago
It's not even in consideration anymore since the plaque of electron swept over desktop apps.
AnonC 2mo ago
> That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut. This is even more visible when using Apple’s own apps on macOS. Choose any of them that have been ported from iOS without any attention to detail or any QA for accessibility, like Reminders or Settings or Notes or another app. The tab key will not take you where you might expect. There is no way to navigate only using common keyboard shortcuts. Nobody working on all these Apple apps have heard of tab order or keyboard based navigation.
SilasX 2mo ago
This has been a source of tremendous frustration for me. I was really happy to discover c. 2009 that you could get browser extensions that let you do anything on a website (like clicking links) from the keyboard. But increasingly, they're failing at making items detectable as clickable. Which is like, why? How do you go through the effort to make a framework to automate the process of putting in UI elements ... and somehow fail to comply with basic standards that would allow interoperability. I suspect that a lot of the resistance to disability compliance in websites[1] is due to how it would let you bypass ads. If a screen reader can cut through the cruft to get to what you need, then everyone can use software that does it. [1] like in the Domino's case https://news.ycombinator.com/item?id=21188092 https://news.ycombinator.com/item?id=21188092

pathartl 2mo ago

Funny that you bring macOS, because for _decades_ I've struggled with navigating it without a keyboard. Windows components however, especially old ones, are incredibly accessible

cosmic_cheese 2mo ago
As a system macOS definitely has some holes in keyboard navigation, as well as a couple corners which are KB-navigable but the way to focus them is not immediately obvious. On the app level, keyboard navigability depends on the developer. If they take the time to dot their I's and cross their T's it's between decent and great, but if they don't care it'll be bad.
- dpark 2mo ago
  MacOS has intentional holes in keyboard support. You have to go into settings and turn on a config for keyboard navigation to reach all elements. Apple intends for most users to navigate with a mouse. It’s in the accessibility settings. https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/mac https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
  - burnte 2mo ago
    I cannot think of a single reason these would be disabled by default other than Apple stubbornness.
    - ChickeNES 2mo ago
      This is the company that popularized the mouse and GUIs, why are you shocked?
      - burnte 2mo ago
        Because it's stupid. Why would accessibility features enabled by default on Windows and Linux be disabled by default in MacOS? There is literally zero advantage to disabling it, and it makes life harder on users. Same thing with tap to click. Once everyone else enabled tap to click Apple disabled it. They just HAVE to be different, even if it's bad for users, and that stubbornness is frustrating.
        dpark 2mo ago
        If you expect your users to mostly work with both mouse and keyboard, it can make sense. Dropping stuff from the tabbing order means that the stuff left is is quicker to tab through. I find it mostly annoying. Tap to click, though, that’s infuriating. I don’t know how people can stand it. I know people who insist they like it and then I see them accidentally “click” regularly and get annoyed by it.
        burnte 2mo ago
        No, keeping it disabled makes zero sense. There's no reason now to force people to enable it. Most people don't even know you can do it in windows so it's not like there's a huge problem for them. No reason not to leave it on here.
        danaris 2mo ago
        To a large extent, I believe it's a holdover from the earliest days of the Mac, when the mouse was brand-new, and many developers had to essentially be forced to even support it, let alone treat it as a first-class interface device. I agree that it would be nice if Apple would have more keyboard navigation available by default now than they did then, but given that it is readily available for those who want it, I don't really see it as a huge issue.
- cyberax 2mo ago
  "Some holes"? That's an understatement. There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".
  - cosmic_cheese 2mo ago
    > There's no option to bring up a context menu with the keyboard. That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.
    - Muskwalker 2mo ago
      > Since at least macOS 15 the context menu key on typical keyboards is recognized and functions Apple's adding it to its own keyboards as well, at least on the third-generation Magic Keyboard with number pad (between F13 and forward delete).
  - kccqzy 2mo ago
    The philosophy was that anything visible in a context menu should also be in the app-wide menu bar. Instead of bring up a context menu and click Copy, you would find the Copy menu item in the menu bar. Therefore such menu items can be assigned any keyboard shortcut by the user. I quote from Apple https://developer.apple.com/design/human-interface-guidelines/context-menus https://developer.apple.com/design/human-interface-guideline...: > Always make context menu items available in the main interface, too. […] In macOS, an app’s menu bar menus list all the app’s commands, including those in various context menus. Therefore one can rightly conclude that there is no need for a key to bring up a context menu.
    - Tallain 2mo ago
      In this case it's not a context menu, it's just a menu. User experience is degraded, see GP's case. There is an expectation and a common paradigm which is intentionally ignored because the OS developers thought they knew better than the users. This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.
AceJohnny2 2mo ago
To reinforce your point, by default on macOS you can't use Tab to select different options in a dialog box. You have to enable that in System Settings -> Keyboard -> "Keyboard navigation" which is off by default.
failbuffer 2mo ago
My theory is that Mac was born with a mouse while Windows (and Windows apps) originally had to function on machines that might not have one. Thus, keyboard navigablity was prioritized, and that design sensibility stuck around longer.
- marshray 2mo ago
  I think it probably has more to do with Mac's lack of adoption by the US Government and large corporations. Microsoft took accessibility of Windows and apps as a basic requirement. The fact that Windows is the daily driver desktop for the staff of the regulatory agencies that would bring complaints would not have gone unnoticed. But really, why wouldn't you? You almost get it for free if you use the standard widgets, and smooth keyboard navigation is far faster for experienced users than having to repeatedly move one's hand between keyboard and mouse.
- nashashmi 2mo ago
  You would be baffled to know that after the creation of the mouse, Steve Jobs wanted to remove the arrow keys so developers would be forced to create mouse only interfaces.
  - quantified 2mo ago
    Not baffling at all. Wasn't he against the two-button mouse?
nashashmi 2mo ago
> Windows components however, especially old ones, are incredibly accessible Bing, Bing, Bing! I came here to vent how the new windows 10 and windows 11 interfaces (made by Mac enthusiasts, ughh) have omitted keyboard accessibility for a cleaner look. They also dropped drag and drop support (which I never knew about in windows 7) and I completely missed how useful it could be on Windows 10/11.
- cosmic_cheese 2mo ago
  For whatever it's worth, the new W10/11 designs aren't in line with traditional Mac design philosophies either. They're more in line with those of iOS and Android with how they tend to bury and omit options entirely and prefer massive whitespace.
  - nashashmi 2mo ago
    Somehow that is a bigger insult: reducing a desktop to act like an iPhone.
- pathartl 2mo ago
  Tons of built in winui3 stuff is still very accessible by the keyboard, metro era though what pretty rough.
  - nashashmi 2mo ago
    Yes the search feature plus using tabs and spaces bring about accessibility. Frequently it misses the underline letter , alt keyboard shortcut.

orbital-decay 2mo ago

>That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut. Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.

ethin 2mo ago
I know of at least 5 different UI frameworks in different languages which are partially accessible or completely inaccessible. Some include Dlangui, Tkinter (although this is getting better), DearImGui... Really any UI that decides to draw it's widgets by frame. QT also has some accessibility problems. In apps made with any of these, they are either impossible to use with assistive technology (and therefore the keyboard) or they are very difficult to use.
- gmueckl 2mo ago
  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.
  - ethin 2mo ago
    > 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, which is a problem. Even if it weren't, it's inaccessibility is a problem. > Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them. Sometimes. Depends on the widget. I've had QLineEdit's crash apps when all-select-copy workflows have been used, or with NVDA on win32 you can't ordinarily read a multi-line QT QLineEdit or other multi-line input since the focus will remain on the first line, always. Webviews are entirely inaccessible at the moment.

RobotToaster 2mo ago

Are there any modern cross-platform GUI frameworks that do this well?

layer8 2mo ago
Unfortunately, the intersection between “modern” and “do this well” is pretty much the empty set.

trentor 2mo ago

It's not even in consideration anymore since the plaque of electron swept over desktop apps.

AnonC 2mo ago

> That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut. This is even more visible when using Apple’s own apps on macOS. Choose any of them that have been ported from iOS without any attention to detail or any QA for accessibility, like Reminders or Settings or Notes or another app. The tab key will not take you where you might expect. There is no way to navigate only using common keyboard shortcuts. Nobody working on all these Apple apps have heard of tab order or keyboard based navigation.

SilasX 2mo ago

This has been a source of tremendous frustration for me. I was really happy to discover c. 2009 that you could get browser extensions that let you do anything on a website (like clicking links) from the keyboard. But increasingly, they're failing at making items detectable as clickable. Which is like, why? How do you go through the effort to make a framework to automate the process of putting in UI elements ... and somehow fail to comply with basic standards that would allow interoperability. I suspect that a lot of the resistance to disability compliance in websites[1] is due to how it would let you bypass ads. If a screen reader can cut through the cruft to get to what you need, then everyone can use software that does it. [1] like in the Domino's case https://news.ycombinator.com/item?id=21188092 https://news.ycombinator.com/item?id=21188092