Re: Text alternatives and GtkPixbuf [Was: GNOME Launches Campaign for Accessibility]

[Bill Cox <waywardgeek gmail com>]

Sorry, Benjamin.  I'll try to keep it straight.  Here's the problem
with pixbuf that makes solving this issue hard without adding an
accessible description directly to pixbuf.  GTK does not build widgets
for cells in lists, tables, and trees.  Instead, you register a
callback function that is responsible for drawing cells.  This is a
major improvement in efficiency vs building a widget for every cell,
but the result is you don't have a widget allocated in memory where
you can add a text description.  The object used for drawing icons in
lists, tables, and trees is GtkCellRendererPixbuf:

http://www.gnu.org/software/guile-gnome/docs/gtk/html/GtkCellRendererPixbuf.html

Programmers simply attach a pixbuf object to their model, and it's
displayed automagically.  This method is used in many GTK
applications.  The problem is there is nowhere on the pixbuf object to
add a text description.  This is why I can't contact the authors of
the various programs which have icons in lists that don't talk and
request that they add descriptions.  They would have to do major
changes to their code to get it to work.  Specifically, they'd have to
somehow draw images in their lists without using the GTK renderer
designed for this purpose.  Most GTK programmers would have no idea
how to even start on such a task (including me!).  Here's the pixbuf
documentation:

http://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html

There are already 9 properties on pixbuf, so a text description would
just raise this to 10.  Also, the description of pixbuf is "The
GdkPixbuf structure contains information that describes an image in
memory. "  Not having a text description seems like an oversight, one
that is easily corrected.  When I added one, I was able to fix three
popular GTK applications so that users could hear how many stars a app
was rated when installing software, and they could hear the status in
Synaptic so they could know if a package was installed or not.  In
each case, adding a text description took only one extra line of code
per icon.  We tested these apps in Vinux for several months, without
any problems.  However, we decided that we did not want to maintain
non-standard patches to GTK.  The goal in Vinux is to help improve
Linux accessibility, not maintain accessible custom versions of code
that only run in Vinux.

In short, adding the text description to pixbuf is very clearly the
right solution.  No other solution has been proposed for good reason.
We'd have to change the cell renderer interface otherwise, and all the
existing applications out there would need major changes.  That level
of disruption just isn't going to be accepted.

This is a major accessibility problem in Gnome.  The community offered
a simple solution, and tested it.  It's about as small a change to the
code base as any patch can be, and would significantly improve the
lives of Orca users.  The fact that Gnome seems incapable of adopting
fixes like this tells me that there is a major problem with the Gnome
organization.  A11y is clearly a high priority for Gnome at the
highest levels, yet Gnome is not capable of fixing a critical a11y bug
the code it manages, even when the community submits a simple tested
patch.  When a GTK programmer says on a community bug report "I don't
think this is the right approach," managers need to understand that
translates to "I don't want to do work my boss didn't specifically
request, and a11y patches from the community aren't on the list."  So,
how do we get issues like this on the list?

Bill