[Accessibility] Shoring up D-Bus Accessibility--Can we talk?

Bill Cox waywardgeek at gmail.com
Mon Jul 19 18:01:16 PDT 2010

Wow... lots to comment on in this!

On Mon, Jul 19, 2010 at 4:06 PM, Janina Sajka <janina at rednote.net> wrote:
>> > Anyhoo.... Alex seems to have found his way into the position of
>> > unofficial/de facto GNOME a11y lead, plus he's got a much better handle
>> > on the big picture than I do.

Does this mean I can bug Alex for GTK+ a11y enhancements?  If so,
here's a patch...


>> > * Performance (Key Events, Re-entrancy) seems to be improved somewhat.
>> > The last time I talked with Mike Gorse about it, however, there was
>> > still a performance loss compared to the current AT-SPI. Speaking just
>> > from the perspective of Orca: We need to make Orca more performant,
>> > independent of the move to AT-SPI2. Therefore, anything that makes Orca
>> > even less performant is, in my mind, very high priority. But that might
>> > not be the view of the full community.

I often ask on the Vinux list, "What are the current biggest problems
we should fix?"  Currently, the answers seem to be:

#1 - Speed of Orca with Firefox
#2 - Speed of Orca with Thunderbird, as well as some bug fixes
#3 - Speed of Orca with OpenOffice, as well as a number of bug fixes

This is why I was looking into DBus speed.  I'm just beginning to work
on understanding all the various contributors to delay.  If anyone has
some tips, I'd appreciate it!  By the way, I'm thrilled to finally be
at the point of worrying about performance.  For a long time, Vinux
users had even bigger complaints.  As Joanie said, slow is better than
not working at all.

>> Reading Mike Gorse mail [1], this seems that he has an idea that
>> involves use old cspi code. This means that there are a possibility
>> that this task help the CSPI one (see following CSPI item).

I haven't read his e-mail, but I doubt that we're seeing significant
delays because of Python bindings.  Compared to 200 microseconds, how
much delay can Python add for one method call?  Of course, I'm mostly
ignorant of the real sources of delay, so I don't really know what I'm
talking about.

> I am very keen to have our ATs and underlying messaging performant. I
> have always been of the opinion that computers should wait on users, and
> not the other way around. It has troubled me from the start that
> performance was at risk in our move from CORBA to D-Bus.

Amen!  It amazes me that a 2 gigahertz computer can have delays in
reading a web page that my brain can sense, given that neurons operate
on about a 10KHz bandwidth.

Anyway, I estimate that on my 2 gigahertz laptop, every DBus method
call takes 200 microseconds to pass two messages, while simpler IPC
programs run about 20X that fast.  I read the DBus spec, and other
than "requirements" to do a lot of checking that I'm tempted not to
do, the spec itself seems fairly efficient.  One idea might be to have
a "turbo" mode which when enabled causes messages to bypass the
existing dbus code and go directly to a simpler, faster interface that
runs 10X faster.  Another idea might be to propagate the dbus filters
to the client applications so that each application can determine
which other applications need a message, so that only direct messages
are sent, and so that messages without listeners are never sent.

>> > * Firefox is reportedly fixed. (And were it not, I'd consider that to be
>> > something the Mozilla guys should be helping look into. But that's
>> > another topic for another time. <smile>)
>> So this means that Firefox doesn't crash using at-spi2 as Mark
>> reported, but I suppose that there are still work to done
>> there. Right?
> Yes, another topic--but important. Let me just ask bluntly, did Mozilla
> accept patches upstream? Or are we still relying on Orca
> workarounds?
> If the latter, then I think we need to make an issue of
> this. I understand they've lost people--but we all have. We're
> adjusting. They need to not lose us as they adjust.

I've had a working patch to a critical Firefox navigation bug, with a
working mochitest test uploaded for weeks:


Urgency at Mozilla to include critical Linux a11y patches is very low.
 I think we should have our own patched version of Firefox that we
test against.  I don't know how Orca regressions can pass with Firefox
3.6 without the patch above.

>> > it needs to be easy for users to get AT-SPI2 as well as to switch
>> > between it and the current AT-SPI. A pre-requisite to that would be the
>> > items under Installation and Packaging, namely options must be
>> > documented and, ideally, packages provided by distros. Thus I'd consider
>> > Installation and Packaging to be the next priority. To be honest, at
>> > least in terms of what Orca needs, when the call for testing is put out
>> > and the ability to perform the testing is made easy, the community comes
>> > through. Often within minutes. Truly amazes me.... Anyway, the point
>> > being: While user testing "vital" I wouldn't call it a "priority" in and
>> > of itself, because it will just happen -- as soon as the packaging and
>> > documentation are done.

