Re: Bitmap, Pixmap, Image and Pixbuf madness

[Paolo Molaro <lupus ximian com>]

On 02/22/01 Bill.Haneman wrote:
> > Is this GtkImage-specific, or would you maybe want labels on other
> > widgets as well?
[...]
> Well, we don't want to impose undue burden on developers or
> unnecessary redundancy.  We *do* need a means of obtaining labels 
> for all widgets that have a "visible acive identity" (e.g. not 
> GtkHBox but buttons, menuitems, labels, icons).  But in many cases
> there is a property that maps nicely to that concept already.
> 
> Ideally an app should have the option of setting such
> a property explicitly on *any* widget, in support of accessibility.
> In that setting, one can set (and subsequently get) the
> "accessible-label" property.

What we need here is a standardization of the names of the properties
that are useful for accessibility. A basic set could be:

"object-label"          Short name
"object-description"    Longer description (like in tooltips)

There is no real need for a different API for this, g_object_set_data()
works fine. Once the names are standardized, a screen reader can
easily make use of them in an automatic way. These properties
are not needed for all the widgets, though it should be possible
to set them on all of them. It's a must to have them in GtkImage, 
for example.
As an example, currently in gspeech there is a way to traverse
the interface and describe it to the user. For each widget type
there is something like this in a configuration file:

description "GtkWindow" {
        "A window titled: "; arg "title";
}

A GtkImage could easily be described with:

description "GtkImage" {
        "A "; arg "object-label"; " icon";
}

This way a "Cancel" icon in a button can provide the info to
the blind user even if there isn't a "visible" label in it.
This works very well, because it doesn't require custom code
to access the widget internals: all the info is obtained with
the standard GtkObject interface and is easily customizable without
recompiling the module. Also, it doesn't require the module to "know"
a widget type in advance. An application that uses a custom widget
can install a special gspeechrc file that describes it and provides
audible cues for it.

The other important point is that the toolkit should automatically
set these properties (they can be overridden later by the programmer, 
anyway) for things like stock icons where the toolkit knows the
meaning of the icons. This is very important, because programmers are 
lazy and usually don't understand accessibility anyway, so the toolkit
should help them getting things right without too much hassles.

> However there is a case to be made that a text label would be
> useful for images in many contexts anyway.  Deciding whether to
> provide only an "accessibility API" for setting such a property,
> or whether it is something that logically belongs as an explicit
> property of the widget, which is leveraged in the "accessibility"
> environment, is a judgement call.  I think that in the case of
> GtkImage one could make a case for inclusion on the grounds that
> it would be generally useful.  For other widgets it may be that
> only in environments where "alternate access" is required does
> a "label" property make sense.

My take is that cues for accessibility should be always "available"
in the toolkit if possible: it's a lost battle requiring all the
application programmers to understand the needs of disabled people.
And they should be enabled to use the existing applications as much
as possible for many reasons (I understand some people will need
special applications, but blind people for example only need them for
some special domain like web browsing).
That said, there is the need for a standard _additional_ API to enable
the advanced use of some applications. If that should look like the
Java Accessibility API is up for debate and I'll wait for your
proposal for more comments.

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better