This also applies to JAWS 2018.1710.42 private preview release and NVDA 2017.3 in Google Chrome 64.0.3250.0 (Official Build) canary (64-bit) (cohort: 64-Bit)

This is intended behavior, and not related to screen readers: The "search box" on the NTP (called the "fakebox") isn't actually a search box, it just redirects to the omnibox. I believe the reasoning for this behavior was:
a) Having two actual search boxes would be confusing.
b) Educate users that they can search using the omnibox.

I'm closing this as WAI, feel free to reopen if there are further concerns. (That said, the current behavior is a continuous source of confusion, and we'll re-evaluate it during the next NTP redesign.)

Hi Marc,

I'd like to keep this open for a PM/designer to look over. While I understand your reasoning, it's still really confusing to have the focus jump out of the tab order like that regardless of the cause.  

Assigning to Hwi for a closer look and comment on priorities, etc. 

Thanks,

Laura 

Here's broken-down issues and fix suggestions on the NTP searchbox per the discussion with leberly@ and dsexton@. 

[Issue breakdowns]

A. Keyboard navigation
Not being able to select the search box with keyboard is frustrating. 

B. Screenreader navigation
Currently the search box can be read by SR navigation but labeled poorly that it's unclear of its intended action. It reads the hint text 'Search Google or type URL' but typing it doesn't do anything. Clicking actually works to go to Omnibox but it's not labeled accordingly so that SR user is unlikely to know that you can click on it. Side note: fixing #A should not break the screenreader experience. 

