Adding flags for accessibility settings?

52 views
Skip to first unread message

Stephen Mcgruer

unread,
Jun 26, 2019, 9:27:29 AM6/26/19
to flag...@chromium.org, abox...@chromium.org
Hey flags-dev,

I recently landed support for an accessibility feature, 'PrefersReducedMotion', which allows users to tell the browser (and websites) that they prefer to avoid movement-based animations/etc (commonly used by people with vestibular disorders). Unfortunately not all platforms have a system-level setting for this that we can read (Linux and ChromeOS), so by user request I recently added a switch, --force-prefers-reduced-motion, to force Chromium to ignore the system setting (if it exists) and enable the accessibility mode.

During review, the accessibility reviewer reasonably asked for this to be a chrome://flags setting, so that we aren't forcing users trying to use accessibility features to figure out how to add command line flags to their browser (and to enable it on ChromeOS, where I'm not sure whether you even can set command line flags?). I read https://chromium.googlesource.com/chromium/src/+/master/docs/flag_ownership.md#wait_what-are-you-doing, and it seems pretty explicit that flags must be for temporary experimental settings, or must otherwise be frequently used debugging settings - which this change wouldn't meet.

Am I reading the flag_ownership document correctly? If so, what is the preferred route to support users trying to change accessibility features - try to add something to chrome://settings ? (Amusingly my understanding is that they also don't like new entries, to again reduce the burden on users and QA!)

Thanks,
Stephen

Avi Drissman

unread,
Jun 26, 2019, 10:22:20 AM6/26/19
to Stephen Mcgruer, flags-dev, abox...@chromium.org
Yes, this strikes me as something that should go into chrome://settings under the Accessibility section, for several reasons.

First, as you noted, flags are for temporary settings and debugging flags. While about:flags is a place to tinker, it's not intended for most users to find their way in there, whereas preferences are designed to help users find what they're looking for.

Second, in settings we have mechanisms to bounce people to system settings when the setting is maintained by the system. An example I can think of that was recently added was styling media captions; on the Mac and Windows it bounces the user to the system settings, and handles the setting for all other platforms. Even though your settings is intended to override the system setting, that may be useful to build your UI. (Maybe a link to access the system setting and a switch to force it off? The UI folks can help you craft something good here.)

Third, the flags page is, honestly, a UI mess. For good reason, though, since it helps discourage people from mucking around in there. The preferences pages are neatly organized into sections; there already is an Accessibility section where your setting would fit well.

Fourth, and importantly, about:flags is not localized. As a place for temporary settings and debugging flags, that's the decision we've made, but for a setting that an average user may need to access, sticking it in a place in Chrome's UI that is in a language they don't speak is not the right approach.

This belongs in the settings page. Yes, we try to minimize the number of switches (both settings and flags!) but if something needs to be set, it needs to be set. Talk to the settings people; they should be helpful.

Thank you for emailing us. If there's anything we can do to support you further with this setting, please let us know.

Avi

--
You received this message because you are subscribed to the Google Groups "flags-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flags-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/flags-dev/CADY3MadaY1O1RzJcHwruX2vm4gJ2FgMWyHLLrr8mMCPzAibBtw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages