Re: [g-a-devel] Possible UI freeze break: acccessibility menu in panel

From: Owen Taylor <otaylor redhat com>

> OK, the current time, the accessibility menu in GNOME Shell is a
> prominent place revealing quite a bit of stuff that isn't working very
> well. Going through the items:
>  High Contrast: no implementation for the shell (though it's mostly reasonably
>    high contrast to start with except for text colors), GTK+ and icon themes working 
>    only sort of OK. 

More about gnome shell and themes:

>  Zoom: Works well
>  Large Text: Works pretty well
>    (shell patch:
>  Screen Reader:
>  Onscreen Keyboard: 
>    These are the problematical ones. Some of the issues:
>    - Accessibility needs to be turned on with a logout and log back in 
>      for these to work. So it doesn't really make a lot of sense to have
>      them in a menu. We're not close to having accessibility to a
>      state where it can be on by default.
>    - The shell integration with screen reading is bad though
>      there is basic support for exposing actors to screen reading.
>      Screen reading in general is probably not good enough to be something
>      we want to make an advertised prominent feature of 3.0.

I agree, right now orca reacts to gnome-shell, but it would be
required to solve this bug [1] in order to get something meaningful. I
would like to book some time soon to solve it, but taking into account
the code freeze deadline, not sure if there is enough time to
implement, review (as this would also require changes on gnome shell),
and integrate.

And, although we get this integrated. As you say, it is not enough to
promote it as a whole a11y experience on GNOME Shell.

>    - Caribou doesn't integrate properly with GNOME3; it can't handle the
>      overview of GNOME Shell, etc. And doesn't match the design we want

Well, as Luca said on other mail, the current main purpose of Caribou
is not being a fully design-integrated keyboard on screen for
gnome-shell, but a functional pragmatic tool. Anyway it would be nice
to get Caribou fully design-integrated on gnome-shell and avoid
rewritting code for this purpose.

Anyway it is true that the others issues are the ones that makes
Caribou as discardable. AFAIK, Eitan is working on, at least, get
Caribou working.

>  Visual Alerts:
>    Not working at the moment, but probably just a Mutter bug that we need
> to fix in any case.
>  Sticky Keys:
>  Slow Keys:
>  Bounce Keys:
>  Mouse keys:
>    Not working for me in testing here with 2.91.90 gnome-settings-daemon, but
>    should work, and trivial to fix if they don't.

After a quick test, I tried to activate those, but nothing appear on
the gnome shell panel indicating that it is active.

> So, basically, our options are:
>  * Leave the menu completely as is, fix everything up as well as possible;
>    this will mean that people testing GNOME 3 may have bad experiences
>    with some of the options.

I agree, I don't like the idea of a menu with things that doesnt work.

>  * Remove the worst working options:
>     Screen Reader
>     Screen Keyboard
>     Maybe High Contrast
>    fix everything else up. This is certainly possible, but does it leave a 
>    menu that's prominent in the design but doesn't have a ton of useful stuff
>    in it.
>  * Remove the accessibility menu entirely. The functionality is still all
>    accessible through system settings, it just isn't as exposed and obvious
>    to first impressions.

And how a about maintain the menu removing all the items except the
current access to the Universal Access Menu? In this way, at least we
would maintain a easy access to a way to configure them.



API (apinheiro igalia com)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]