How should Joplin handle Tab-key navigation? (Keyboard accessibility)

Features
,
1

We're working on making Joplin more accessible. Part of this involves improving keyboard navigation. Currently, the way Joplin handles Tab has accessibility issues.

This post's goal is to collect feedback and suggestions: How should Joplin support keyboard navigation in an accessible way?

The issue

Currently, some functionality is difficult or impossible to access when navigating with tab and shift-tab.

1. Changing focus from the title to the body with tab

Currently, pressing Tab from the title input moves the cursor to the note body:

Diagram: Pressing Tab from the title input jumps to the editor body
Diagram: Pressing Tab from the title input jumps to the editor body2324×805 211 KB

This skips the focusable items in the note toolbar and can make it difficult to use certain features with only a keyboard.

Related WCAG guidelines

The WCAG:

  1. Requires that "components receive focus in an order that preserves meaning and operability", and
  2. Requires that "All functionality of the content is operable through a keyboard interface [...]".

2. Moving focus out of the editor requires pressing Esc before Tab/Shift-Tab

At present, Tab indents in the Rich Text and Markdown editors and Shift-Tab de-indents. This turns these editors into focus traps.

It's currently possible to leave the focus trap by pressing Escape before Tab/Shift-Tab (or using one of the "jump focus to" shortcuts). However, this isn't well documented.

Note: The behavior described above is different in Joplin <= 3.0.
Note: This issue on the W3C ARIA-practices GitHub repo suggests using ctrl-m as a "toggle tab mode" keyboard shortcut.

Related WCAG guidelines

Proposed changes

1. Use different keyboard shortcuts to navigate between the editor and the title

Update: This suggestion has been included in Joplin v3.1.4.

Rather than remapping tab, it could make sense to use enter and the arrow keys to navigate between the title and the body.

In particular:

  1. Pressing Enter when the title input is focused focuses the editor.
  2. Pressing Down when the cursor is at the end of the title input navigates to the first line of the editor:
  3. Pressing Up when the cursor is at the beginning of the editor navigates to the title.

This would allow the Tab to follow the default focus order:

This would fix the first issue raised above, but would not fix the second.

See also: A possible implementation.

2. Include a "tab navigation" toggle button

This solution involves adding a ctrl-m "toggle tab indentation" shortcut and providing a toggle button to document this shortcut. (ctrl-m seems to be the standard shortcut for this).

For example,

screenshot: Tab indentation button in the toolbar is focused. The button has content "Tab indentation (Ctrl-M)"
screenshot: Tab indentation button in the toolbar is focused. The button has content "Tab indentation (Ctrl-M)"691×160 18.3 KB

This button would only be visible when it has focus. However, if the user is navigating with Tab, this button would be visible before the editor receives focus.

By providing instructions on how to escape the focus trap, this button should satisfy this section of the WCAG 2.2:

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

— WCAG §2.1.2, emphasis added.

Feedback?

  • This post proposes replacing a Tab key mapping with other shortcuts (arrow keys, enter). Should these shortcuts be adjusted?
  • What should be done to show users how to escape the note editor focus trap? Is the "tab indentation" button suggested above sufficient?
4 Likes
2

I agree Joplin is not well prepared for keyboard navigation. Often the order of elements selection is not expected for me..

Regarding the mentioned points:

  1. moving from the title to the body is the most frequent and most "native" move IMHO. I agree is sounds contra-intuitive to skip the buttons between title and body but this buttons mostly have no meaning for the documents itself and only relate to text editing - there is no advantage to put focus on it after leaving the title. Enter or Down are good alternatives in my eyes.
  2. un-/intendation with Tab is frequently used and would appreciate this remains as is. Some smart way to break out of the focus trap is required but I don't think suggested ctrl+M command is a good way to go.
  • as Tab is very frequently used to navigation I would prefer including Tab
  • Esc followed by Tab is maybe the most fluid way.. as it utilizes "intuitive" functionality of Tab for navigation while Esc pressed before allows the "Escape" of the focus trap.

I have another very annoying habit to add:

  • in markdown editor Ctrl+l switches from text to rendered mode (Toggle editor layout)
  • starting with markdown representation pressing Ctrl+l twice to check how the rendered version looks like and returning back to the edit mode there is no cursor so it's impossible to continue editing right away. it requires another mouse click or Ctrl+b key combo to bring the cursor back. would be great if the cursor appears immediately after switching to editor mode
2 Likes