GNOME Bugzilla – Bug 614121
Shell Toolkit requires additional a11y support
Last modified: 2010-08-11 18:24:58 UTC
Created attachment 157284 [details] [review] a11y support on shell toolkit infrastructure Some of the Shell Toolkit widgets will require additional a11y support, extending the basic one provided by Cally. I haven't made a exact analysis, but you can take StLabel as a example. It doesn't expose the text (label not exposing his text is obviously not really useful from a11y POV). We can use this bug as a rant-place to decide how to do that, although I attach a patch with one solution. It is basically what I made with hildon-desktop. As the shell toolkit is integrated directly on gnome-shell, not a different library, I just added a new directory (called stally) where implement that. Once compiled, it is not added to gnome-shell binaries, a new module is created, to be installed on the clutter module directory. I also added a new option on configure, so compile the a11y support for the shell toolkit is optional. One of the main reasons is avoid add a hard cally dependency here. You only need cally if you want to compile Shell Toolkit a11y support. Anyway, although you use this options, it checks if cally is installed or not, to avoid a fail if it is not installed. This has the advantage that, apart of this infrastructure, the a11y support is implemented in a different directory, not interfering with main gnome-shell source or with any plan to became a independent library or re-merge with mx. Some questions that could arise: * Why cally is required? Why not define this new objects as AtkGObjects and extend the proper cally class using run-time inheritance [1]? Because it would be a really pain. Run-time inheritance is a good hack on Gtk+ world if you have an application that defines one or two custom widgets. But not if you are defining a new widget stack, as HAIL has proved (You can't access to the virtual methods defined in the "parent toolkit", you can't define virtual methods on your own, etc) * Why don't implement the a11y support in the same object code (StLabel) as GtkIconView does? First, it would mean modify directly shell toolkit code. Sometimes being isolated is a good thing, to not interfere with other developers. Second, on Gtk it is possible because you have the virtual method gtk_widget_get_accessible, so you can registry the proper atk factory here if required. We don't have it in clutter. It could be solved adding this method, or just defining atk_gobject_accessible_for_object [2] as virtual. I would prefer the latter, although it would be more difficult to achieve. Without this, you need to registry the factory is some initialization code, so the module init call is the proper place to do that. CCing Emmanuele Bassi and Li Yuan due the last question. Sorry for this really long bug description. [1] http://projects.gnome.org/accessibility/talks/GUAD3C/making-apps-accessible/anonymous-inheritance-1.html [2] http://library.gnome.org/devel/atk/stable/AtkGObjectAccessible.html
Created attachment 157285 [details] [review] Example of StLabel a11y support, This patch depends on the previous one. It just add the a11y support implementation for StLabel. Really basic, it only expose the text of the internal ClutterText as the name. It also add the common atk factory template (as used in GAIL, HAIL, Cally)
me personal gut feeling is that we should stop considering a11y as a module and more an integral part of a toolkit implementation - Clutter included. Alejandro: what would be needed in Clutter core to actually implement what Cally does as a module? would we depend on a set of D-Bus interfaces? a dependency on GDBus for Clutter (on x11) would not be a problem for me. another issue is: we've seen that ATK is tailored to GDK (e.g.: event structures); should we take advantage of the API break in GTK+ to get rid of that and make ATK toolkit agnostic?
(In reply to comment #0) > defining atk_gobject_accessible_for_object [2] as virtual. I would prefer the > latter, although it would be more difficult to achieve. Forget this idea, I was too sleepy. (In reply to comment #2) > me personal gut feeling is that we should stop considering a11y as a module and > more an integral part of a toolkit implementation - Clutter included. If my memory doesn't fail me, the reason of the isolated GAIL was that the accessibility support couldn't arrive on time Good to hear > Alejandro: what would be needed in Clutter core to actually implement what > Cally does as a module? would we depend on a set of D-Bus interfaces? a > dependency on GDBus for Clutter (on x11) would not be a problem for me. No, we don't depend in DBUS interfaces at all, Cally works with the current CORBAthis is the advantage about work > > another issue is: we've seen that ATK is tailored to GDK (e.g.: event > structures); should we take advantage of the API break in GTK+ to get rid of > that and make ATK toolkit agnostic?
Sorry, the previous comment was committed before be complete, sometimes writing on a couch add collateral issues. > If my memory doesn't fail me, the reason of the isolated GAIL was that the > accessibility support couldn't arrive on time Good to hear that the accessibility support couldn't arrive on time to a Gtk+ release. But not sure. Anyway good to hear this interest. > > Alejandro: what would be needed in Clutter core to actually implement what > > Cally does as a module? would we depend on a set of D-Bus interfaces? a > > dependency on GDBus for Clutter (on x11) would not be a problem for me. > > No, we don't depend in DBUS interfaces at all, Cally works with the current > CORBAthis is the advantage about work Cally works fine with the current CORBA at-spi and the new DBUS at-spi one, AFAIK. This is the advantage of just work with abstract classes (ATK). All the CORBA/DBUS details are implemented on the atk-bridge. About what Clutter requires, as far as I remember, on the Boston Summit you didn't like too much the idea of have two different objects, the widget and the accessible object. So, the straightforward idea could just re-think AtkObject, and instead of a real object, became that an interface. So ClutterActor would be in fact a AtkObject. *But*, take into account that have specialized accessibility objects offer some extra flexibility that can't be achieve in the other way. For example, it allow to expose accessibility objects without a real widget related. Some of the elements of GAIL are not related to real GtkWidgets, like the flyweight objects used on the treeview [1]. GailTreeView implements AtkTable and expose each cell as another Atk object. And AFAIK, on JAVA applications, the JAVA widget hierarchy is not the same that the ATK object hierarchy you get. In the same way, it would also allow to not expose some objects if not required. For example: in this StLabel. Has sense have an Label object, exposing the text, and have a ClutterText child having the same text? It shouldn't be enough to just expose StLabel? (Note: just an example, not final implementation). Anyway, it shouldn't be a problem to just move Cally source to Clutter. The example would be what it was made on GtkIconView. All the process done in the module initialization (the factory initialization, and more important, the root object) could be done on the clutter-init (although I still fear the mixed environment gtk-clutter). It would be also good to have this equivalent to gtk_widget_get_accessible on clutter. > > another issue is: we've seen that ATK is tailored to GDK (e.g.: event > > structures); should we take advantage of the API break in GTK+ to get rid of > > that and make ATK toolkit agnostic? This is a good question, moreover taking into account that right now it is used by JAVA applications as well. If I had have done my homework before, this question would have arisen just before the GNOME accessibility hackfest, instead on the last day, with the people re-packaging the luggage. I will talk with the last survivors, and send a mail to the gnome-accessibility-devel [1] http://projects.gnome.org/accessibility/talks/GUAD3C/making-apps-accessible/flyweights.html
Created attachment 159779 [details] [review] Optional patch using features not implemented in Clutter If patches on these clutter bugs [1][2] were applied, it would not be required to have a isolated module to implement the accessibility support on St. This patch implements the a11y support for StLabel using a modified clutter with these patches (and some other a11y related) applied, so the two previous patches would not be required. [1] http://bugzilla.o-hand.com/show_bug.cgi?id=2070 [2] http://bugzilla.o-hand.com/show_bug.cgi?id=2077
Just one comment, probably Thomas Wood would be also interested in this last patch, as he commented time ago that he is interested in provide a11y support for MX. As far as I see this patch is almost-directly applicable to MX.
Comment on attachment 157284 [details] [review] a11y support on shell toolkit infrastructure cally is merging into clutter
Comment on attachment 157285 [details] [review] Example of StLabel a11y support, cally is merging into clutter
Well I didn't set those patches as obsolete because as I said, attachment 159779 [details] [review] is based in a clutter feature not applied yet. Anyway, I suppose that this is correct, as it is the desired one to implement it.
Note: Clutter bug [1] and cally bug [2] impeding this feature were applied today. Clutter bug is included in the last Clutter release 1.3.2 Anyway, I couldn't test it properly (or 612599), as running gnome-shell ends in a signal 11. It also happens with the master as well. I will try to solve this issue and test this patch again during these days. [1] http://bugzilla.openedhand.com/show_bug.cgi?id=2070 [2] http://bugzilla.openedhand.com/show_bug.cgi?id=2077
This bug was created with the intention of start the basic infrasctructure of a different st accessibility library ala cally. On the situation this bug was created, as explained on the description, this was the way to go (IMHO). Anyway, after all the events and a11y infrastructure changes on clutter, and now that gnome shell has moved to clutter 1.4 this is not true anymore. And although we could use this bug as a metabug of any ST widgets that requires extra a11y support, I think that this would be confusing, and it is not worth, as any a11y lack on a individual ST object can be tracked individually. So, I will close this bug, and creates a different one with the StLabel problem (BTW: the patch in this bug attached is outdated, I will upload a different one in this new bug).