Re: 2.4 Proposed Modules - 2 weeks left

[Peter Korn <peter korn sun com>]

Hi Havoc,

Havoc Pennington wrote:
> 
> On Tue, May 06, 2003 at 04:05:42PM +0100, Bill Haneman wrote:
> > Accessibility support is part of the "readiness" equation.  I did not
> > say we "could not ship anything without accessibility", though I
> > personally do think that we should not include inaccessible components
> > in the GNOME official desktop, just as we are reluctant to bundle GUI
> > apps that don't use GTK+ or otherwise are not very GNOME-like, without a
> > compelling reason.  Otherwise all the usual criteria for inclusion in
> > the GEP could be discarded using the same logic.
> 
> The readiness criteria should be "architecture and maintainers
> a11y-friendly" not "all a11y bugs fixed." Though certainly if we're
> comparing two alternatives, finished a11y in one is a positive point
> (that may outweigh or be outweighed by other points); but in this case
> we aren't comparing alternatives, unless you are advocating that we
> include Mozilla.

Can you provide a more detailed definition of "architecture and maintainers
a11y-friendly"?  

For example, does this mean:

 a) supports the desktop themeing engine and the [high|low] contrast
    and large print themes - though there may be bugs

and
 
 b) uses exclusively widgets that are completely operable from the 
    keyboard - though there may be bugs

and

 c) uses exclusively widgets that support the AT-SPI (via ATK or 
    whatever) - though there may be bugs


Or are you suggesting that it means "there are no fundamental barriers to
supporting theming, keyboard operability, and the AT-SPI, but we simply
haven't gotten around to doing much work there"?  

Or something else?

> ...
>
> If we do include epiphany, the harms are:
> 
>  - we can't say "everything we ship is 100% accessible"
> 
> That's just a marketing bullet point, because "we don't have an
> accessible browser" is going to be a true statement whether we say we
> are 100% accessible or not. The user experience either way is "no
> accessible browser" (well, "you have to use Mozilla"). We should not
> be holding back technical progress and hurting developers and users so
> we can have a better marketing claim. I assure you "cool new browser"
> is a better marketing claim anyway...
> 
> What's best for moving the technology forward and getting it out to
> users? That's what matters.
> 
> Not to be melodramatic, but the software industry is a treadmill;
> stagnation is death.

I think the real question here is are we prepared to add to the GNOME 2
desktop a major application with very important functionality that is
substantially inaccessible, and perhaps further without a commited roadmap
to becoming substantially (if not necessarily 100%) accessible in a specific
and fairly short term timescale?

Do we not have a variety of buckets into which to put "GNOME" applications
(things like fifth toe, etc.)?  Is there a reasonable distinction to be made
in terms of accessibility for bucket criteria going forward?  (e.g. we want
app foo in GNOME, but app foo is substantially inaccessible now and so it
will go into fifth toe; at such time as it is substantially accessible it
will be considered for inclusion in the gnome desktop)

In no way am I suggesting that we shouldn't move technology forward as
rapidly as we can.  But we cannot seriously commit to having an accessible
desktop if we are prepared to add things - and especially things large and
substantial - that are substantially inaccessible.


Regards,


Peter Korn
Sun Accessibility team