WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Query Regarding Keyboard Trap Issue in Search Page

for

From: Birkir R. Gunnarsson
Date: Mar 26, 2025 1:41AM

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 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.