This is relevant for mustash (mus + ash)
On https://codereview.chromium.org/1785833002/, we discussed moving some of the Chrome OS accessibility code out of chrome/browser.
I think there are a lot of different pieces to this, let's separate them:
1. Where should the Chrome OS accessibility preferences be defined? Options include:
chromeos/chromeos_pref_names.cc
chrome/common/pref_names.cc
ash/??? (where? i can't find any chromeos ui prefs in ash currently)
It does seem useful to put all of the accessibility preferences in one place, so wherever we choose should be somewhere that can be accessed from any module that may want to query or modify accessibility preferences.
2. Where should the simplest Chrome OS accessibility features like Large Cursor be implemented?
Right now the implementation is split across ash/ and chrome/browser/, but there's almost no point because the guts are in ash. For this particular feature at least, I don't see any reason to expose it in AccessibilityDelegate or put any of its code in chrome/browser, it could be entirely in ash/.
One open question: can ash/ access per-profile preferences? If not, could we easily abstract the feature that an accessibility preference set on the login screen gets "inherited" to a logged in profile?
3. Where should Chrome OS accessibility features that use some Chrome APIs, like Magnification, be implemented?
Magnification is split pretty evenly between ash/ and chrome/ - the ash/ part does the graphics transform work, but chrome/ is needed to monitor focus changes. The chrome/ part also monitors profile changes, but it's not entirely clear to me why. Interestingly, the code to monitor caret movement is entirely in ash/ already.
So at first glance it seems like we'd need:
* An interface to watch focus changes from ash/
* Possibly something to handle profile changes / pref syncing for accessibility features
4. Where should Chrome OS accessibility features that use extension APIs, like ChromeVox, be implemented?
Spoken Feedback (ChromeVox) is implemented as an extension. Some of the native code pieces required to turn on/off the Chrome OS feature include:
* Enabling and disabling the extension, and sending JavaScript to the extension
* Opening a native "panel" window for ChromeVox to display status messages and overlays, and closing it when the extension closes
* Intercepting and rewriting native events based on a private extension API (i.e. ChromeVox says it wants to start capturing keystrokes, then says it doesn't want to).
There are other accessibility features under development that will be built using extensions, so at a minimum enabling the accessibility feature will require enabling an extension.
Conclusions so far:
* It does seem like it would reduce some wasted code to move some accessibility features, like Large Cursor, out of chrome/ and into ash/ only, and others, like Magnification, mostly out of ash/ except for a new interface to allow it to listen to focus changes
* Several accessibility features depend on access to both ash/ and extensions/, plus other Chrome APIs, which seems to imply that chrome/ is the only place we could put them. Given that, is it worth making any changes at this point?
What changes would we need for Mustash?
Assigning to Oshima to respond, feel free to assign back to me with specific goals.
Comment 1 by rjkroege@chromium.org
, Oct 4 2016Labels: Proj-Mustash