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

Mon Jul 19 16:06:42 PDT 2010

The following is a somewhat edited extract from a recent email exchange
between myself, Joanmarie Diggs, and Alejandro Piño Iglesias.

Janina

Piñeiro writes:
> From: Joanmarie Diggs <joanmarie.diggs at gmail.com>
> 
> See comments inside.
> 
> > I hope you don't mind that I'm bringing Alejandro Piñeiro Iglesias
> > (CCed) into this discussion. I call him Alex; he's "Piñeiro" to most.
> > But I'm old-fashioned, and women just don't call guys by their surnames.
> > 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.
> 

I don't mind at all. In fact, I'm delighted.

I've added Bill Cox as a CC.

And, I'm forwarding this email, with a few comments of my own, to the
Open A11y list, as it was always the intent to have this conversation go
to that group.

> > * 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.
> 
> 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 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.

Other than Joanmarie's point below, that no access is worse than slow
access, performance is key to my mind.

> > * 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.

> > * Moving from GConf to GSettings needs to happen. It's a GNOME Goal. And
> > it is my understanding that GNOME Goals are not choices. They are
> > must-do's. Having said that, it's not really clear to me what would
> > happen if we went to the GNOME community and said "ain't gonna happen:
> > no resources." Would the GNOME Community magically cause resources to
> > appear? Would they postpone the requirement until the next release? If
> > the answer to either question is "yes," then this task strikes me as
> > being less important than addressing performance. But if the answer is
> > "no," then this would be priority number one. After all, slow access is
> > a drag; no access is not acceptable.
> 
> We were talking about that on our last gnome #a11y weekly meeting [2],
> and Mike Gorse said that he had plans to do that. Probably we should
> ask him about it.
> 
Yes, we need to track this.

> > * Testing, especially user testing, is vital. In order to achieve that,
> 
> Related with the firefox thing, and not exactly user testing, note
> that in the case of WebKitGTK+ a11y support, Mario Sanchez Prada is
> using *exclusively* at-spi2. As an outcome he was able to report (and
> fix by himself) some at-spi2 bugs.
> 
> Why I'm saying that? Because I also would include "developer
> testing". I think that a11y developers, and application developers
> worried about their own a11y support, should start to test at-spi2 in
> his development environment.
> 
This is a key issue for Open A11y and the Linux Foundation.

Just to be clear, our long term goal is to add AT-SPI to LSB. The LSB
Work Group is OK with this--we almost got there a few years ago, but
supporting both CORBA and D-Bus (our last proposal) was unacceptable.

So, now we're working on D-Bus. Once it's working to our satisfaction
we'll want to return to the LSB about getting AT-SPI added. For that to
happen, we will need tests that distributions, ISVs, etc., can certify
against.

It's also another topic for another day, but I wanted to say this here
so everyone can have context of what Open A11y is up to.

> > 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 agree.
I also.

> 
> > * CSPI has been deprecated. It is my understanding that it has been
> > deprecated due to lack of resources. The primary impact is that the
> 
> Yes, it was deprecated due lack of resources. a11y team conclude that
> on CSUN GNOME hackfest a11y meeting [3].
> 
> > 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>
> 
> 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.
> 
> Going back to the issue. As the wiki says, CSPI drop "It's not
> desirable, but there are no resources to do the work." And after
> almost 6 months, it didn't become a top-priority, so it is in the same
> state.
> 
> But, if working on performance would mean a push to CSPI, probably
> with a real funded "at-spi2 project" we can recover CSPI item.
> 
I thought we had a few more dependencies--but I could be wrong. Rather
than speculate, let's touch on this on the Open A11y telecon.

> > * KDE and QT - Will be awesome to have. I'm really looking forward to
> > it. So are the Orca users. Not top priority, however, IMHO.
> 
> There are some discussion about it on kde accessibility mailing
> lists. But unlikely that kde community would take care of it.

We'll follow up on this. I think we'll need to go into LSB.

> 
> > So in summary, what I think the prioritization should be is:
> > 
> > * Performance
> > * GConf to GSettings conversion
> > * Testing
> > * Multi-user Bus
> > * everything else
> > 
> > Alex, what's your take on the above?
> 
> Yes, I wouldn't change the order. Although I would put CSPI as the top
> one in "everything else".
> 

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.

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

Janina

> > Take care.
> > --joanie
> 
> Awesome summary, thanks
> 
> > [1] https://lists.linux-foundation.org/pipermail/accessibility-atspi/2010-June/000623.html
> [2] http://live.gnome.org/Accessibility/Minutes/20100708
> [3] http://live.gnome.org/Accessibility/GNOME3#CSPI_.28drop_for_GNOME3.29
> 
> BR
> 
> ===
> API (apinheiro at igalia.com)

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina at asterisk.rednote.net

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)