Piñeiro | 1 Mar 17:30 2011

Announcing ATK/AT-SPI Hackfest


This will come as no surprise to many of you at this point, as we
already talked about it during the weekly accessibility meetings, but
I would like to officially announce that we are having an ATK Hackfest
in May.

For the new people, ATK is the accessibility toolkit. Right now the
main and more extensive implementation is GAIL (GNOME Accessibility
Implementation Library), although it is also used in Clutter (Cally),
Java (via the Java Access Wrapper), and others. AT-SPI is the
accessibility service provider interface. Accessibility tools "uses"
AT-SPI in order to interact with the applications. ATK works as the
common language that target applications uses to expose themselves to
AT-SPI, so a deep change on ATK would require an update also in
AT-SPI. In the same way, we would like to get a one-to-one relation
between the interfaces on ATK and AT-SPI as much as possible.

Applications and toolkits do not all implement ATK consistently. This
has a negative impact on the assistive technologies ability to provide
a consistent cross-application user experience. Even in applications
and toolkits in which the ATK implementation is complete, the
information obtained from a single event and/or object is not always
sufficient for an AT client to proceed immediately; instead it is
often necessary to perform further queries and make decisions based on
heuristics rather than concrete data. This has a negative impact on
both performance and reliability.

Accessibility team has come to the conclusion that this is time to
improve on ATK no matters if that means an API break. The primary goal
is to take what we have learned from years of ATK/AT-SPI and make
(Continue reading)

Matthias Clasen | 2 Mar 16:40 2011
Picon

A11y themes in GNOME3

Hey,

I've spent some time yesterday working on the HighContrast.
LowContrast and Inverse themes. I thought I should post a quick note
about a11y themes in GNOME 3, so people know what things currently
work, what things don't, and where things live.

The Contrast control in the universal access panel sets both the gtk
theme and the icon theme to the same value, the options being
HighContrast, LowContrast and HighContrastInverse. The high contrast
switch in the universal access menu of the shell does the same (just
for HighContrast, obviously), as does the toggle-contrast keybinding
that is implemented in g-s-d. The meta-theme information in the
/usr/share/themes/≤theme>/index.theme files _is ignored_. When
metacity/mutter move to gsettings, we might consider adding the
metacity theme to the set of components that are set for Contrast. And
maybe it makes sense to tie the cursor and icon size to the text size
control, not sure. But for now, these theme components are not
affected at all, so if you want to need a different cursor theme or
size, you have to go directly to gsettings.

The a11y themes for gtk2 used to live in gnome-themes. They did not
really have matching icon themes and instead relied on setting stock
icons in rc files. Carlos has added a11y themes for gtk3 to
gnome-theme-standards last week. Yesterday, I have added gtk2 rc files
there too, and also created matching icon themes reusing icons found
in gnome-themes, mostly. This means that the three a11y themes that
are available from the universal access panel should work reasonably
for both gtk2 and gtk3. The icon themes are far from complete; help in
improving their coverage would be greatly appreciated.
(Continue reading)

Owen Taylor | 7 Mar 20:25 2011
Picon

