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

[Peter Korn <korn sun com>]

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?  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?

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


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