On May 12, 2011, at 5:25 AM, Piñeiro wrote: > On 05/11/2011 02:57 PM, Benjamin Otte wrote: > > Well most of the paragraphs were already answered by Brian, but I would like > to add a comment here.What concerns me a lot is that there is only very few > applications > >> that actually make use of this huge abstraction layer that is AT-SPI. >> I'm often thinking that we would have less code to maintain if we >> indeed wrote Orca code once for every toolkit we target Orca at >> instead of having to maintain a big ATK interface for every toolkit. >> (And the same for the other few applications that have accessibility >> requirements.) But of course I have no idea if that is actually true, > Well, there are some issues with this proposal: > * It is true that right now the AT more mature and maintained is Orca, but > we still have other AT tools, like Caribou, Dasher (if it migrates to > libatspi), MouseTrap/OpenGazer, Gnome Shell magnifier (Joseph is planning to > use some AT-SPI features). > * And although that would be true, I think that our target is "GNOME being > accessible", and provide a proper framework to do that. Just providing > support to Screen Readers are limited. > * In fact, improving the a11y general support would allow to create new ATs > easily. > * As you said, one of the current problems on the ATK-toolkit relation is > that the implementor requires to know both in order to do a good work here. > But with this proposal you are just moving from "need to know about an > abstract accessibility toolkit and an specific toolkit" to "need to know > about screen readers and an specific toolkit". Screen readers can be tricky. > * A lot of people working on those toolkits already know about abstract > accessibility toolkits. IE: LibreOffice and Gecko has also support for IA2. > Most of the people that are already implementing support for IA2 are also > implementing ATK support. > >> I just wouldn't rule it out from the start like you seem to do. > > Well, sorry if thats what you extracted from my comments. It is clear that > current accessibility status is not good enough. Thats a fact. And we all are > open to proposals to solve that. I was just trying to discuss your proposals > in a constructive way. Sorry if I failed at that. > >> What remains is that we have a problem: The AT code in GTK is so bad >> that it is off by default and nobody is in sight that wants to fix it. >> And that is bad. > > Well, just a comment here. As Brian said one of the reason is that a lot of > effort these years were used on the at-spi IPC switch. During those years we > were in a situation were nobody put a lot of effort on at-spi as it was using > an deprecated technology, and at-spi2 was in a "work in progress" status. > Mike Gorse was starting to try to solve the just on the last iterations. (And > DBUS is still, in general, less performant that CORBA). > > Anyway, one of the big problems in performance preventing to having by > default the a11y on is related to the treeview. Specifically the > "adding/removing a lot of rows on the model means a performance penalty" [1]. > As Li said a11y treeview implementation is really complex because the lacking > way to expose the internal information of the treeview. I hope that this > gail-to-gtk move could help to improve this, and mainly, simplify > gailtreeview implementation. Right now it is mostly an gtktreeview > replication.
I would like to inject into this discussion the point that however a11y is implemented there need to be hooks to integrate it with the native a11y features of all platforms that Gtk supports, not just Linux. It rather misses the point of a11y to force users who depend upon it to use an a11y tool for the Gtk applications on their systems different from the one provided by the OS. Regards, John Ralls _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