C. Screen magnifier navigation (e.g. ZoomText)
Clicking the search box moves the focus to the Omnibox. Since the screen is magnified, the automatic moving of the zoomarea/focus is not easy to comprehend. Not having any focus indication on the omnibox (crbug.com/701133#c11) makes it even difficult to understand why that happens and how to proceed the search task that the user initiated. 

[Fix suggestions]

1 and 2 addresses issue #A, 3 addresses issue #B, and 4 addresses issue #C. 

1. Make the search box element Tab-navigable by using tabindex=0 (i.e. a way to make a non-form element be in a page's focus order) so it can be reached with keyboard Tab key. Note: in the current code, this is probably best to be done in <div id="fkbx-text">, not in <input id="q"> in order to keep the current behavior of using Omnibox as the only way to type in url or query.

2. On the box element of #1, make onkeypress event listened, and, when the keyboard user starts typing letters, move the focus to the omnibox and insert the typed letter in the omnibox. This replicates the intended behavior of using a mouse.

3. Add "role=button" for the box element of #1 so screenreader can identify it as a button so the screenreader user can click on it to go to the omnibox. Side note: No need to special-casing taborder for this transition since going to different place by clicking a button is an expected behavior in the screenreader context.

4. Fix the issue "No focusring on omnibox" crbug.com/701133#c11

Please feel free to discuss further. Thanks you for reading and looking into this! 

Also  crbug.com/696239  contains the same issue and related discussions

Fixes 1 and 2 will probably look a bit different in practice, due to the special fakebox-omnibox integration. It *might* be enough to just make the fakebox tabbable by removing the "tabindex=-1", but probably there'll be extra work to make it all work together.

Fix 3 should be easy. I'm not entirely convinced that we should treat the fakebox as a button, but I guess it's the smallest evil...

Fix 4 isn't an NTP issue, let's continue tracking that at bug 701133.

Thanks for the detailed breakdown and suggestions!

As I expected, making the fakebox keyboard-focusable is more complicated due to the way the fakebox-omnibox integration works. What currently happens in this: You click on the fakebox, and Chrome moves *invisible* focus to the omnibox. In the fakebox, we show the blinking fake-cursor so that it looks focused, but it doesn't actually have focus.

Now the problem with making the fakebox accessible via tabbing is that we'd still have to move the actual focus (invisible) to the omnibox. So then when you continue tabbing, it'll start at the beginning of the page again, meaning everything that comes after the fakebox is completely inaccessible by tabbing.

I don't see a way to get this to work with the current embeddedSearch.searchBox APIs. I'm open for ideas.

 Issue 696239  has been merged into this issue.

How about we just do a bit more work to complete the current illusion?

Right now if you click on the fakebox, visually we show the flashing cursor there, even though focus is really on the omnibox. So clearly we already distinguish between that state, and when focus is really in the omnibox. We just need to complete the illusion.

* We need to make accessibility focus seem like it's in the fakebox. I can help with that. Accessibility focus is completely separate from input focus, and we can just add a special case for this.
* When the user has focused the fakebox and presses Tab, we should behave as if the user was really in the web page. Maybe that means tabbing to the "real" Omnibox.

@treib, let's discuss any technical limitations that would make this hard.

I think adding a11y focus should be straightforward, since the whole fake-focus implementation of the fakebox is manual anyway. What exactly does a11y focus involve?

"Completing the illusion" wrt keyboard focus will be quite cumbersome though. Basically, I think we'd have to add special code to the omnibox to hand focus back to the middle of the page, instead of following the normal order.

> I think adding a11y focus should be straightforward, since the whole fake-focus implementation of the fakebox is manual anyway. What exactly does a11y focus involve?

We'd want to override the AX_EVENT_FOCUS notification in View::OnFocus for the Omnibox, and then somehow trick RenderWidgetHostView::HasFocus() into returning true so that the web accessibility code thinks it has focus. Or we could plumb through the special case directly to BrowserAccessibilityManager and tell it to fire focus events even though the RWHV says it's not focused.

> "Completing the illusion" wrt keyboard focus will be quite cumbersome though. Basically, I think we'd have to add special code to the omnibox to hand focus back to the middle of the page, instead of following the normal order.

Yeah, that's what I had in mind. Cumbersome, but I think that's the only way we're going to get a truly accessible experience for all users.

Maybe it won't be that hard, though. If the fakebox is actually focusable (tabindex=0), then when the user tabs out of the omnibox we'd just put Views focus back on the Tab, and then fire a synthetic Tab keypress on the web contents, since the web contents' active element should still be on the fakebox.

Wait, I'm confused now. I thought we wanted to pretend like the *fakebox*
had actual focus?
The *Omnibox* already gets focus when the fakebox is clicked, it's just a
special "invisible" focus state. I don't know how that state is reported to
a11y tools, but that should be easy to change.
Maybe a quick VC would be best?

I have little experience with Views code (and I think Mac still doesn't use
Views?), but I guess that could work. So the logic would look something
like:

Omnibox::OnKey(key) {
  if (key == TAB && focus_state_ == INVISIBLE_FOCUS) {
    tabContent.SetFocus();
    tabContent.FireKey(TAB);
    return;
  }
  ...
}

 Issue 777066  has been merged into this issue.

> Wait, I'm confused now. I thought we wanted to pretend like the *fakebox*
had actual focus?

Yes, that's correct, and sorry if I was unclear.

> I have little experience with Views code (and I think Mac still doesn't use
> Views?), but I guess that could work. So the logic would look something
> like:

> Omnibox::OnKey(key) {
>   if (key == TAB && focus_state_ == INVISIBLE_FOCUS) {
>     tabContent.SetFocus();
>     tabContent.FireKey(TAB);
>     return;
>   }
>   ...
> }

Yes, that's what I had in mind.

> Omnibox::OnKey(key) {
>   if (key == TAB && focus_state_ == INVISIBLE_FOCUS) {
>     tabContent.SetFocus();
>     tabContent.FireKey(TAB);
>     return;
>   }
>   ...
> }

I've looked into this a bit more, and I don't see a way to do it without super-intrusive changes to the core focus logic, i.e. adding a special case in FocusManager::SetFocusedViewWithReason or something along those lines. Over to dmazzoni who might have better ideas.

Zach Koch is considering a redesign of the NTP, this may be a non-issue. Waiting until we hear back to move on.

Still Pri-1, but let's wait for a decision before starting any next steps.

Also affects keyboard only users on Chrome OS
69.0.3473.0 (Official Build) dev (64-bit)			Google_Lulu.6301.136.57

 Issue 647285  has been merged into this issue.