GNOME Accessibility on by default, and Firefox
David Bolter
Firefox (and other apps) provides accessibility support conditionally.
This means that on GNOME it always runs a little slower for everyone,
and eats up extra resources. I wonder if we could have GNOME
accessibility turned on, but a separate setting that Firefox can check
on GNOME to tell it if the at-spi is actually being used by a client?
This matters because people outside our circle make choices about
browsers based on performance... and I think we want the most accessible
one to win ;)
cheers,
David
Mario Lang
> Hi all,
>
> Firefox (and other apps) provides accessibility support conditionally.
> This means that on GNOME it always runs a little slower for everyone,
> and eats up extra resources. I wonder if we could have GNOME
> accessibility turned on, but a separate setting that Firefox can check
> on GNOME to tell it if the at-spi is actually being used by a client?
This feels broken. What if I have accessibility enabled,
my screen reader not started, but firefox already open?
By enabling accessibility, I told the system already that I will want to use
it. But with such a sneaky check, my screen reader would not be able
to access firefox since it has decided to not use AT-SPI...
Or did I miss something in this mail. It reads like
the check you propose is kind of automatic, if it were a permanent gconf
setting, it would just duplicate the Accessibility-enabled setting, wouldn't
it?
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang/k...@db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
Aaron Leventhal
"enable a11y" flag in the OS. Just the fact that something asks us for
an accessible object wakes us up. We get a WM_GETOBJECT event -- and
before that a11y is not loaded.
We really need lazy instantiation like that under Gnome. If the AT is
loaded and starts asking us for objects, then we can wake up.
- Aaron
T.V Raman
Performance matters to everyone, and the last thing you want as
someone who depends on accessibility is for the rest of the world
to perceive accessibility as something that slows things down for
everyone else.
David Bolter writes:
> Hi all,
>
> Firefox (and other apps) provides accessibility support conditionally.
> This means that on GNOME it always runs a little slower for everyone,
> and eats up extra resources. I wonder if we could have GNOME
> accessibility turned on, but a separate setting that Firefox can check
> on GNOME to tell it if the at-spi is actually being used by a client?
>
> This matters because people outside our circle make choices about
> browsers based on performance... and I think we want the most accessible
> one to win ;)
>
> cheers,
> David
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
--
Best Regards,
--raman
Title: Research Scientist
Email: ra...@google.com
WWW: http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk: ra...@google.com, tv.ra...@gmail.com
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
David Bolter
Replying to a message from Aaron which didn't have the lists cc'ed.
As Steve has brought up separately, this might indeed fit into the D-BUS
AT-SPI migration work. It doesn't seem terribly complex to add this
small thing that will have nice benefit (like what T.V. points out).
@Will Walker, we could maybe touch on this Monday night at 10 ;)
Are there any objections to all this?
cheers,
David
Aaron Leventhal wrote:
> In Firefox, there's a lot of code that doesn't need to run, and a lot
> of objects don't need to be created, when a11y isn't needed.
>
> Please, add lazy instantiation for accessibility. Would it fit to do
> this in the D-BUS AT-SPI migration project?
>
> - Aaron
>
>
> On 10/22/2008 8:35 PM, David Bolter wrote:
>> This is a common pattern. I hear it is also true for other things in FF
>> like dom mutation events.... only fire if there is a listener... makes a
>> lot of sense.
>>
>> A tree should only fall in the forest if someone is listening.<grin>
>>
>> D
Willie Walker
There are a lot of things to think about here. From the internals point
of view, we can think about the following:
1) The accessibility gconf setting: this says whether or not
accessibility has been requested for the session. Right now, this
tends to be used by GTK+ just to say whether or not to load the
accessibility modules and start the AT-SPI registry. We've been trying
for a long time to not require this setting and just always have the
support turned "on". But, there are performance and stability issues
that prevent us from doing this, some of which might be addressed by
making things more dynamic. BTW, I'm not sure about the details of
what the Gecko implementation does, but it would surprise me if it
*always* loaded the accessibility modules regardless of the gconf
setting.
2) ATK and the ATK bridge: the ATK is a utility toolkit for use by
applications and graphical toolkits to create an accessible
representation of widgets: ATK peers are created for
application/toolkit widgets and ATK events are issued for
application/toolkit events. The bridge provides the communication with
the "outside world." That is, the bridge is the thing that currently
speaks CORBA and which we are moving to D-Bus. Note that ATK and the
ATK bridge are not required for an application to participate in the
AT-SPI infrastructure; they merely make it easier to do so. So, GTK+,
OOo, and Gecko all use the ATK and ATK bridge. Java, on the other
hand, currently has its own bridge and speaks CORBA directly (I've
argued that Java should use ATK via JNI to help normalize things
somewhat and make it less dependent upon the AT-SPI transport).
3) The AT-SPI registry. This provides the rendezvous mechanism between
applications and assistive technologies. When an application starts,
it lets the registry know it exists so that assistive technologies can
discover it. An application also issues events to the registry, which
then delivers them to assistive technologies. When an assistive
technology starts, it lets the registry know the event types it is
interested in. Like the ATK bridge, the communication with the
registry is dependent upon the IPC mechanism being used (i.e., CORBA or
D-Bus).
4) GAIL: this provides the accessibility implementation for GTK+,
creating ATK peers for GTK+ widgets and causing ATK events to be
issued. It is designed to loaded as a GTK+ module at GTK+
initialization time and is currently not designed to be
unloaded/reloaded over the course of an application's lifetime.
Modifying it to be more dynamic might be rather difficult, and this is
independent of the IPC mechanism in use. That is, I don't believe its
behavior matters whether we use CORBA or D-Bus.
From the assistive technology point of view, we can think of the
following:
1) Assistive technologies that mostly examine object hierarchies. GOK
tends to be this type of assistive technology. Accerciser fits into
this category as well. These kinds of ATs might work with the "just
wakes up" model, especially if one queries from the top of the object
hierarchy down. However, *something* needs to already be awake so that
an assistive technology can discover the top level application object
in the first place.
2) Assistive technologies that mostly listen for events. Orca tends to
fit into this category. I believe GOK also needs to listen for events,
however, so it knows where to enter text and which UI needs to be
grabbed. These kinds of assistive technologies might be more difficult
to support the "just wakes up" model since they tend to depend upon
receiving events from the application in order to learn that an
application exists.
Given these, I'm not sure it's really feasible to completely shut off
accessibility in an application and dynamically turn it on when an
assistive technology appears. That is, I think something probably
needs to live in the application to at least support a rendezvous with
an assistive technology. I also believe the main performance issues we
face are the ATK peering of objects and event notification: we don't
want unnecessary ATK peers to be created and we don't want unnecessary
events to be issued. As such, I think we at least need the ability for
assistive technologies to discover applications that are already
running and to be notified when new applications start. From there, we
could investigate generating ATK peers and issuing ATK events on an "on
demand" basis.
So...to make a long story short, I'd guess most of the work needed is
independent of CORBA/D-Bus and would live in the AT-SPI implementation
for the toolkit (e.g., GAIL). Li Yuan would be a good person to help
us understand the scope of this problem.
Will
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-access...@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Aaron Leventhal
<snip>
BTW, I'm not sure about the details of what the Gecko
> implementation does, but it would surprise me if it *always* loaded the
> accessibility modules regardless of the gconf setting.
Afaik we do just use the gconf setting, which is the problem. Then we
start creating accessible objects, firing extra events, doing extra
processing for DOM mutations, lalala. What other check should we use
before turning it on?
>
<snip>
> However, *something* needs to already be awake so that an assistive
> technology can discover the top level application object in the first
> place.
In Firefox, on Windows, the main system event loop is awake before a11y
ever is.
Any time any app asks for even the root accessible object for a given
window, that window receives a signal. This happens no matter what type
of AT is doing the asking -- the "mostly looking at objects" or "mostly
listening to events" doesn't effect anything. Either way, something in
each AT is causing an accessible object to be requested even before we
start firing a11y events.
- Aaron