Re: Proposal: enable accessibility by default for GNOME

["Luis Villa" <luis tieguy org>]

And login times? Impacted, not impacted? Application performance?
(Granted this last one is probably hard to get at, but it still seems
important to measure- we are, after all, considering something here
that could impact every single application.)

Tangentially, I'm disappointed with the 'a user can spend 10 seconds
to just turn it off' school of thought- that is not how we are
supposed to do things around here. We *fix* problems instead of
requiring users to somehow magically find the right set of options to
fix it for themselves. We know it'll take far longer than 10 seconds
to discover how to turn it off and stop paying the price. In fact, we
know most users will never discover how to do it. They'll just assume
GNOME is slow, if this does in fact slow GNOME down. So to say
'they'll just spend 10 seconds to turn it off' is not a GNOME-y way of
thinking at all.

Luis

On Thu, Jul 31, 2008 at 3:29 AM, Mark Doffman
<mark doffman codethink co uk> wrote:
> Hi everyone,
>
> Rob Taylor wrote:
>>
>> Hmm, my take here is that the current AT-SPI is possibly a little too
>> heavy to enable by default. I'd suggest we look at enabling a11y by default
>> when the new AT-SPI DBus is ready (2.26 at current estimations)
>
> I'll take my best guess about what happens when a11y is turned on:
>
> 1. The atspi registry daemon needs to be running.
>
> 'top' has the data memory usage at 550kb and the code size at 40kb. The
> cpu utilization is exactly zero.
>
> 2. All gtk applications are going to load accessibility modules.
>
> I'm not sure which modules are going to be loaded. I would say libgail
> and libatk-bridge (including libspi). Perhaps not gail, isn't it now
> included in gtk? Are liborbit and libbonobo loaded for other reasons on
> gtk_init?
>
> So the test program:
>
> int main(int argc, char* argv[])
> {
>        gtk_init(&argc, &argv);
>        gtk_main();
> }
>
> It uses 15464kb virtual memory and 596kb of data when accessibility is
> turned on.
>
> When accessibility is turned off it uses 13660kb of total virtual memory and
> 456kb of data.
>
> So there is 150kb odd of data initializing the atk-bridge and libspi.
>
> 3. Accessible objects are created for gtk widgets / other UI elements.
>
> Finding how an ATK object is created feels very much like jumping down a
> rabbit hole. In the end though Gail objects and Bonobo servants are only
> created on-demand. This means that there will be very little additional
> memory usage if accessibility is turned on but not accessed.
>
> This is the important part really. Bonobo servants might be very large, and
> this, I think, is where ORBit/Bonobo gets its reputation for being heavy.
> However, if a11y goes unused there shouldn't be any created.
>
>>
>> I've cc'd Mark Doffman for his imput as he's probably got the most
>> experience profiling current AT-SPI behaviour.
>>
>> Rob
>>
>> Willie Walker wrote:
>>>
>>> The way accessibility support works is that GTK+ loads accessibility
>>> modules (gail and atk-bridge) if it detects that accessibility support is
>>> enabled.
>>>
>>> If accessibility support is not enabled when an application starts, I
>>> don't believe there is a way to indicate to a running GTK+ application to go
>>> ahead and load the accessibility modules retroactively.  As such, one needs
>>> to quit running applications and restart them in order for changes to the
>>> accessibility setting to take effect.
>>>
>>> The current user experience is very bad and kind of a Catch 22 situation:
>>> in order to enable accessibility, they often need to use assisitve
>>> technologies.  In order to use assisitve technologies, they often need
>>> accessibility enabled.  So, what we do now is tell users to find some way to
>>> enable accessibility for their session, then log out and log back in.  It's
>>> really embarrassing as far as I'm concerned.
>>>
>>> I'll see if we can dig up some metrics on the costs of enabling a11y. If
>>> anyone has good suggestions for how to do this and how to get numbers that
>>> people will trust, I'd like to hear them.  :-)  Even if the numbers  are not
>>> favorable, however, I think I'd still argue to turn a11y on by default: it's
>>> far easier for someone without a disability to turn it off than it is for a
>>> person with a disability to turn it on.
>>>
>>> Will
>>>
>>> Mathias Hasselmann wrote:
>>>>
>>>> Am Mittwoch, den 30.07.2008, 13:11 -0400 schrieb Willie Walker:
>>>>>
>>>>> Alexander Jones wrote:
>>>>>  > Isn't this a distro decision?
>>>>>
>>>>> Ultimately, I guess the value for any gconf setting in
>>>>> schemas/desktop_gnome_interface.schemas can be whatever a distro wants it to
>>>>> be.  What I'm proposing, however, is that the default value that we choose
>>>>> for GNOME is that accessibility will be enabled by default. If distros want
>>>>> to revert this back to disabling accessibility, I guess it would be their
>>>>> choice.
>>>>
>>>> What is the motivation for enabling accessibility by default?
>
> Anecdotally....
> I have had 'assistive technologies' turned on now for a year. I am not a
>  user. My fairly modest computer (IBM T43 512mb of ram) hasn't had any
> difficulties. I haven't seen any detrimental effect.
>
> Having assistive technologies turned off by default is a real hassle for
> those who need to use it. Having it turned on by default doesn't have much
> of an effect. For those who want to optimize their desktop turning it off
> takes exactly 10 seconds.
>
>>>>
>>>> For the regular user (not handicapped, not a testing engineer) the
>>>> accessibility bridge just consumes resources without providing any
>>>> benefit - AFAIKS.
>>>>
>>>> Why can't accessibility be activated on demand? With D-Bus activation
>>>> we have the platform for enabling such features on demand.
>>>>
>>>> Ciao,
>>>> Mathias
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> desktop-devel-list mailing list
>>>> desktop-devel-list gnome org
>>>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>>
>>> _______________________________________________
>>> desktop-devel-list mailing list
>>> desktop-devel-list gnome org
>>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>>
>
> Thanks
>
> Mark
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list