Payload CMS is inaccessible for keyboard users when a lexical rich text editor is on the page

[rilrom]

Link to reproduction

No response

Environment Info

Payload: 3.0.0-beta.113 Next.js: 15.0.0-canary.173

Describe the Bug

It is not possible to properly navigate Payload CMS when a page contains a lexical text editor.

Once focus is applied in a text editor, the tab key is used for indents.

The only way to leave the text editor is to use the escape key, which removes all focus and sends the keyboard user back to the beginning of the page.

Worst case is there are at least two lexical text editors on the page, any fields placed between them are completely inaccessible to keyboard users (since once you reach one on either side you cannot continue).

The plugin itself recommends that it probably shouldn't be used for accessibility reasons.

I recommend removing IndentFeature from the default feature list and making it opt-in.

Reproduction Steps

1. Access any lexical rich text editor using a keyboard.
2. Attempt to continue to the next field using the tab key to navigate, but instead you will be adding indents to the rich text.
3. Press the escape key to leave the rich text editor.
4. Focus will be placed back at the beginning of the page.

Adapters and Plugins

richtext-lexical

[GermanJablo]

Thanks for thinking about this. Improving accessibility is really important to us! ❤️

I'd like to point out this comment, and this other one. Some conclusions that can be drawn from there about disabling "indent with tab":

• It should be opt-out
• It should be possible to disable and enable it with the keyboard while using the app (rather than leaving it always on or always off for all users in the code).

Supposedly the common practices are ctrl-m or esc. I don't know where ctrl-m came from, but in view of the lack of definition by the W3C I'm going to advocate for esc.

So the flow I suggest is that every time the users press esc they toggle the on/off state of "indent with tab".

To avoid accidental toggles, I suggest displaying toasts with the messages:

You have disabled the option to indent with the tab key. To enable it press escape again.

You have enabled the option to indent with the tab key. To disable it press escape again.

[rilrom]

Appreciate the response @GermanJablo.

You've got me thinking about how we can support keyboard users while still allowing the indent feature to be available by default.

What are your thoughts on if the escape key is pressed, the indent feature is disabled, allowing the tab key to be used for navigation, however if the next key pressed is not tab or shift+tab, it is automatically re-enabled. It will also be automatically enabled upon focusing the editor.

This would allow the best of both worlds, and prevent users from accidentally disabling it.

Ideally this should be fixed in lexical, and I'm happy to go in there and come up with a solution, but until then this could be a solid workaround (assuming it works, I haven't tested it yet).

Once again thanks for being open to taking accessibility into consideration.

[GermanJablo]

What are your thoughts on if the escape key is pressed, the indent feature is disabled, allowing the tab key to be used for navigation, however if the next key pressed is not tab or shift+tab, it is automatically re-enabled. It will also be automatically enabled upon focusing the editor.

Good point. I think a toast is enough of a visual aid for the user to understand what's going on. Also, this is local state, so at worst it would be restored on refresh or navigation. That's why I think holding the toggle until you press escape again is ok.

Ideally this should be fixed in lexical, and I'm happy to go in there and come up with a solution, but until then this could be a solid workaround (assuming it works, I haven't tested it yet).

That's true. Ideally, instead of a property to disable it, they could handle the escape event, and expose a callback like onToggleIndentWithTab: (newStatus: "open" | "closed") => void, so that users can decide what visual aid they want (a toast in our case).

Whether you decide to contribute there or here, I'd be happy to review it. Thanks again!

[rilrom]

Hi @GermanJablo, very much appreciate the feedback, I think we're on the path towards finding a solution that works for all users.

I've updated my PR to allow for the IndentFeature to still be enabled while also resolving any keyboard trapping issues in the editor. I think the changes I have put together are a good balance for now to unblock keyboard users while we explore a more permanent solution over in the lexical package.

I have put more information in the PR itself, please give it a test and let me know what you think.

Thanks!

[rilrom]

Upon further investigation, this looks to be a firefox specific bug. Chromium browsers work as you would expect when pressing the escape key.

With that in mind, I will explore why firefox is resetting the focus to the beginning of the page. The PR I've created does resolve the issue for firefox without affecting chromium based browsers but it still may no longer be appropriate.

[GermanJablo]

I left a review in the PR 😊👍

[github-actions[bot]]

This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.

[github-actions[bot]]

🚀 This is included in version v3.2.2