E-mail List Archives

Search E-mail List Archives for

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

From: Sumit Patel
Date: Wed, Mar 26 2025 1:18AM
Subject: Query Regarding Keyboard Trap Issue in Search Page
No previous message | Next message →

Hi all,
I hope you’re doing well. I have a query regarding a keyboard trap issue in
one of our webpages.
The page in question is a search page. After performing a search, results
are displayed below the search field. In between the search field and the
results, there are four tabs that can be used to filter the search results.
For example, selecting the first tab shows all results, while selecting any
other tab will display only related results.
However, I’ve encountered an issue when navigating through the page using
the keyboard. Upon tabbing into the tab group, the focus gets trapped
within this group. This means that, using the Tab or Shift + Tab keys, I
can only navigate through the four tabs and cannot move beyond them. Each
tab receives separate tab focus, and arrow keys cannot be used to navigate
through the group.
We’ve reported this issue as a failure under WCAG SC 2.1.2 (Keyboard Trap).
The development team has indicated that this behavior is part of the
intended functionality and cannot be changed. As a workaround, they have
implemented the Escape key feature: when pressing the Escape key while in
the tab group, users can exit the trap and resume normal navigation using
Tab or Shift + Tab to move to the next or previous interactive element.
While this approach allows users to continue navigating via the keyboard,
I’m concerned about how a keyboard-only user would know to press the Escape
key to escape the trap. It’s not immediately clear that this is the
solution.
Given this, I would like to know if we can proceed with accepting this
workaround, or if there are alternative suggestions we should consider to
ensure compliance with WCAG 2.1.2.
Looking forward to hearing your thoughts on this.

Regards,
Sumit.

From: Birkir R. Gunnarsson
Date: Wed, Mar 26 2025 1:41AM
Subject: Re: Query Regarding Keyboard Trap Issue in Search Page
← Previous message | Next message →

This is borderline acceptable if they display keyboard interaction
instructions regarding the escape key.
(this is not expected keyboard operation so they must include instructions
for keyboard user)

This is a very poor keyboard user experience, even with instructions.
* The tabs are not modal (I take it) so no reason they should trap keyboard
focus
* This is not expected keyboard interaction for tabs (see the tabs pattern
in the ARIA Authoring Practices)

With no tab selected, all tabs are in focus order. To select the focused
tab, press enter or spacebar.
With one tab selected, only that tab is in focus order.
To navigate to other tabs from the selected tab use arrow keys.
Navigating to a tab may automatically activate it, if not press enter.
From the selected tab, the tab key navigates to the first tabbable
element in the tabpanel.
(say that 5 times as fast as you can)

I could see filters being implemented more like toggle buttons than tabs
(less work, you can select multiple filters) but none of that warrants
trapping keyboard focus.


On Wed, Mar 26, 2025 at 3:18 AM Sumit Patel via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi all,
> I hope you’re doing well. I have a query regarding a keyboard trap issue in
> one of our webpages.
> The page in question is a search page. After performing a search, results
> are displayed below the search field. In between the search field and the
> results, there are four tabs that can be used to filter the search results.
> For example, selecting the first tab shows all results, while selecting any
> other tab will display only related results.
> However, I’ve encountered an issue when navigating through the page using
> the keyboard. Upon tabbing into the tab group, the focus gets trapped
> within this group. This means that, using the Tab or Shift + Tab keys, I
> can only navigate through the four tabs and cannot move beyond them. Each
> tab receives separate tab focus, and arrow keys cannot be used to navigate
> through the group.
> We’ve reported this issue as a failure under WCAG SC 2.1.2 (Keyboard Trap).
> The development team has indicated that this behavior is part of the
> intended functionality and cannot be changed. As a workaround, they have
> implemented the Escape key feature: when pressing the Escape key while in
> the tab group, users can exit the trap and resume normal navigation using
> Tab or Shift + Tab to move to the next or previous interactive element.
> While this approach allows users to continue navigating via the keyboard,
> I’m concerned about how a keyboard-only user would know to press the Escape
> key to escape the trap. It’s not immediately clear that this is the
> solution.
> Given this, I would like to know if we can proceed with accepting this
> workaround, or if there are alternative suggestions we should consider to
> ensure compliance with WCAG 2.1.2.
> Looking forward to hearing your thoughts on this.
>
> Regards,
> Sumit.
>
>

--
Work hard. Have fun. Make history.

From: Mark Magennis
Date: Wed, Mar 26 2025 5:07AM
Subject: Re: Query Regarding Keyboard Trap Issue in Search Page
← Previous message | No next message

HI Sumit. I think the most important thing you can do here is to have to have a gentle conversation with whoever in the development team has decided on this intended keyboard behavior and has the authority to change it if you can convince them that there is a better design. Ask them what they think are the benefits of adopting this non-standard keyboard interaction. They may have some reasons that you haven't thought about and both of you will need to weigh with them against the obvious drawbacks you have raised. They may not be aware of how tab bars generally work with the keyboard so you could maybe show them some examples of tab bars in other applications that work in the standard way, preferably well known ones like google or facebook if you can find them because they often have a high, though undeserved, level of kudos. Ask them if they are following other examples. I imagine if the person is at all receptive then you will be able to win them over to making it work in the expected way. Quite possibly the "designers" aren't UX designers at all, or at least haven't studied user centered design. They may be the engineers who are coding the app, in which case you might have hard time getting them to look at things from a non-engineering perspective.

Good luck, and let us know how you get on.

Mark

From: WebAIM-Forum on behalf of Sumit Patel via WebAIM-Forum
Sent: Wednesday, March 26, 2025 07:18
To: WebAIM Discussion List
Cc: Sumit Patel
Subject: [EXTERNAL] [WebAIM] Query Regarding Keyboard Trap Issue in Search Page

Hi all,
I hope you’re doing well. I have a query regarding a keyboard trap issue in
one of our webpages.
The page in question is a search page. After performing a search, results
are displayed below the search field. In between the search field and the
results, there are four tabs that can be used to filter the search results.
For example, selecting the first tab shows all results, while selecting any
other tab will display only related results.
However, I’ve encountered an issue when navigating through the page using
the keyboard. Upon tabbing into the tab group, the focus gets trapped
within this group. This means that, using the Tab or Shift + Tab keys, I
can only navigate through the four tabs and cannot move beyond them. Each
tab receives separate tab focus, and arrow keys cannot be used to navigate
through the group.
We’ve reported this issue as a failure under WCAG SC 2.1.2 (Keyboard Trap).
The development team has indicated that this behavior is part of the
intended functionality and cannot be changed. As a workaround, they have
implemented the Escape key feature: when pressing the Escape key while in
the tab group, users can exit the trap and resume normal navigation using
Tab or Shift + Tab to move to the next or previous interactive element.
While this approach allows users to continue navigating via the keyboard,
I’m concerned about how a keyboard-only user would know to press the Escape
key to escape the trap. It’s not immediately clear that this is the
solution.
Given this, I would like to know if we can proceed with accepting this
workaround, or if there are alternative suggestions we should consider to
ensure compliance with WCAG 2.1.2.
Looking forward to hearing your thoughts on this.

Regards,
Sumit.