Closed Bug 1708009 Opened 3 years ago Closed 3 years ago

search box falls out of tabbing order

Categories

(Firefox :: New Tab Page, defect)

defect

Tracking

()

RESOLVED INVALID

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.

  1. launch new profile
  2. open new tab with ctrl+t
  3. tab a few times from address bar to the document
  4. tab to the search box
  5. tab to the first top site
  6. 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.

Per TheCount: the issue may be because the personalize button is absolutely positioned, which is causing a number of issues.

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.

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.

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

  1. launch new profile
  2. open new tab with ctrl+t
  3. tab a few times from address bar to the document
  4. tab to the search box
  5. tab to the first top site
  6. 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?

Flags: needinfo?(asa)

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

Blocks: 1516272

Mardak, do you remember what motivated this behavior? I imagine the hand-off behavior might otherwise confuse a11y software?

Flags: needinfo?(edilee)

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

  1. launch new profile
  2. open new tab with ctrl+t
  3. tab a few times from address bar to the document
  4. tab to the search box
  5. tab to the first top site
  6. 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.

Flags: needinfo?(asa)

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

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

Flags: needinfo?(edilee)
See Also: → 1508388, 1508364, 1521757

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.

Flags: needinfo?(asa)

Sounds like this is working as expected. Resolving as invalid.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(asa)
Resolution: --- → INVALID
See Also: → 1713953
You need to log in before you can comment on or make changes to this bug.