In some more detail:

high-contrast: technically works, but we don't have gtk3 a11y themes atm
zoom: works, but the a11y panel in the control-center needs to be taught to use the same settings, I guess
large text: doesn't seem to do anything. the same is true for the control-center setting, but it feels like there is some loop that causes the setting to revert to its old value immediately
screen reader: doesn't work and should probably be dropped from 3.0 ?
screen keyboard: ditto ?
visual alerts: works (i've filed a separate bug about making fullscreen flashing work)
accessx settings: seem to toggle the right setting, but forget to toggle the overall 'keyboard a11y' setting that shows up as a checkbox in the cc panel

*) High Contrast -> code is right, the bug is the absence of a real high contrast theme (but icons work)
*) Large text -> bug in gnome-settings-daemon, we're using the correct GSettings key, it ought to be exposed in XSettings
*) Screen Reader / Screen Keyboard -> there are two keys for each of these, one at org.gnome.desktop.default-applications.at.{mobility,visual}, which mirrors the GConf key used in GNOME 2.32, and one at org.gnome.desktop.a11y.applications, which mirrors a key used in GDM 2.32, but which is referenced also in orca autostart files. Don't really know how to fix this, I have never managed to make it work when it was GConf, and have never tested a gnome-session with GSettings.
*) Everything else should work, it was tested at some point and nothing was changed, unless I didn't notice. In particular, keyboard modifiers should work even if a11y keybindings are disabled.

*) Large text -> bug in gnome-settings-daemon, we're using the correct
GSettings key, it ought to be exposed in XSettings

I'll investigate

> *) Everything else should work, it was tested at some point and nothing was
> changed, unless I didn't notice. In particular, keyboard modifiers should work
> even if a11y keybindings are disabled.

In that case, the 'Turn on a11y features from the keyboard' checkbox in the panel is confusing to me. What does it do ?

Created attachment 178541 [details] [review]
A11yStatus: ignore an user default of O dpi

The default for the DPI setting is 0, but 0 * any scaling factor
is 0, so we need to deal with that, by falling back to X default.

Comment on attachment 178541 [details] [review]
A11yStatus: ignore an user default of O dpi

>+        let default_value = initial_setting || user_value == 0 ? x_value : user_value;

ok to commit if you put ()s around "initial_setting || user_value == 0"

Attachment 178541 [details] pushed as 12d991f - A11yStatus: ignore an user default of O dpi

*** Bug 643712 has been marked as a duplicate of this bug. ***

I don't think this really should have gotten marked FIXED, since for the most part, things still don't work.

(In reply to comment #1)
> high-contrast: technically works, but we don't have gtk3 a11y themes atm

I believe we have those now, although there's still the problem that (a) we don't specify whether this is light-on-dark or dark-on-light, and (b) we don't have a11y themes for the shell itself

> large text: doesn't seem to do anything

if this doesn't work, it would seem to be g-s-d's fault

> screen reader: doesn't work and should probably be dropped from 3.0 ?
> screen keyboard: ditto ?

Agreed, this potentially requires configuration, requires turning on the a11y key if it's not already on, which we don't do, and potentially requires a relogin.

> accessx settings: seem to toggle the right setting, but forget to toggle the
> overall 'keyboard a11y' setting that shows up as a checkbox in the cc panel

I'll figure out what's up with that.


Though given the generally awful state of a11y in 3.0, I wonder if we shouldn't just drop the menu for now.

(In reply to comment #8)
> > large text: doesn't seem to do anything
> 
> if this doesn't work, it would seem to be g-s-d's fault

Works for me (TM)

Created attachment 182404 [details] [review]
panel: remove accessibility icon

After some discussion with Jon, here's a patch to remove the menu.
Everything there can also be done from the capplet anyway, although
we may want some default keybindings for some things that don't
currently have any (eg, zoom).

Review of attachment 182404 [details] [review]:

The implementation seems fine.

Attachment 182404 [details] pushed as 7790a07 - panel: remove accessibility icon

Screen reader works as long as you have an updated orca. Caribou is still broken, but screen keyboard should work once ported to GNOME 3.

The "visual alerts" not working would be a mutter bug.

All the other items work as they should, I spent enough time implementing them in gnome-settings-daemon that they should.

We are past ui freeze, so this needs to get approval before it gets committed.

Well, it's already committed, because I forgot about UI freeze, but we can revert it. Presumably we at least want to remove the Screen Keyboard entry.

(In reply to comment #15)
> Well, it's already committed, because I forgot about UI freeze, but we can
> revert it. Presumably we at least want to remove the Screen Keyboard entry.

Making caribou work in GNOME 3 is probably less work than removing the option in gnome-shell and in gnome-control-center, and with certainly fewer side-effects.

This functionality just isn't up to par and I don't think we should add it in until 3.2.  This is a tough decision but I think it is the right one.  The options will still be available (when possible) from the System Settings.

Caribou for example is not the right solution.  And it isn't a matter of just making it work.  It needs to be designed properly.

(In reply to comment #17)
> This functionality just isn't up to par and I don't think we should add it in
> until 3.2.  This is a tough decision but I think it is the right one.  The
> options will still be available (when possible) from the System Settings.
> 
> Caribou for example is not the right solution.  And it isn't a matter of just
> making it work.  It needs to be designed properly.

That may be, but I'd like to ask for some respect for the process here. Can we

a) revert the outright removal of the a11y menu

b) send a mail about removing just the on-screen keyboard, with a rationale for why that would be better than just fixing caribou to work


Matthias, putting his release team hat on

Regressing like that in a11y is a bit silly. Sure Caribou will look silly in GNOME 3, but I'd much rather it was present and looking bad than not present at all.

In any case, it's not just cause to removing the whole of the a11y menu. And it costs next to nothing reaching out to the a11y team.

I think the question of "are Caribou/Orca good enough, and if not, is the best way to handle that an emergency patch to turn off the a11y menu" (if Caribou and Orca are the reasons why think the a11y menu isn't working), deserves to be handled more publicly and on record than an IRC conversation. Can we revert the patch and deal with this on email to release-team and cc: the accessibility list?

Comment on attachment 182404 [details] [review]
panel: remove accessibility icon

reverted

Whether they're good enough or not, my case (that was duped to this bug) is that the menu offered them even when they weren't installed. Is that a case we want to handle in the shell?

Created attachment 183130 [details] [review]
accessibility: remove Screen Reader and Screen Keyboard entries

per discussion on release-team

Review of attachment 183130 [details] [review]:

Looks good for now. I hope it will be reverted as soon as gnome-shell is branched for 3.0.

Attachment 183130 [details] pushed as 0a3d80b - accessibility: remove Screen Reader and Screen Keyboard entries