Comment by ckardaris
13 hours ago
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.
So in none of the cases they do - it shouldn't depend on any tags, that's the whole point of bypassing the app devs!
(not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components)
What complicated designs do you have in mind?
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
And more pressure from more options doesn't follow, you only need to study if you actually want to diverge