Organize Accessibility settings |
||||||||||||||||||||||||||
Issue description
There are too many checkboxes in the Accessibility section. This is not a bad thing, it means we have lots of accessibility features for users now and under development! But we need to organize them better.
Here are two ways we could organize the existing settings to more easily group things. Note that the proposals below include not-yet-launched accessibility features that are shown if you flip the "Enable experimental accessibility features" flag; I think it makes more sense to design what it should look like when these ship rather than only considering what's shipping now.
*** PROPOSAL 1 ***
[x] Show accessibility options in the system menu
Vision:
[x] Enable ChromeVox (spoken feedback)
[x] Use high contrast mode
[x] Enable screen magnifier
[x] Highlight the caret (when editing text)
[x] Show large mouse cursor
[x] Highlight the mouse cursor
[x] Highlight the object with keyboard focus
[x] Select-to-speak: Hold down Search and click or drag to speak anything
Interacting:
[x] Enable sticky keys
(to perform keyboard shortcuts by typing them sequentially)
[x] Enable tap dragging
[x] Automatically click when the mouse pointer stops
Delay before click:
[x] Enable on-screen keyboard
[x] Switch access (control the computer with just one or two switches)
Audio:
[x] Play the same audio through all speakers (mono audio)
*** PROPOSAL 2 ***
[x] Show accessibility options in the system menu
Speech:
[x] Enable ChromeVox (spoken feedback)
[x] Select-to-speak: Hold down Search and click or drag to speak anything
Display:
[x] Use high contrast mode
[x] Enable screen magnifier
Keyboard:
[x] Enable sticky keys
(to perform keyboard shortcuts by typing them sequentially)
[x] Enable on-screen keyboard
[x] Highlight the object with keyboard focus
[x] Highlight the caret (when editing text)
[x] Switch access (control the computer with just one or two switches)
Mouse:
[x] Automatically click when the mouse pointer stops
Delay before click:
[x] Enable tap dragging
[x] Show large mouse cursor
[x] Highlight the mouse cursor
Audio:
[x] Play the same audio through all speakers (mono audio)
,
Jun 2 2016
How about organizing by need. 1. Have text read aloud: Chromevox and Click to Speak. 2. Make the screen easier to see: Magnifier and High Contrast. 3. Make the cursor / focus easier to find: Large mouse pointer, heighlight mouse pointer, heighlight caret and heighlight focused object. 4. Make the keyboard easier to use: On-Screen Keyboard and Sticky Keys. 5. Access the computer through an alternative input device: Switch access. 6. Make audio easier to hear: Mono audio.
,
Jun 2 2016
,
Jun 24 2016
,
Jul 18 2016
I'd say I like Dominic's proposal #2 the best so far. I think it's the most clear and doesn't categorize the features into specific accommodations (which helps since some of these features are useful for more than one user group, like TTS being helpful for both visually impaired and dyslexic users).
A few notes in line, marked with"LP":
[x] Show accessibility options in the system menu
LP: We should revise what this looks like in the system menu. Right now, we only show a few options there, and they are predetermined. I've received feedback from users that when they check that checkbox and have those accessibility settings in their menu, then they forget that there are actually more a11y settings since the UI only has the button for "settings" at the bottom of the menu, when it should say "More Settings" or something like that. I'd ideally like to see the short list in themenu be customizable, to show the most popular settings by default, then have the user be able to show their most recently enabled settings in that list to provide a better, more catered experience based on the user's needs.
Speech:
LP: I'd recommend we call this "Text To Speech" as to not confuse users, since they might think it means dictation.
[x] Enable ChromeVox (spoken feedback)
LP: Let's be sure to include a button to access the ChromeVox options page
[x] Select-to-speak: Hold down Search and click or drag to speak anything
Display:
[x] Use high contrast mode
[x] Enable screen magnifier
LP: Could be useful to include links to other parts of ChromeOS settings UI, e.g. to adjust screen resolution and increase font size
Keyboard:
[x] Enable sticky keys
(to perform keyboard shortcuts by typing them sequentially)
[x] Enable on-screen keyboard
[x] Highlight the object with keyboard focus
[x] Highlight the caret (when editing text)
[x] Switch access (control the computer with just one or two switches)
LP: Let's include a link to the keyboard settings here, the page in settings that allows you to adjust keyboard repeat rate, and the page that allows you to enable auto capitalization, word prediction, etc. We need to make these more discoverable for users through a11y settings.
Mouse:
LP: Let's make this Mouse & Trackpad:
[x] Automatically click when the mouse pointer stops
Delay before click:
[x] Enable tap dragging
[x] Show large mouse cursor
[x] Highlight the mouse cursor
LP: Let's link to the portion in settings to enable/disable tap to click
Audio:
[x] Play the same audio through all speakers (mono audio)
Thoughts?
,
Jul 19 2016
@Laura, when I say organize by need I am not referring to disability. I am being more descriptive concerning what the feature helps you accomplish. Instead of saying "keyboard" or "mouse", I would like to say "Make the cursor easier to find" etc. Up to you, of course.
,
Jul 19 2016
Totally. I was actually referring to the first proposal that refers to "vision" as a category, for example. Other's thoughts?
,
Jul 19 2016
organizing by input method ("PROPOSAL 2") sgtm
,
Jul 19 2016
Great, I'll make a first attempt at implementing something like what we're converging on in a changelist - Proposal 2 plus as many of Laura's suggestions as I can do. I'm assuming it will be okay to just land the change in Canary and then tweak after going through UI review?
,
Jul 19 2016
> just land the change in Canary and then tweak after going through UI review? I'm don't have strong opinions about the organization of a11y, but bettes@ or tbuckley@ might. I wouldn't normally recommend consulting UI review /after/ implementing something (seems a little backward), but this case may be OK if what you're doing is not controversial to anyone (seems to be smooth sailing so far).
,
Jul 19 2016
I don't*
,
Jul 19 2016
The reason I thought it might make sense to just implement it first here is because MD settings haven't even launched yet, right? I'll reach out to bettes@ or tbuckley@
,
Jul 19 2016
dmazzoni@: it's out on canary* (so not /really/ launched, no)
,
Jul 20 2016
,
Jul 20 2016
I think there are 2 things we need to decide on here: 1) should we use toggles or checkboxes 2) how to convey the logical organization of our sub-lists I'm attaching some other places we show hierarchical list-y things just to get a better feel for this stuff.
,
Jul 21 2016
Related is issue 164273 , which asked why "Enable tap dragging" and "Tap to click" were in different sections (unlike every other OS on the face of the planet). Currently "Enable tap dragging" is duplicated between the Accessibility and Device sections. Here's a screenshot of the "Mouse and touchpad" subpage in Device Settings: https://bugs.chromium.org/p/chromium/issues/attachment?aid=241031&inline=1
,
Jul 22 2016
I prefer to keep the settings as checkboxes, as too many toggles gets overwhelming. We really only use them for enabling/disabling top-level items (eg. wifi/bluetooth/autofill). Not sure what the right spacing / use of dividers is, so I'd like to get Alan's advice.
,
Jul 24 2016
Hey everyone, Apologies for the late response, still re-grouping from my OOO. I love the organization of information here. I agree with Laura on moving forward with proposal 2. It feels like a more logical way to categorize and I also don't have any strong objections to Laura's suggestions in comment 5 so those LGTM as well. One note on the "[x] Show accessibility options in the system menu": LP: We should revise what this looks like in the system menu... bettes: This is outside the scope of this particular bug, however the concerns are totally valid and should be taken into account when revisiting the UI. This is something that should be taken up with chromeos-ui-review@ Re: process Generally it's best to consult UI review with a proposal that includes mocks assembled by someone on the UX team *before* implementation. Given the scale of settings, it's been difficult to standardize a more formal process for feature requests like this one but I agree with dbeam, there's very little contention involved with this request so UI review can be looped in afterwards. Re: design See attachment. I've also updated mocks on folio: https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20Inner%20Pages/03-Settings/preview/cards#%2FPREVIEW-Accessibilty.png%3Fz=width Question for Laura: To cut down on the height of the a11y card, I think we need to consider moving the majority of settings to a subpage. The suggestion I've included in the mocks is intentionally aggressive, but maybe too aggressive. There's precedent to highlight pertinent information at the top-level, with a "Manage" acting as a read more mechanism so let me know what your thoughts are here. Notes regarding implementation: - Implementation is gated on what we show in the main page and what we show in the subpage. - Specs on subpage layouts, including sub-headers, can be found here: https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20Inner%20Pages/03-Settings/specs#%2FSPEC-settings_structure-subpage.png%3Fz=width - do not custom edit row heights for checkboxes. They should be using the standardized height of 44px for now. We will re-evaluate opportunities for density at a later time. - Please use checkboxes, not toggles, unless otherwise specified. - If "show accessibility options in the system menu" remains at the top-level, using a toggle switch is appropriate to use. ** Last but not least, the "delay before click" should be using our polymer components, not native.
,
Jul 25 2016
(@lpalmaro -- we're also updating the System Menu as part of MD CrOS, so if the a11y row needs changes let's talk about that now in a separate thread)
,
Jul 26 2016
@bettes Thanks for the great feedback and for the mock! I like the idea of accessibility as a subpage, I think that will clean it up. It also means it will have a bookmarkable url, which is a plus for those of us who go there frequently. I'll do my best to implement that mock and update this bug when I have it ready.
,
Jul 29 2016
,
Jul 29 2016
The <h3>s in #16 are different from the headers in the Pointers page: 612986: https://bugs.chromium.org/p/chromium/issues/attachment?aid=241031&inline=1 Is there a consistent header style to use, or are these supposed to be different?
,
Aug 4 2016
Here are screenshots of the change I'm going to land soon implementing this. It matches the mock in comment #20 pretty closely. The first two screenshots are what would ship now, in Chrome 54. The second two screenshots show what it would look like when select-to-speak and switch access are launched, in the fture.
,
Aug 4 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2fa2772be4152c0291ff745f19bd3ace41bf82cd commit 2fa2772be4152c0291ff745f19bd3ace41bf82cd Author: dmazzoni <dmazzoni@chromium.org> Date: Thu Aug 04 22:56:53 2016 Reorganize accessibility settings. Based on the mock in the bug, put the accessibility settings into a subpage, organize them by category, and add additional helpful links. BUG= 616802 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation Review-Url: https://codereview.chromium.org/2200463002 Cr-Commit-Position: refs/heads/master@{#409924} [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/app/chromeos_strings.grdp [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/a11y_page/a11y_page.html [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/a11y_page/a11y_page.js [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/a11y_page/compiled_resources2.gyp [add] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/a11y_page/manage_a11y_page.html [add] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/a11y_page/manage_a11y_page.js [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/advanced_page/advanced_page.html [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/icons.html [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/route.js [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/resources/settings/settings_resources.grd [add] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/ui/webui/settings/chromeos/accessibility_handler.cc [add] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/ui/webui/settings/chromeos/accessibility_handler.h [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/browser/ui/webui/settings/md_settings_ui.cc [modify] https://crrev.com/2fa2772be4152c0291ff745f19bd3ace41bf82cd/chrome/chrome_browser_ui.gypi
,
Aug 5 2016
This has landed and it's ready for UI review.
,
Aug 10 2016
,
Sep 19 2016
,
Sep 28 2016
verified on 54.0.2840.42 |
||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||
Comment 1 by dbeam@chromium.org
, Jun 2 2016