Accessibility: Keyboard Control Specification

[anthonyalfimov]

The top post will be updated with options and decisions for the keyboard control implementation.

---

General considerations

Keyboard control of a plugin needs to be independent from the mouse.

Keyboard control should comply with the following Web Content Accessibility Guidelines:

2.1 Keyboard Accessible 2.1 Reference

---

Keyboard control patterns

A. Full keyboard control

All features of the plugin can be controlled via keyboard without the mouse.

This requires:

1. Clear visual indication of the control that currently has the keyboard focus.
2. A way to change the focused control from the keyboard (e.g. using the Tab key).
3. Mouse interaction with a control switches the keyboard focus to it.
4. Knobs and sliders should allow to both nudge the value (e.g. with arrow keys) and directly type in the value (e.g. by pressing Return).

Additionally, Buttons / Toggles could have keyboard shortcuts.

---

This approach might require introducing a new UI element for all controls to indicate the keyboard focus. Alternatively, the highlighted "hover state" of the controls can be used as an indication of keyboard focus. However, the control highlight could be not prominent enough for this.

Examples:

(Waves) (Goodhertz)

---

In plugins offering full keyboard control, preset browsing is usually excluded from it. You can only use keyboard to navigate the preset list once you open it. Changing presets is a potentially destructive action, so there's some sense to not allowing to flip through presets using arrow keys.

However, I believe that if keyboard control is offered, it should be possible to access all plugin features without a mouse. So at the very least it should be possible to switch the keyboard focus to the preset browser and open the dropdown.

But if the keyboard focus is clearly indicated, there shouldn't be any problem with enabling the arrow keys to switch presets. It's better than allowing to individually focus "next preset" and "previous preset" buttons (if focus is cycled using Tab, you'd need to go full circle to get from "next preset" to "previous preset").

---

I've also encountered full keyboard control with no focus indication and no way to change focus from keyboard. This option will not be considered.

---

B. Partial keyboard control

Only certain controls like ComboBoxes and Lists allow using the keyboard. The point of keyboard control in this case is speeding up certain workflows. For example, auditioning presets or comparing different modes.

The keyboard focus is gained by a control that the mouse has last interacted with. In this case, it is possible to omit the visual indication for the keyboard focus. However, no keyboard focus indication can lead to confusion. Especially in the case of destructive actions like switching presets. This can be partially negated by introducing Undo functionality.

There is a number of open questions about the implementation of this approach.

---

Keyboard focus indication

Preferably, eligible controls should have visual indication of keyboard focus.

If no indication is used, a special care should be taken to avoid confusion and unwanted behaviour.

NB! Controls capable of destructive changes (e.g. preset browser) should not be eligible for keyboard focus, unless Undo functionality is available.

---

Keyboard focus switching

The common way of switching the keyboard focus in this pattern is via mouse interaction. This makes sense if no keyboard focus indication is used. However, this approach makes keyboard control dependent on the mouse. It is prone for confusion.

If visual indication is used, then the focus can also be cycled from the keyboard (e.g. using the Tab key).

---

Should there be a state when no controls have keyboard focus?

Only some controls are eligible for keyboard focus, so what happens when you interact with a non-eligible control? Should the previously focused control keep the focus, or lose it?

With no focus indication, it might be better to go to a state when no controls have keyboard focus.

---

Clearly, having no visual indication for keyboard focus always leads to some degree of confusion. One possible way around this is to simply "hardwire" the keyboard focus to a single control in the entire plugin. It might be viable for very simple plugins.

---

C. No keyboard control

A simple way to avoid confusion and unwanted destructive actions could be to not offer keyboard control at all. This is definitely better than poorly implemented partial/full control.

This is a very common solution.

---

Conclusion

I believe that a plugin should have either a really well implemented full keyboard control, or no keyboard control at all. So option B will not be considered.

Currently, the plugin will offer no keyboard control.

Full keyboard control will be implemented at a later date as a part of accessibility update (when JUCE 6.1 is released).

[anthonyalfimov]

Note: so far I haven't encountered a plugin that would allow flipping through presets using arrow keys on the keyboard. Since changing presets is a potentially destructive action, this makes sense.

[anthonyalfimov]

Idea: current control highlight (hover state) can be used as an indication of keyboard focus.

[anthonyalfimov]

The logical approach is to start with no keyboard control, and potentially add proper full keyboard control later.

[anthonyalfimov]

Full keyboard control of the UI should be implemented as a part of accessibility update when JUCE 6.1 is released (see JUCE Accessibility).

[anthonyalfimov]

JUCE 6.1.0 is released