Possible UI freeze break: acccessibility menu in panel

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. 
   https://mail.gnome.org/archives/gnome-accessibility-devel/2011-March/msg00001.html
 Zoom: Works well
 Large Text: Works pretty well
   (shell patch: https://bugzilla.gnome.org/show_bug.cgi?id=636868))

 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.
   - 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
     https://live.gnome.org/GnomeShell/Design/Whiteboards/ScreenKeyboard

 Visual Alerts:
   Not working at the moment, but probably just a Mutter bug that we need
(Continue reading)

Peter Korn | 7 Mar 20:37 2011
Picon

Re: Possible UI freeze break: acccessibility menu in panel

Owen, gang,

In GNOME 2.2x, there is a typical place for assistive technologies to live: the Universal Access menu.  Some distros surface this by default, while with others the user has to explicitly make it visible via the Main Menu editor.  Similar to which apps are on the by-default-at-the-top-of-the-screen panel. 

Why not do the same here?  I think this level of prominence will make sense for some distros, particularly as more of the functionality improves.  So I would suggestion option #2, with the ability for distros/users to add/remove items from this menu, and to show/hide this menu by default.  And... that nearly all of the builds prior to the final one continue to have this icon prominent.  I dare say the prominence has helped surface these issues (would you have noticed that StickyKeys is broken had the option to turn it on not been so prominent?).


Peter

On 3/7/2011 11:25 AM, Owen Taylor wrote:
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. https://mail.gnome.org/archives/gnome-accessibility-devel/2011-March/msg00001.html Zoom: Works well Large Text: Works pretty well (shell patch: https://bugzilla.gnome.org/show_bug.cgi?id=636868)) 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. - 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 https://live.gnome.org/GnomeShell/Design/Whiteboards/ScreenKeyboard Visual Alerts: Not working at the moment, but probably just a Mutter bug that we need https://bugzilla.gnome.org/show_bug.cgi?id=639765eed 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. 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. * 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. Jon McCann's request is to do the last one. I don't really have an opinion on the matter myself. - Owen _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel <at> gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

--

Peter Korn | Accessibility Principal
Phone: +1 650 5069522
500 Oracle Parkway | Redwood City, CA 94065
Oracle is committed to developing practices and products that help protect the environment
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Piñeiro | 7 Mar 21:59 2011

Re: Possible UI freeze break: acccessibility menu in panel

From: Peter Korn <peter.korn <at> oracle.com>

> In GNOME 2.2x, there is a typical place for assistive technologies to
> live: the Universal Access menu.  Some distros surface this by

The last entry on this menu is and access to the Universal Access menu.

BR

===
API (apinheiro <at> igalia.com)
Piñeiro | 7 Mar 22:06 2011

Re: Possible UI freeze break: acccessibility menu in panel

From: Owen Taylor <otaylor <at> 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. 
>    https://mail.gnome.org/archives/gnome-accessibility-devel/2011-March/msg00001.html

More about gnome shell and themes: https://bugzilla.gnome.org/show_bug.cgi?id=618888

>  Zoom: Works well
>  Large Text: Works pretty well
>    (shell patch: https://bugzilla.gnome.org/show_bug.cgi?id=636868))
> 
>  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
>      https://live.gnome.org/GnomeShell/Design/Whiteboards/ScreenKeyboard

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
>    https://bugzilla.gnome.org/show_bug.cgi?id=639765eed 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.

BR

[1] https://bugzilla.gnome.org/show_bug.cgi?id=640057

===
API (apinheiro <at> igalia.com)
Matthias Clasen | 7 Mar 22:18 2011
Picon

Re: Possible UI freeze break: acccessibility menu in panel

On Mon, Mar 7, 2011 at 2:25 PM, Owen Taylor <otaylor <at> redhat.com> wrote:

> 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.
>
>  * 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.
>
> Jon McCann's request is to do the last one. I don't really have an opinion
> on the matter myself.

Removing things from the menu does not make much sense to me. After
all, they are still available from the UA panel. So the bad experience
can still be had.

Removing the menu altogether seems even worse, after it has figured
prominently in every shell screenshot for the last year or so.

I think we should make try to make things work as well as we can for
3.0 and promise to do better for 3.2. And yes, that will mean making
compromises and accepting an on-screen keyboard that may not follow
the design vision to the pixel.

Matthias
Matthias Clasen | 7 Mar 22:33 2011
Picon

Re: Possible UI freeze break: acccessibility menu in panel

On Mon, Mar 7, 2011 at 4:31 PM, William Jon McCann
<william.jon.mccann <at> gmail.com> wrote:

>
>> I think we should make try to make things work as well as we can for
>> 3.0 and promise to do better for 3.2. And yes, that will mean making
>> compromises and accepting an on-screen keyboard that may not follow
>> the design vision to the pixel.
>
> I can't disagree with this attitude more strongly.  It has nothing to
> do with pixel precision.  Caribou in particular is nothing like the
> (incomplete) designs we have for on screen keyboard.
>
> Bottom line: universal access in the shell is a 3.2 feature - provided
> the work gets done to meet our minimum requirements of stability,
> performance, and design.

And you get to make the rules for what is good enough for disabled
users of GNOME ? I couldn't agree with this attitude more strongly.
Matthias Clasen | 7 Mar 22:35 2011
Picon

Re: Possible UI freeze break: acccessibility menu in panel

On Mon, Mar 7, 2011 at 4:33 PM, Matthias Clasen
<matthias.clasen <at> gmail.com> wrote:
> On Mon, Mar 7, 2011 at 4:31 PM, William Jon McCann
> <william.jon.mccann <at> gmail.com> wrote:
>

>
> And you get to make the rules for what is good enough for disabled
> users of GNOME ? I couldn't agree with this attitude more strongly.

And of course, when I say agree, I mean disagree...
Matthias Clasen | 7 Mar 22:41 2011
Picon

Re: Possible UI freeze break: acccessibility menu in panel

On Mon, Mar 7, 2011 at 4:31 PM, William Jon McCann
<william.jon.mccann <at> gmail.com> wrote:

> Bottom line: universal access in the shell is a 3.2 feature - provided
> the work gets done to meet our minimum requirements of stability,
> performance, and design.

Also, this is the first time I ever hear universal access being
demoted to a 3.2 feature. Another unilateral decision or yours ?

Gmane