Open JAWS-test opened 4 years ago
I agree, it doesn't make sense to me to allow controls to hijack the toolbar's arrow key interaction. In the same way that the editable data grid uses Enter
/Escape
to surface the text input, it would make more sense to require toolbar controls that use the same arrow keys to be behind similar enter/escape or disclosure patterns.
Hi there!
As we have a really extensive Toolbar, there are scenarios in which it contains Textbox and Combobox controls that follow their own keyboard navigation patterns. As a result, they do not allow Left/Right arrow keys to be used by the Toolbar.
In my opinion, the statement "Avoid including controls whose operation requires the pair of arrow keys used for toolbar navigation." does not give much value. We do our best to "avoid" the use of such controls, but at the end of the day, we have to embed them in the Toolbar. They are not forbidden ("avoid" is different than "must not"), so their usage should be clarified.
What keyboard navigation pattern should we follow then? Do we wrap them, similarly to Grid cells with inputs in them as @smhigley suggested? Should be the Toolbar navigation pattern completely revised, so that it also covers the usage of those controls? Or the above sentence should be revised to "Controls whose operation requires the pair of arrow keys used for toolbar navigation are not allowed in the Toolbar."?
The APG toolbar chapter says
I suggest to remove the second and third sentence, because even at the end of the toolbar an input field causes that the other elements are not reached anymore, if the input field gets the focus or that within the input field cannot be navigated with the arrow keys