Re: [g-a-devel]Support for Color in ATK

["Draghi Puterity" <mp baum de>]

Hi Peter !

see me comments after "MP:"

Draghi

----- Original Message -----
From: "Peter Korn" <korn sun com>
To: "Draghi Puterity" <mp baum de>; <Padraig Obriain sun com>; "Bill
Haneman" <Bill Haneman sun com>
Cc: <gnome-accessibility-devel gnome org>
Sent: Tuesday, January 08, 2002 8:57 AM
Subject: Re: [g-a-devel]Support for Color in ATK


> Hi guys,
>
> The accessibility of color information is a sticky issue.  When color is
used
> to indicate important things, it may well not be the "foreground" or
> "background" color, but color that was drawn there by the (generally
custom)
> widget explicitly (and also thereby not respecting user preference
settings,
> window manager settings, etc.).
>
> While in some toolkits foreground and background color information is
> available (and therefore potentially providable via the AT SPI), that (a)
> isn't always the case, and (b) is often not going to give you the
information
> you want because of usages as cited in the paragraph above.
>
> I think we can factor out the problem space into four main divisions, with
> several sub-divisions:
>
>  - Apps that use color for important info
>     1. color is standard widget usage
>         get from AccessibleState, AccessibleRole
>
>     2. color is set via foreground/background
>         a. toolkit supports this -> get from AT SPI
>         b. toolkit doesn't support this; nothing we can do
>         c. also seek from app/widget via Accessible[State|Role]
>
>     3. color is really an icon (with AccessibleIcon being valid)
>         foreground/background color doesn't matter, get via
>         Accessible[State|Role] and also AccessibleIcon
>
>     4. color is rendered by app (custom widget?)
>         a. app tries to be well behaved with Accessible[State|Role]
>         b. need to talk with X display to get individual pixels!
>
> Is there any disagreement about the problem space factoring?

MP: So there is no "legal" GTK API to set the color of a standard widget
different from the prefered fore/back colors?

 If not, it seems
> to me the only cases in which getting background/foreground color is
important
> and useful is case 2a above.  How large is this subset of scenarios?  How
much
> larger are the others?

MP: I don't know, I think it will depend on how much "discipline" can be
enforced by the toolkit's API or by the comunity. As I see it, programmers
tend to abuse the existing toolkit features because: a) some things they
want are not possible otherwise, b) they are too lazy to learn the roles
anyway and c) it's cool to break the rules ;-) .

A more general statement: from my past experience, there will always be a
"killer app" that won't play by the rules (think of MS Office and the SDM
mess under Windows). And all the blind user will want to use this app. We
will say "You can't, it is not accessible because it's not well behaved".
The users will turn to the developers, and they will say "It is accesible,
it was done by the toolkit rules. AT-SPI can get this information, they just
don't do it". So, the bottom line, if you can get something that is "pretty
legal" from the toolkit, do it or at least keep a door open for it.

>
> While getting foreground/background color info may be possible for a lot
of
> scenarios, is it a good investment in work given the above?

MP: I belive that this is a good investment if the ammount of work needed is
reasonable. But there are surely more important issues for the first release
and leave this for the next release. Until then we could hope that the apps
will enhance widget colors with app specific states. I will need to better
undestand this concept and how to present it to blind users (see the
localization issue for example).

>
>
> Regards,
>
> Peter Korn
> Sun Accessibility team
>
>
> Bill Haneman wrote:
> >
> > Draghi Puterity wrote:
> > >
> > > I think we should ask ourselves the following question:
> > >
> > > "Can I have in a well behaved GTK application a widget which has a red
> > > text/background and another widget with let's say a blue
text/background?"
> >
> > Yes, if the application uses GTK states to distinguish the widgets and
> > determine the colors.  AN application can install its own widget state
> > color set or theme, or extend an existing theme, but widget colors
> > should be based on a theme and state.
> >
> > > If the answer is yes, then I think we need widget colors, because the
blind
> > > user should be able to distinguish between them. I also don't think
that a
> > > widget color will always express a state,
> >
> > It should (see above ).  If it is colored to improve readability this
> > means that the color carries no intrinsic information and thus no state,
> > but by the same logic the color information is extraneous to the
> > non-sighted user except when communicating with sighted colleagues.
> > Remember also that colors are not fixed but depend on the theme, so even
> > sighted colleagues cannot rely on color as a verbal communication tool
> > unless they are using the same GTK theme.
> >
> > > it can be colored just to improve
> > > app readability or to offer some extra (maybe app specific state)
> > > information. A red button could mean in a given app or context
"enabled" in
> > > an other "disabled" but the difference is stil relevant for the blind
user.
> > > Or think for example at a viteotext app which could have four coloured
and
> > > unnamed buttons. Talking on a broader accessibillity scale, some apps
could
> > > use coloured widgets for iliterate users (so if SUN wants contracts
from the
> > > White House... ;-) ).
> > >
> > > I don't know the "good behaviour rules" of GTK, but if using different
> > > colors for widgets in a GTK app would make us say to the app
programmers
> > > that this is an ill-behaved app, I think they would laugh us at best.
> >
> > At the moment the official position is that such apps should use GTK
> > widget "state" for such coloring if it is at all meaningful, and that
> > apps which override GTK theme colors (that is, which provide hard-coded
> > colors for widgets rather than either getting colors directly from
> > themes or basing colors on themes) are ill-behaved.  No one has laughed
> > or challenged us on this yet, but of course this can't be enforced.
> >
> > -Bill
> >
> > > As
> > > always, I'm not aware of what is really doable in the current
time-frame and
> > > of the costs of doing it. I just wanted to present my point of view
from the
> > > blind user perspective.
> > >
> > > Draghi
> > >
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel