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

[Piñeiro <apinheiro igalia com>]

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