I also agree.  Vinux users are eager to try out the new at-spi2 system
and Gnome 3.  There will be plenty of testers when you're ready to say

>> > current solutions for voice recognition for GNOME will no longer work
>> > unless they are converted to Python or implement D-Bus directly. I think
>> > the GNOME a11y team needs to decide what the priority of CSPI is. The
>> > question has been raised before (in the context of voice recognition),
>> > but no conclusion has been reached. Perhaps the possibility of funding
>> > will help elicit a response. <smile>

People who can't type are currently poorly served by *-nix. There's
just no good open-source voice recognition engine worth using in a
large-vocabulary continuous recognition mode.  I'm recommending Simon,
because it works with small vocabularies and has a powerful command
creating and sharing facility.  I think we could make programming by
voice with Simon practical, and we might attract some of the many
excellent programmers who can't type due to RSI injuries.  These poor
guys are not well served by companies like Nuance, and there's room
for real advances.  I believe it should be easier to beat Nuance at
programming by voice productivity with low quality speech recognition,
than it will be beating Freedom Scientific.

>> About voice recognition, both "GNOME Voice Control" and "VEDICS"
>> (programs to control gnome desktop using voice) are using deprecated
>> CSPI bindings, so those projects are in fact in a dangerous state.
>> Anecdote: When I raised that, VEDICS developers answer was that they
>> started VEDICS project just some months ago, and they want to finish
>> it, and then they will have time *to port it to python*. IMHO, this
>> kind of "once the scope and implementation of a program is defined,
>> port that to a (totally) different language would be easy" sentences
>> are just pure (noob) optimism and likely to fail.

Both projects have terrible recognition problems, and neither are
currently of any real use, in my opinion.  I think we can live for a
while without the ability to speak menus, buttons, and links, and that
we should instead focus on helping people who are able to point a
mouse.  What they need, IMO, is commands that do stuff similar to what
Simon and Vocola do.  It should mostly be possible with our poor
quality recognition engines.  It's enough to do a lot, like writing
poorly commented C programs, for example.  It would look just like all
the other Linux code!

> I'm also keen to solve the root access issue in a generic way. To me
> it's insufficient that it's solved in one particular distro. Distros can
> also change their minds and drop things. We need a wider, Linux-wide,
> solutions that all the distros must package. I acknowledge and applaud
> Bill's work creating Vinux. But, I think we can't allow the mainstream
> distros therefor to wash their hands of any responsibility to
> accessibility support.

I agree!  The problem seems to be bugs in gksu.  I don't know why gksu
stopped being a simple GTK+ wrapper around sudo, and instead morphed
into an independent monster of massive complexity.  Given that we're
talking about basic security, it's nuts to hav two independent
systems.  There must have been a motive, but my preferred solution is
to force gksu back to being what it was intended to be.  We could
rewrite it with a simple Python script using policy kit, and I know of
no reason not to do so.  As is, I've got a simple bash shell in Vinux,
and a task on our list to rewrite it.  Maybe we could track down the
gksu devs and try to understand why they need all the complexity, and
maybe have them fix their code?

As for upstream washing their hands of accessibility support, I think
that's what Vinux is here to fix.  Luke at Ubuntu is working very
closely with us now days.  I'd say he's doing more good technical work
than me, and he's leveraging everything he can for Ubuntu.  I don't
know how to get other major distros interested, but the guys who are:
Open Solaris, Debian, Arch, Ubuntu, Knoppix... you know the distros.
These guys are getting fixes and improvements faster than before, I
believe in part because of Vinux.  Hopefully the non-a11y friendly
distros will be shamed into caring a bit more as their competitors
pull ahead.

> Adding one more, related point to this list, there are still distros not
> supporting accessible login (GDM) out of the box. And, I believe we
> still have issues around the audio environment, especially when we
> consider that we need users to be able to use console as well as the
> desktop environments

It's so nice to hear someone supporting console use!  There seems to
be a push to eliminate them entirely, but most blind Vinux users seem
to spend most of their time in the consoles.  In a year or so, I'm
hoping we can get Gnome/Orca working so well that the blind will give
up console use, but we've got a ton of work to get there.

As for audio environment, I assume you mean PulseAudio.  I think blind
users are still steaming mad over that whole debacle.  Even Ubuntu
Maverick will have trouble shipping with a usable console screen
reader, unless someone like Luke catches fire and writes a ton of
solid user-session code.  Until that happens, the only popular distros
for the blind are likely to be Solaris, Knoppix, Vinux, old versions
of popular distros like Ubuntu and Fedora, and seriously hacked up
machines where users purge pulseaudio altogether.


More information about the Accessibility mailing list