Re: [g-a-devel] GNOME Launches Campaign for Accessibility

[Bill Cox <waywardgeek gmail com>]

Hi, Alejnandro.  GdkPixbuf is used in cell renderers, which draw cells
in tables, lists, and trees.  They are used as GUI objects, even if
they were not originally intended to be.  They are displayed by many
programs, usually as status indicators in lists, such as stars for
popularity, green check for passed, red x for failure, etc.  Adding a
text description is the simplest solution, is backwards compatible,
and makes upgrading non-accessible uses of pixbuf a one-line change in
most cases.  One other solution might be to depreciate the cell
renderer pixbuf class, and replace it with a similar class that uses
the gtk image class instead of pixbuf.  This would provide a widget
with accessible object where a text description can be attached.
However, it could be problematic in that the widget would not be part
of the widget hierarchy, and would have a lot of unused properties.
My guess is this would confuse programmers, who would simply continue
to use the old non-accessible class.  Another possible solution might
be to add an accessible object to the pixbuf class rather than a text
description.  That would enable programmers to use
atk_image_set_description() on pixbuf objects.  However, the argument
against pixbuf having a text description is that pixbuf is meant to be
a lightweight raw image data structure.  Adding a whole new object to
it rather than a property seems like a less lightweight solution,
though I don't feel this lightweight argument has merit in the first
place.

I agree with CFH that drawn objects should be required to have some
sort of description.  There could be a check in the drawing routines
that generate warning messages for objects without them.  However, as
no windowing system I've heard of does this, I don't expect it to
happen any time soon.  Instead, I think it should be possible for
users of programs to add accessible descriptions themselves, and share
them with others.  However, that's a topic for a different thread.

Bill

On 1/9/12, Piñeiro <apinheiro igalia com> wrote:
> On 01/07/2012 03:26 PM, Christian Hofstader wrote:
>>> cox: In my opinion, the separation of responsibilities is the main reason
>>> for lack of a11y progress in GTK.  If any of the wonderful people
>>> working on a11y  that we are both fans of were able to commit patches
>>> to GTK, the issues would have been resolved years ago.
>>>
>> cdh: Can Brian or someone related to Gnome Foundation explain the process
>> for getting a11y fixes upstream? As Bill says and I agree that a bunch of
>> a11y volunteers would be interested in making changes to GTK+ if they had
>> confidence that their remedies would make it into the main branch.
>
> Steps:
> 1. Report a bug on GNOME bugzilla (https://bugzilla.gnome.org/) for the
> specific project/component
> 2. Upload the patch
> 3. Project/componet developer will review the patch
> 3.1 He could find some issues, so it could require some improvements.
> a11y volunteer will require to provide an alternative patch. Go to step 2.
> 3.2 If the patch is ok, he will approve the bug. Go to step 4.
> 4. Patch is approved, and then committed on the specific
> project/component repository
> 5. On next release, that project/component will include that patch
>
>>
>> cdh: Is there a document describing the process for volunteer hackers to
>> ensure that their fixes, once approved, make it upstream?
>
> There is no document like that. Anyway, AFAIK, this is what happens in
> any free software project. Is there any document explaining when a patch
> on the linux kernel, once approved, make it upstream?
>
> Anyway, once approved in GNOME bugzilla, any patch will be upstream.
>
>>
>>
>>> cox: Because several e-mails on this topic have attacked my emotional
>>> response to my patch to pixmap objects being rejected, I want to
>>> explain my philosophy about GUI objects and a11y.  If an object is
>>> going to be displayed on the screen, I feel extremely strongly that
>>> the programmer using that object should have the opportunity to attach
>>> a text description to that object.  Not only does pixmap not allow
>>> this, but GTK uses pixmap objects in all lists, tables, and tree
>>> displays, which is why no icon in any list, table, or tree in any
>>> single GTK program says anything other than "icon".  Any programmer
>>> who takes the time to examine how GTK programs are typically written
>>> can come to any conclusion other than pixmap objects are a fundamental
>>> core object, used just about everywhere, and that the programmers
>>> using them are not to blame for not making accessible descriptions.
>>> GTK doesn't allow it.
>>>
>> cdh: I would take this a step further and say that GTK+ should not just
>> support but require text descriptions for all UI objects. Sure, a
>> programmer can put nonsense in the text description field but, as users
>> get nothing better than nonsense now, any programmers who added any text
>> descriptions whatsoever would be a win.
>>
>>
>
> For that specific bug, GTK reviewer was not against having a text
> description, just saying that he didn't agree with the specific
> implementation. FWIW GdkPixbuf is not an UI object. It is just a raw
> structure that represents an image. Then it is used by GTK object (UI
> objects) to show that image. GTK reviewer was just saying that the
> implementation should be applied in the proper place. Taking into accoun
> my previous list of steps, this is a 3.1 case.
>
> BR
>
> --
> Alejandro Piñeiro Iglesias
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>