E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: N Robichaud
Date: Mon, Sep 24 2018 7:25PM
Subject: Fixing a focus trap in WYSIWYG input field
No previous message | Next message →

Hello,

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?

Thanks,
Nicolette

From: Swift, Daniel P.
Date: Tue, Sep 25 2018 6:41AM
Subject: Re: Fixing a focus trap in WYSIWYG input field
← Previous message | Next message →

Nicolette:

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
610.738.0589

From: Mallory
Date: Tue, Sep 25 2018 6:42AM
Subject: Re: Fixing a focus trap in WYSIWYG input field
← Previous message | Next message →

I was just testing a client using an SQL query input. Your tab types tabs.

Turned out that was Monaco, an editor from Microsoft. Only by trawling the MS docs did I learn that Ctrl-M was the magic escape route (it allows your tab to tab out).

Someone at Elastic sent a cool way they did stuff. I rather like this way:
(Github page) https://github.com/elastic/kibana/pull/13339

cheers,
_mallory

On Tue, Sep 25, 2018, at 3:25 AM, N Robichaud wrote:
> Hello,
>
> 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?
>
> Thanks,
> Nicolette
> > > >

From: glen walker
Date: Tue, Sep 25 2018 11:19AM
Subject: Re: Fixing a focus trap in WYSIWYG input field
← Previous message | No next message

I prefer the ESC key approach, as Dan mentions, although in one of my
company's previous apps, we had shortcut keys to move you to another
element and then you could Tab from there. But that required some
knowledge about the app. A list of shortcut keys was on the help menu. We
also implemented our own landmarks dialog that all users could get to
without needing a screen reader, so that was another way to navigate out of
the tab trap.

Glen