Re: Forming an Accessibility Steering Committee
- From: Brian Cameron <Brian Cameron Sun COM>
- To: Willie Walker <William Walker Sun COM>
- Cc: gnome-accessibility-list gnome org
- Subject: Re: Forming an Accessibility Steering Committee
- Date: Wed, 19 Dec 2007 17:38:00 -0600
Willie:
We also need to coordinate efforts across GNOME. For example: what's
going on with metacity's composite manger and gnome-mag? What new
widgets are in GTK+ and do they need GAIL support? Is this new
application "X" accessible?
Yes, it would be nice to have a matrix on the GAP Wiki which shows
which applications have been tested, and which ones have problems.
There's definitely various aspects of coverage that need to be done, and
I suspect the dimensions of this matrix might go beyond 2.
Yes, it might make sense for the table to have columns for bugs of
different priority, as well as break down into different columns for
different accessibility use case (magnifier, text-to-speech, on-screen
keyboard, etc.)
It is also
something we can work on once the committee is formed. Brian, do you
have a list of all the end user apps that are part of GNOME? That would
be a good start.
A good place to start would be the list of applications in the GNOME
platform and desktop:
ftp://ftp.gnome.org/pub/gnome/platform/2.21/sources/
ftp://ftp.gnome.org/pub/gnome/desktop/2.21/2.21.3/sources/
Not all distros ship all these applications, but we could perhaps focus
on the more popular programs first. Or perhaps, more simply, focus
on applications that we know have a11y issues first.
> We also must include other non-GNOME apps of great
> relevance, such as Firefox, Thunderbird, OOo, Compiz, etc.
Right. There are also a fair number of SourceForge modules that are
commonly used with GNOME, such as ekiga, gthumb, gtkam, pidgin, and
gphoto2. Also there is gimp.
Yes, prioritizing a11y bugs is a huge job. It would be great if we
could get some volunteers to help make sure that bugs have proper
keywords and are appropriately prioritized and highlighted. Perhaps we
need a place on the Wiki where the most shameful bugs are listed in the
hopes that this will help encourage their resolution.
We've done the 'shame' thing with GNOME bugs affecting Orca and had
limited success. People just respond better to compliments,
recognition, and thank yous than shame. IMO, the best way to get
languishing bugs addressed is to pleasantly, but aggressively, pursue
them and let the people know the impact the bug has on the usability of
their product. This is something that someone with good program
management skills could do well in.
My suggestion that we use the Wiki to highlight serious bugs was not
really geared towards shaming maintainers or modules. We all know a11y
issues can be complicated and not all module maintainers are engaged
with a11y requirements. As you say, this will benefit more from
gentle persuasion.
Instead, I think the primary value in having a Wiki that cataloged the
highest priority issues across the desktop would be:
- To give people a high level overview of how well a11y works
- To help give volunteers an idea of what the serious bugs are, so
that if a person wants to volunteer to fix bugs, this would be a
good place to get an understanding of what bugs need fixing.
The problem with using bugzilla to "pleasently, but aggressively,
pursue bugs" is that not all volunteers know how to effectively
use bugzilla to find the ones that really need the most attention.
Figuring our the highest priority a11y bugs via bugzilla would be
a hard task even for someone who is involved and engaged with GNOME
a11y development. That's why I suggest highlighting them somewhere
else, such as on a Wiki.
We also need a nice logo. :-)
You should find out. You should be able to point him to this email
discussion to demonstrate the community interest. I think with your
leadership experience in GNOME a11y, you would be especially valuable
to have engaged in this sort of project.
My boss is a great guy and I also value Sun's commitment to
accessibility. I've actually felt guilty going to Xmas parties this
year telling people how much I like my job. I think the only resistance
I would receive is a question of the opportunity cost with respect to
Orca. Time spent on this means time spent away from Orca. But, Orca is
maturing and there's a great community of users and developers behind
it. In addition, work on this would still have a very positive impact
on Orca and GNOME a11y across the board.
I agree.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]