WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Fixing a focus trap in WYSIWYG input field


From: Swift, Daniel P.
Date: Sep 25, 2018 6:41AM


We've never had to deal with that before, but to me, 'escape' seems like a logical solution. We've had people tell us that escape was perfect for exiting accordions, menus, dialog boxes, etc. To me, I would think that would be one of the first things someone would try. Add in some minor directions to the user, and I think that would be a good solution.

The challenge at that point would be -- where do you place the focus.

Just my two cents!

Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of N Robichaud
Sent: Monday, September 24, 2018 9:25 PM
Subject: [WebAIM] Fixing a focus trap in WYSIWYG input field


I'm looking for advice or shared accounts of past experience.

I'm tackling a problem with a WYSIWYG input field that I'm sure someone has solved before. It's in a web app that allows users to have an email conversation via the app. Users can use tab to change focus and navigate the page until they focus on the input field, which allows tabbed indentation. Once the focus lands there, there is no way for users to move on and access the rest of the page using a keyboard.

I know some products approach this by making tab do different things based on where the blinking cursor is:
If the blinking cursor is in a bulleted list, pressing tab or shift+tab changes the indentation.
If the blinking cursor is in a table, pressing tab or shift+tab moves between cells.
If the blinking cursor is in plain paragraph text, then pressing tab or
shift+tab changes focus in the page.

Other products introduce a custom keyboard shortcut for changing indentation within the composer input field, and tab and shift+tab are only used to change focus.

Can anyone share some advice on this? If you have addressed this problem in the past, what did you do and how did it go?