Issue metadata
Sign in to add a comment
|
Regression : Unnecessary Focus is seen on Language and Accessibility option in OOBE screen |
||||||||||||||||||||||||
Issue descriptionChrome Version: 58.0.3021.0/9323.0.0 dev-channel Gnawty,Blaze and Paine OS: Chrome What steps will reproduce the problem? (1)Recover build -> In OOBE screen observe Blue Focus on Language i.e. on "English(United kingdom)" (2)Click on "Accessibility" and observe Focus on Toggle button of "ChromeVox(spoken feedback)" option (Please refer screenshot) Expected: No default Focus should be seen on Language and Accessibility option Actual: Instead default Focus is seen This is Regression issue as same is working fine in 58.0.3015.0/9299.0.0 dev-channel Paine @alemate: Please confirm the Issue
,
Mar 1 2017
+dmazzoni +lpalmaro As far as I know, we should focus first element of the dialog when opening it, should not we? Dominic, Laura, could you clarify this?
,
Mar 15 2017
,
Mar 15 2017
Zach, should we close this?
,
Mar 17 2017
Sorry for the delay! I'd be fine if we don't have default focus set on one of these items upon getting to that screen. But once you press tab, the focus should be visible, and once you enter one of the dialogs, then focus should be placed on the first item so it's visually clear. Thoughts?
,
Mar 17 2017
Which items do you mean?
The issue says that all three screens ('Welcome', 'Accessibility settings', 'Language selection'), and probably two extra (timezone selection and network selection) should not have default focus.
You are saing that at least two ('Accessibility settings' and 'Lanaguage selection') should have default focus. What about other two ('Network selection' and 'Timezone selection') ?
Should 'Terms of Service' screen have default focus?
,
Mar 21 2017
In the GAR documentation (go/gar-web), in Question 1.3, it says, " * When you open a page, focus goes to the most relevant content on that page. * There is always a visible highlight shown for whatever is focused, and nothing is ever focused that’s offscreen or invisible. * If you pop up a dialog, focus is set to the most important part of that dialog. * When you close a dialog, focus is set to where you were before. " The OOBE pages aren't exactly dialogs, but they're more like dialogs than web pages. My 2 cents (and that's about what it's worth): 1. On the Welcome and Terms pages, focus should be on the "Next/OK" button, since that's what most users are going to press. 2. On the Network page, it should be on the network list, since the user needs to select something there before they can proceed. 3. For the Language and A11y pages, focus should be on the first control, since if a user opens these pages, presumably they want to change something. For my own purposes, given that I can go thru the OOBE flow 10 times a day if I'm developing, I'd much rather have focus on "Let's go" than on the background page, where I have to press TAB 3 times before I can move on. I think the same might be true for an average user. And note that default focus on pages was something I requested in https://bugs.chromium.org/p/chromium/issues/detail?id=630082#c12, and which was addressed in Issue 690726 , so I'm probably a little biased here, and I'll let someone else decide whether this is WAI :-)
,
Mar 22 2017
> The OOBE pages aren't exactly dialogs, but they're more like dialogs than web pages. My 2 cents (and that's about what it's worth): > 1. On the Welcome and Terms pages, focus should be on the "Next/OK" button, since that's what most users are going to press. Keyboard navigation should access most relevant controls and then others, right? So the focus order on Welcome page should be like "Let's go", "Language/Keyboard", "Accessibility", right? We can implement this, but it will be even more confusing. We should probably make OOBE convenient (and less confusing) not for developers, but for end users, who do not usually go through OOBE 10 times a day.
,
Mar 22 2017
Yeah, TAB order not following physical order is a problem on a couple of login pages as well (sometimes it moves right to left). I'm not sure what the best way to deal with it is. I agree that we should be optimizing for users and not developers, but since I'd guess that more than 4 out of 5 users only press "Let's go", I still think default focus on that button may be the right decision. Is there a UX designer you've been working with that we could consult for advice?
,
Mar 24 2017
+Maria WDYT from an interaction design perspective?
,
Mar 27 2017
,
Mar 28 2017
,
Apr 3 2017
Hiya, I've chatted with Greg, Laura, and Zach today. Here is what I propose: - Default focus is always on primary action (big blue button) - Tabbing from default focus follows standard tab order (generally left to right) - If no primary action is available (e.g Network page) default focus falls to first menu item. Let me know if you have any questions :)
,
Apr 3 2017
Maria and others, thanks for the feedback! For clarity, let me write up my understanding of the precise implications of this: * Welcome page: Default focus on "Let's go". TAB order doesn't change, so 1st press of TAB focuses "Shut down" button; quickest way to get to Language / A11y buttons is SHIFT+TAB. * Language and A11y pages: Default focus is on OK button. (Or the first control? Do we consider the OK button to be the "primary action" for these pages?) * Network page: Default focus is on network list. * Terms page: Default focus is on "Accept and continue" button. 1st press of TAB focuses "Shut down". Please confirm behavior for Language and A11y pages. If this is correct, I'll move these into a new bug, and close this one. Thanks!
,
Apr 3 2017
Hi Greg, Yes, your described behavior is what I would expect. On the Language and Ally pages the default focus is on the OK button. Thanks!
,
Apr 3 2017
This issue has wandered off somewhat from its original description, so I summarized the content of Comment 14, and filed it as Issue 707939 . Marked "won't fix" since the original issue asked for no default focus, and no work has been done along those lines. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by mmanchala@chromium.org
, Feb 28 2017