Accessibility: user trap: cannot escape the editor with TAB (WCAG 2.0, Success Criterion 2.1.2)

[mikkorantalainen]

Describe the bug

Whenever etherpad lite is used within an iframe (or otherwise as part of larger page), the user using only keyboard access is trapped within the editor.

To Reproduce

Steps to reproduce the behavior:

1. Load any etherpad document, e.g. 'Wikimedia etherpad service example document' and do not touch mouse.
2. Use Tab to move focus into the editor (unless the focus is already in the editor)
3. Use Tab, Shift+tab or Arrow Keys to get out of the editor as explained in WCAG 2.0, Success Criterion 2.1.2

Expected behavior

The user should be able to get out of the editor area or have clear instructions about how to do it.

WCAG 2.0, Success Criterion 2.1.2: No Keyboard Trap: 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.

Server (please complete the following information):

• Etherpad version: unknown, whatever etherpad.wikimedia.org is running.

• I could also reproduce the problem with older release 1.8.13 on Ubuntu 20.04.6 LTS so I would assume this happens with all versions:

• OS: Ubuntu 20.04.6 LTS on x86-64 compatible Intel CPU.

• Node.js version (node --version): 14.18.2

• npm version (npm --version): 6.14.15

• Is the server free of plugins: yes

Desktop (please complete the following information):

• OS: Ubuntu 22.04.4 LTS
• Browser: Google Chrome
• Version: 127.0.6533.99 (Official Build) (64-bit)

Smartphone (please complete the following information):

Didn't test because I don't know how accessibility is supposed to work with smartphone.

Additional context

WCAG 2.0, Success Criterion 2.1.2 describes accessbility level A requirement which is mandatory to implement if the software is used within EU area if I've understood correctly.

Note that the user should be able to exit from the editor at the start and at the end to allow all editors to be used if a single long page contains multiple etherpad instances (e.g. two iframes with one iframe per service running etherpad). If e.g. only Shift+Tab is supported to back out from the editor at the start of the editor, keyboard-only user can never access the second etherpad document on a long page.

[SamTV12345]

Describe the bug

Whenever etherpad lite is used within an iframe (or otherwise as part of larger page), the user using only keyboard access is trapped within the editor.

To Reproduce

Steps to reproduce the behavior:

1. Load any etherpad document, e.g. 'Wikimedia etherpad service example document' and do not touch mouse.
2. Use Tab to move focus into the editor (unless the focus is already in the editor)
3. Use Tab, Shift+tab or Arrow Keys to get out of the editor as explained in WCAG 2.0, Success Criterion 2.1.2

Expected behavior

The user should be able to get out of the editor area or have clear instructions about how to do it.

WCAG 2.0, Success Criterion 2.1.2: No Keyboard Trap: 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.

Server (please complete the following information):

• Etherpad version: unknown, whatever etherpad.wikimedia.org is running.
• I could also reproduce the problem with older release 1.8.13 on Ubuntu 20.04.6 LTS so I would assume this happens with all versions:
• OS: Ubuntu 20.04.6 LTS on x86-64 compatible Intel CPU.
• Node.js version (node --version): 14.18.2
• npm version (npm --version): 6.14.15
• Is the server free of plugins: yes

Desktop (please complete the following information):

• OS: Ubuntu 22.04.4 LTS
• Browser: Google Chrome
• Version: 127.0.6533.99 (Official Build) (64-bit)

Smartphone (please complete the following information):

Didn't test because I don't know how accessibility is supposed to work with smartphone.

Additional context

WCAG 2.0, Success Criterion 2.1.2 describes accessbility level A requirement which is mandatory to implement if the software is used within EU area if I've understood correctly.

Note that the user should be able to exit from the editor at the start and at the end to allow all editors to be used if a single long page contains multiple etherpad instances (e.g. two iframes with one iframe per service running etherpad). If e.g. only Shift+Tab is supported to back out from the editor at the start of the editor, keyboard-only user can never access the second etherpad document on a long page.

Hi thanks for the report. Accessibility is indeed important. Do you have a suggestion for a good key binding for unfocusing the editor? Tab is for making a tab in the editor and shift + tab is for undoing the existing tab.

[mikkorantalainen]

I think keyboard Arrow up from the first line would be the least problematic way to escape backwards from the editor. And keyboard Arrow down from the last line to escape forward from the editor would be the least intrusive solution.

Using tab to navigate between editors (one tab always escapes the editor) would be the optimal solution but I understand that it would clash with the existing feature where tab is already used.

If you're willing to change the keybinding of Tab key, then using tab to enter and exit the editor (similar to native textarea) would be optimal and e.g. Alt+Arrow key right could be mapped to the indentation that is currently bind to Tab and Alt+Arrow key left could be mapped to unindent which now has Shift+Tab.

Note that Alt+Arrow key left is typically bind to browser's Back action by default so if you use that for unindent, it can still cause some issues but I think it would be better than trapping the user when you capture the Tab.

[sharpchris]

I was looking into Etherpad as a tool in an academic setting, but this keyboard trap is a dealbreaker. There are new US regulations requiring all websites and services offered by state and local government institutions meet WCAG 2.1, level AA, by as early as April 2026.

[sharpchris]

Another suggestion for unfocusing the editor could be the Esc key. Whatever method is chosen, it would be important to have a explanation for how to move the focus: https://www.w3.org/WAI/WCAG21/Understanding/no-keyboard-trap.html

Success Criterion (SC)
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.