[Feature]: Ensure Consistent Shortcut Behaviors (e.g. Return, Tab, etc.), ideally using Native Accessibility Interactions

[garrettmflynn]

What would you like to see added to the NWB GUIDE?

Using Return to advance through a form was previously implemented. However, this behavior notably diverges from the native Tab accessibility feature in several ways, including:

1. Advancing past a select element
2. Will not focus FilesystemSelector element
3. Inconsistent behavior with a boolean selector (i.e. pressing Enter will select the currently focused button instead of advancing)
4. Stuck on list inputs because Enter submits values to the list
5. No ability to jump between accordions, even when open

Instead of maintaining an ad-hoc shortcut system on top of native accessibility features, it may be prudent to require users to leverage the native behaviors _except when adding instead of mirroring an interaction`.

For instance, the keywords input supports pressing Enter instead of the submit button to register a written keyword to the list. In the current implementation, this blocks the ad-hoc Enter advancement mechanism but is itself a useful behavior. This would be a good justification to keep this behavior while removing the mirrored Enter / Tab behavior.

Do you have any interest in helping implement the feature?

Yes.

Code of Conduct

Yes

Did you confirm this feature was not already reported?

Yes

[garrettmflynn]

Not sure where it comes from, but there's also a weird issue where you can tab backwards, but not forwards, through editable list items like the keywords list.

[CodyCBakerPhD]

Summarized and moved to #846

Re-open again whenever this starts active development