David, Laura, Dominic, Maria - are you sure we want this?

I still believe that current implementation better fits user need than this proposal.

- Regular user will still use touch/trackpad/mouse to navigate through the OOBE, so keyboard focus does not affect them. (Except that we currently prevent users from accidentally activating "I agree" button on EULA page, which could be important.)

- For Chrome VoX users it is natural to navigate from the first dialog control element to the "I am done with this".

- For Accessibility screen there was a question "if keyboard focus shadow of the first is confusing users". We can switch to "default focus on dialog itself, i.e. no control would be focused by default". this should remove confusion.

So that I think that we should treat keyboard navigation as accessible by default. I.e. if user is not using trackpad or touch, we should go through all
the options, because otherwise user will never know about them.


WDYT?

+1. I believe keyboard focus should start on each screen at the first item in the tab order.
I believe we need to ensure this happens and that each screen has a logical tab order.

For example, I believe the "Take a Picture" screen does not set default focus (unsure if that's part of OOBE).

David, yes, "User Image Selection screen" is formally not a part of OOBE, but we can still fix it ;)

 Issue 704860  has been merged into this issue.

Alexander and I just chatted a bit more about this. I think the best way to move forward here is to have the default focus on the first UI element, instead of on the OK button. I agree that if we were to put default focus on the OK button that it would be a slightly more convenient and efficient process for sighted keyboard-only users, or keyboard power users who just want to get through OOBE as fast as possible. That said, we don't really want people to just speed through it - we want them to have the right context about the first experience of Chrome OS so they know what to expect. Also, for ChromeVox users, it can be disorienting to get to a new UI and only hear "ok button", and then know that you have to backtrack through the UI to hear what you are pressing "ok" for. My vote is to place default focus on the first element. 

Laura, SGTM.
My one concern is about the visual appearance of putting default focus on elements like the Toggle Switch - it looks very odd when opening a screen with one (see attached).
Alexander, is there a way to prevent visual focus from showing while having accessibility focus on the first item?

I'll look into this. I already tried to implement "no default focus, but focus on the first UI element on pressing Tab", but this breaks ChrmeVoX as it has nothing to say.
I'll see what we can do for Accessibility settings dialog to make keyboard focus less confusing.

Yes, the problem with Accessibility dialog is that if we move default keyboard focus from the first Toggle Switch to the dialog itself (so that pressing "Tab" will move the cursor to the first control element), ChromeVoX will say nothing. And the same happens if I focus some non-control HTMLElement inside the dialog (dialog title, for example).

So this is not going to happen in M-58.
I'll talk to David about what could be done here.


Moving to M-59.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6ca3d65b4a1d2653384a84a62f7dde590dbbe4f

commit b6ca3d65b4a1d2653384a84a62f7dde590dbbe4f
Author: alemate <alemate@chromium.org>
Date: Thu Apr 13 23:40:04 2017

ChromeOS OOBE: fix JS crash in oobe-dialog focus behavior.

BUG= 707939 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2818633003
Cr-Commit-Position: refs/heads/master@{#464609}

[modify] https://crrev.com/b6ca3d65b4a1d2653384a84a62f7dde590dbbe4f/chrome/browser/resources/chromeos/login/oobe_dialog.js

I am going to close this as fixed, because HTML ARIA allows focusing only on control elements. So this is now working as expected.