Search input in overlay isn't keyboard accessible.
As the input click triggers the search overlay, it's never accessible by focus alone.
This task is following-up T218154
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdlrobson | T195473 [GOAL] Invest in the MobileFrontend & MinervaNeue frontend architecture | |||
| Resolved | Jdlrobson | T195478 [EPIC] Speed up unit test execution and increase code coverage | |||
| Resolved | Jdlrobson | T195482 [EPIC] Review and refactor MobileFrontend components used by Minerva | |||
| Open | None | T281930 [EPIC] Migrate MobileFrontend's code to Vue.js and Codex | |||
| Declined | None | T212465 [EPIC] None of our View's should exhibit 2 levels of inheritance | |||
| Declined | BUG REPORT | Jdlrobson | T289084 MinervaNeue shows 2 search elements when JS is disabled | ||
| Open | None | T282473 [GOAL] Use the Codex search widget inside the mobile and desktop site | |||
| Open | None | T221194 Search input of overlay is not tab-able, inaccessible by alternative input users |
Event Timeline
Comment Actions
We pointed this as a medium. This is technically tabbable, the focus state just isn't visible.
Comment Actions
When we estimates this bug yesterday I think our understand may have been incomplete. Reading over the comments in T218154, it appears that this might not be an issue with the focus state being invisible: As @Volker_E wrote:
IMHO not acceptable. But the problem lies deeper, it's not about the visual focus. That's only minor aspect.
The overlay doesn't get triggered when input is focussed upon. User can't write the input.
I think the behaviour described above would be problematic. It would mean that the overlay would open while a user is tabbing though the page, since tabbing would give focus to the input, and the focus would trigger the overlay. I think this behaviour would be pretty unexpected (i.e. the page going blank as your tabbing through it).
I think the real issue at hand here is the entire 2 input system. I think semantically, the fake input actually acts as a button rather than an input. It can receive focus, and if we add a border it'll look like it's ready to be typed into, but it's set to readonly, so it's only function is to be clicked on and send focus to the overlay with the real input.
Short of reworking the entire search overlay and the two inputs involved here, I don't see an easy way to fix this behaviour. I think ideally (IMO) we would only have one input, and we would show the overlay below the main header (so that the real input in the header is still visible), and we'd only show the overlay when the user starts typing.
Comment Actions
Do we need to rethink this (and drop associated story points) with the new information?
Comment Actions
You can actually trigger the input, but it's really hidden to keyboard users:
When tabbing to the input (and there's no visual feedback for focus provided), by pressing <Enter> you can trigger the search. You can't escape out of it by clicking <Esc>, just by tabbing further (again, no visual feedback guidance) and <Enter> on the close button again.
Comment Actions
The Minerva search is out of scope of the goal above. It will be part of the goal of adding WVUI to mobile.
Comment Actions
We have not prioritized replacing the mobile search with Codex so we should think about fixing this.