ckardaris

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.

Sometimes users may prefer to reduce the degree of accessibility of an application in favor of aesthetics.

> ..., 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.

> 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.

  <object class="GtkMenuButton">
    <property name="primary">true</property>

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?

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.

This is where using a common framework pays dividends. For example, on the desktop I can disable animations for all GTK applications.

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.

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.

In some cases they do.

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.

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.