Re: help with data on webkit accessibility

[Joanmarie Diggs <joanmarie diggs gmail com>]

On Tue, 2010-02-23 at 20:19 +0200, Xan Lopez wrote:

> OK, so any of the missing caret browsing issues actually prevents the
> app from working at all?

Yup. Startling, isn't it? <huge grin>

Okay, all kidding aside.... Basically, there are several things going on
here:

1. The accessibility work that had been done is WebKitGtk already was
awesome, but sufficiently different from what we see in other Gtk+ apps
that quite a bit of custom scripting would be needed in Orca in order to
cause Orca to present WebKitGtk content. In addition, without fixes for
the remaining caret-navigation issues, we'd likely have to implement our
own caret navigation model. This tends to be not performant and at times
flakey. :-(

2. There are some things we cannot script around in Orca, namely the
bugs which are still open and listed as blocking bug 25531:

* If an AtkRole is not implemented, Orca cannot discern what that object
is, let alone present that object and the user's interaction with it
correctly.

* If we have no idea where content is on the screen (i.e. the character
and range extents), Orca cannot piece together a line's worth of content
(which is a hack to begin with) or enable the user to "flat review" it.

* If we have no idea if an object is focused or not, it's at best a
guess whether or not events from that object should be presented --
assuming events from that object are even being emitted.

* The accessible table hierarchy is truly borked....

3. Shaun said that he wouldn't migrate Yelp to WebKitGtk until the
accessibility issues had been addressed. (Thanks Shaun!!)

With all this in mind, I had to decide if I should cobble together an
interim script in Orca -- to support a version of Yelp which in theory
users wouldn't be seeing -- which would cause some content to be
presented correctly, some content to be presented incorrectly/oddly, and
some content to not be presented at all.  Or should I try to become
familiar with WebKitGtk internals and contribute patches to fix bugs and
make what WebKitGtk presents more inline with other Gtk+ apps? Given
that Yelp would still (officially) be using Gecko, I went with the
latter. And I honestly do believe that when GNOME 3.0 rolls around, and
Yelp is accessible *and* content in Epiphany is accessible *and*
accessing this content via Orca is more reliable and more performant
than what we've been able to do w.r.t. Gecko, it will have been worth
it.

Having said that.... Because of the decision which I made, there is no
Orca script in place for WebKitGtk content at the moment. This means
that unless WebKitGtk behaves 100% like a standard Gtk+ app -- which it
doesn't, and which includes fixing the bugs I mentioned in an earlier
message -- an Orca user is not going to have much success. :-(

So the question now is where do we go from here? Do I spend my time
hacking something together in Orca which only kinda sorta works to
address the fact that Debian and Ubuntu have decided to do their own
thing? Or do I spend my time trying to work on the WebKitGtk side of
things? I'm sure my tone conveys my opinion. ;-) However, if the
community consensus is that I should try to get *something* working on
the Orca side of things, I will do my very best.

(And yes, Xan, I know. I've been away from WebKit for the past several
weeks. There were some significant changes -- and regressions -- in
Firefox 3.6 a11y which had many Orca users very unhappy. So I got
diverted temporarily to sort all of that out. :-( )

--joanie