search box falls out of tabbing order
Categories
(Firefox :: New Tab Page, defect)
Tracking
()
People
(Reporter: asa, Unassigned)
References
Details
(Whiteboard: access)
When I first tab to the new tab page the order is 1) document, 2) search box, 3) first top site. However, when I attempt to shift+tab to to get from 3) to 2) it skips the search box and takes me to the new tab customize button (which was curiously missing when I first opened a new tab.)
Steps to reproduce.
- launch new profile
- open new tab with ctrl+t
- tab a few times from address bar to the document
- tab to the search box
- tab to the first top site
- shift+tab to get back to search box
Results
Search box is no longer part of the tabbing order after initial interaction.
Expected results
Tab order should be from the toolbar to the document to the Personalize button to the search box to the top sites and should work in reverse order with shift+tab, no matter how much a user tabs around the page.
Comment 1•3 years ago
|
||
Per TheCount: the issue may be because the personalize button is absolutely positioned, which is causing a number of issues.
Comment 2•3 years ago
|
||
I had observed that behavior too, but hadn't considered it a problem as this search box now just sends one back to the address bar - which might be confusing keyboard interaction going in a loop. (Might be that I miss something here.)
Also noticed that the search box is set to tabindex="-1" which lead me to assume this was done intentionally.
Comment 3•3 years ago
|
||
Yeah, I think you're right, I think it might be intentional, to avoid that potential loop you mentioned. It's not related to the position of the personalize button.
Also, I looked at the code, and I don't think this is a recent change.
Comment 4•3 years ago
|
||
(In reply to Markus Jaritz [:designakt] (UX) from comment #2)
Also noticed that the search box is set to tabindex="-1" which lead me to assume this was done intentionally.
Yeah, this is intentional. aria-hidden="true"
is set as well.
(In reply to Asa Dotzler [:asa] from comment #0)
When I first tab to the new tab page the order is 1) document, 2) search box, 3) first top site. However, when I attempt to shift+tab to to get from 3) to 2) it skips the search box and takes me to the new tab customize button (which was curiously missing when I first opened a new tab.)
Steps to reproduce.
- launch new profile
- open new tab with ctrl+t
- tab a few times from address bar to the document
- tab to the search box
- tab to the first top site
- shift+tab to get back to search box
Step 4 doesn't work for me, it takes me straight to the first top site. Am I missing something?
Comment 5•3 years ago
|
||
(In reply to Scott [:thecount] Downe from comment #3)
Also, I looked at the code, and I don't think this is a recent change.
Seems to go back to the initial search hand-off implementation.
Comment 6•3 years ago
|
||
Mardak, do you remember what motivated this behavior? I imagine the hand-off behavior might otherwise confuse a11y software?
Reporter | ||
Comment 7•3 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #4)
(In reply to Markus Jaritz [:designakt] (UX) from comment #2)
Also noticed that the search box is set to tabindex="-1" which lead me to assume this was done intentionally.
Yeah, this is intentional.
aria-hidden="true"
is set as well.(In reply to Asa Dotzler [:asa] from comment #0)
When I first tab to the new tab page the order is 1) document, 2) search box, 3) first top site. However, when I attempt to shift+tab to to get from 3) to 2) it skips the search box and takes me to the new tab customize button (which was curiously missing when I first opened a new tab.)
Steps to reproduce.
- launch new profile
- open new tab with ctrl+t
- tab a few times from address bar to the document
- tab to the search box
- tab to the first top site
- shift+tab to get back to search box
Step 4 doesn't work for me, it takes me straight to the first top site. Am I missing something?
I am no longer able to reproduce step 4. Now I see the search box skipped completely.
Reporter | ||
Comment 8•3 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #5)
(In reply to Scott [:thecount] Downe from comment #3)
Also, I looked at the code, and I don't think this is a recent change.
Seems to go back to the initial search hand-off implementation.
I can tab to the search box on release Firefox and cannot on Nightly.
Comment 9•3 years ago
|
||
The original about:newtab bug 1508388 implementing this had some comments about accessibility that seemed to include moving focus as well as keyboard interactions, so it originally landed with it being tabbable. But some reason bug 1508364 comment 4 noted the about:privatebrowsing implementation uses tabIndex=-1, and that got copied over to about:newtab in bug 1521757.
Looks like it originally landed with keyboard access early in 66 cycle and got removed later in 66 to address some bugs that block the port bug:
bug 1519713: search handoff is suboptimal when a user has previous disabled search suggestions in the address bar
bug 1520512: When type something in-content search using Japanese IME, caret is staying in in-content search field
bug 1521098: Cannot enable Japanese IME in the in-content search field using keyboards
bug 1521446: search box in Firefox Home page doesn't work if "search when typing" option is on
Comment 10•3 years ago
|
||
NI Asa again who was going to ask Jamie Teh about a11y software behavior when moving focus in the middle of typing.
But based on just comment 9, I think this is wontfix even for non-a11y reasons.
Reporter | ||
Comment 11•3 years ago
|
||
Sounds like this is working as expected. Resolving as invalid.
Updated•3 years ago
|
Description
•