(A11y severity 1) Allow keyboard "escape" from collaborative documents

[sathomas]

Once a keyboard user enters the text entry frame and begins typing, the user then becomes trapped within the text field with no way to get out. Provide a method for users to leave the frame.

[nicolaasmatthijs]

This is going to be tricky, as a tab inside of the collaborative document designates an edit action instead of a navigational action. @sathomas : Do we know what an appropriate approach for this would be?

[sathomas]

Not offhand, but I've got a couple of books on accessibility for web components that may provide more guidance.

[sathomas]

According to WCAG 2.0 it is acceptable (though not ideal) to use a key other than Tab to navigate within a page, as long as the user is informed:

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. (Level A)

This might provide a glimmer of hope. More specifically, it might be feasible to allow the Esc key to shift focus to the editpad toolbar. From there, normal keyboard navigation should be okay.

[nicolaasmatthijs]

Okay, that would make sense. Are there any examples of how applications containing CKEditor or TinyMCE have fixed this problem?

[sathomas]

Both CKEditor and TinyMCE use a special key (Alt-F10) to switch to the toolbar from the edit window. FWIW both editors are much more accessible than etherpad.

• CKEditor: The best on Accessibility
• TinyMCE - Accessibility

There are many aspects of the accessibility support in both editors that provide good models for how etherpad could be enhanced.

[nicolaasmatthijs]

It sounds like taking the Alt-F10 approach would probably be the best thing to do, so it's at least consistent with other editors. We might want to consider sending this back to Etherpad as an a11y PR.

[sathomas]

I've been looking through the Etherpad code and I don't think there's any way to do this with a plugin, so we'd have to submit any enhancement as a PR. (I'm assuming we don't want to maintain our own Etherpad fork ;^) And as long as we're tweaking the Etherpad codebase itself, we could integrate the other accessibility improvements into the PR instead of relying on a plugin.

There's already an Etherpad issue (https://github.com/ether/etherpad-lite/issues/1803) for improving accessibility. I might comment more extensively on that issue to see if there's any interest in accepting a PR, as well as to see if there are any other folks that might help. The Etherpad key handling is very low-level, so being able to call on folks with more Etherpad expertise would definitely be a big bonus.

[nicolaasmatthijs]

@sathomas: +1 for checking interest on the Etherpad side and trying to bring the improvements directly into Etherpad

[JohnMcLear]

@sathomas are you still working on this?

[sathomas]

@JohnMcLear not in the very short term (next week or so), but possibly after that.

[JohnMcLear]

@sathomas okies I'm due to start working on this possibly this week so if you can free some time up over the next few days we can work together to get it done quickly?

[JohnMcLear]

Even just creating my a checklist of stuff to do would help, my notes are here: http://john.primarypad.com/ogf-24-03-15

[sathomas]

Closing this since the latest release of etherpad, combined with https://github.com/oaeproject/ep_oae/pull/13, addresses the issue