WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Query Regarding Keyboard Trap Issue in Search Page

for

From: Mark Magennis
Date: Mar 26, 2025 5:07AM

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.