But you can — or should be able to — independently toggle all of those features. For example, the app should work in high-contrast mode with disabled color coding, it should work with touch gestures disabled, etc.
A good common framework helps here. Then, it's up to each user to set their settings properly.
Riddle me this - why would you want to disable something that increases usability of an application? (Yes, this is a loaded question - I never said these features are bad, just that usability and accessibility are sometimes at odds with each other.)
unsure this is quite the same thing, but I often swap my phone to gray scale to reduce brightness overall (and 'reduce whitepoint' sometimes) because at night colors are too stimulating.
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.
In fact, for some people high contrast is headache-inducing.
I’ve installed a utility on my laptop that supports “sub-zero” display dimming for nighttime use because monitors are now over-optimized for max brightness, with min brightness being retina-searing for eyes adjusted to a dim room.
I am a little confused about your response. Do you disagree with me that accessibility features often reduce usability, or do you agree with me and just feel like nitpicking? I'm all for nitpicking, but I'd rather keep it separate from the real debate.
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.
That's a good point. Accessibility is the next step that should also not be ignored. Navigating to the elements is one thing, but for the voice assistant to work properly it can be a little trickier.
> What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?
If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with "<N>G", but such a shortcut would seem absurd in another application.
Any text-centric action will have a great advantage when done inside a terminal. I would think the equivalent in GUIs would be first-class OCR support on the compositor level. I am not informed about any progress made in that region to be honest, so I cannot tell how close we are (or not) to this.
You are right. Maybe the wording is a little too absolute. If you gotta ship and later try to slowly address any shortcomings in different areas, this is also a step in the right direction in my opinion. Just don't completely forget about those areas just because you have already shipped by that point.
For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.
In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.
In that case, it is up to the developer as well to read and try to follow the published guidelines.
Maybe not complicated, but unorthodox. A developer who is not familiar with the correct design patterns may, for example, create a dialog using a FrameworkWindow instead of a FrameworkDialog. In that case the framework can not provide any automation, because the developer is not following the guidelines.
I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.
> 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.
This is easy to omit and then you will never know about the automation.
Then, you can go into a different discussion. How does the framework guide you to the correct functionality? Does it force you to include a primary menu? Does it check that if you have at least one menu, then one should be primary? What if the developer creates an unorthodox menu by creating a simple button that opens a popup with a list of buttons?
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?
> ..., so a user can configure F10 to open it if you, app developer, forgot to mark it as main
So, basically what you want you want, as a user, is to bind arbitrary application actions to shortcuts and force click events in spite of what the developer has predicted or tested in their interface. I do not think this is a trivial problem to solve. The application would need to have a way to expose these actions consistently.
> What is he draws a circle instead of using a letter O? What of it?
Well, then you cannot expect the screen reader to work, for example, and you also cannot expect to do anything with this weird "shape". The developer has broken the standards and the user is helpless in this scenario.
These aren't arbitrary actions, but standard menu actions (open menu, close it, activate an item). Also not sure how forcing clicks entered the scene. These are possible via keyboards in many frameworks already today.
> in spite of what the developer has predicted
The dev has "predicted" the menu by creating it in the first place? The framework just made sure that this menu is addressable by the user
> tested in their interface.
That's not a big loss, it's not like we've come to expect any serious testing of UIs anyway
> The developer has broken the standards
Yes, so? I don't understand the point relevant to this discussion. Should standards not exist if they can be broken? Should frameworks not try to make following standards easier?
Should frameworks not allow user customizations if devs can find a way to break them?
This can happen if the applications exposes single keys as shortcuts. If they are "hidden" behind the different modifiers (i.e. Ctrl, Cmd, Alt), then mis-clicks should not be possible or should be more tolerated.
The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.
I agree. I mention this briefly in one of the footnotes. There are some tasks that greatly benefit from the mouse (e.g photo editing tasks where arbitrary region point and click is required).
This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.
A good common framework helps here. Then, it's up to each user to set their settings properly.