Re: 2.4 Proposed Modules - 2 weeks left

[Peter Korn <peter korn sun com>]

Hi Havoc,

> On Tue, May 06, 2003 at 10:27:03AM -0700, Peter Korn wrote:
> > 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"?
> 
> That sounds good.

I still don't think I understand this criteria very well.

What would constitute a "fundamental barrier to supporting theming, keyboard
operability, and the AT-SPI"?  Is there anything short of a maintainer's
statement that they don't care about this and will not implement it that in
your mind would constitute this fundamental barrier?  After all, as we've
seen with the Mozilla and StarOffice/OpenOffice.org effort, things that look
wildly different from GTK (and also from Java) can be made accessible, with
sufficient staffing and time.  But in the absense of a corporation like Sun
stepping forward and making a large investment in it, these apps would very
likely never become accessible.

Are we as a community happy to accept a world where there can be lots of
accepted (and welcomed) innovation but that said innovation will only be
accessible if someone with deep pockets invests in making it so?  Or do we
want to have a stronger statement about what all apps *should* do?  What is
the minimum level of an "active accessibility plan" that we should expect
from an app that becomes part of the GNOME desktop?

> > 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?
> 
> My answer to that question is yes.
> 
> If we want committed roadmaps, then we have to pay somebody.
> 
> We are time-based because feature-based means you have to either a)
> pay somebody or b) be prepared to delay indefinitely. As we don't have
> those options, we are time based.
> 
> You are advocating the "delay indefinitely" option for the browser -
> because the nature of free software is that we cannot know that any
> *specific* feature will happen at any given time, only that *some
> features* will happen. Blocking the browser on a specific feature is
> b), delay indefinitely.
> 
> Delay indefinitely mean users don't get the work that *did* happen.

We already delay indefinitely for quality, right?  There can be lots of
innovation in a buggy program that crashes all the time.  And we would not
want that program to be part of the GNOME desktop until those problems were
fixed, right?  Would we not also delay indefinitely for significant build
ugliness?  If folks cannot generally 'make install' the thing, it's not
ready to be part of the GNOME desktop, right?

Is there a generally understood criteria that outlines what is necessary for
something to be part of fifth toe? of the GNOME desktop? of core GNOME?

Also, I'm not suggesting that we somehow prevent a user from getting any
particular program they want, or that we say that no collection of GNOME
software can contain any particular application.  Rather, I'm trying to suss
out the definition of what being part of the "GNOME desktop" means, and
whether that definition includes (or should include) any statement
whatsoever about accessibility.


I am NOT advocating the "delay indefinitely" option (from the GNOME desktop)
specifically for Epiphany.  I don't know enough about it, and specifically I
don't know enough about how much work is needed to make it a good
accessibility citizen.  Rather, I'm trying to understand and help hash out
principles and general requirements (which would then be applied to Epiphany
and any other candidate for the GNOME desktop, GNOME core, and fifth toe).

> > 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.
> 
> We can't commit upstream GNOME to being 100% accessible, because that
> is a feature-based criterion, and we cannot pay people, and we cannot
> delay indefinitely.
> 
> What we can do is be friendly to a11y - we can be sure that *if*
> someone does the work, they can make the code shipped accessible.

There are two clear positions here: "100% accessible" and "0% accessible
with no roadmap for getting to 100%".  But I think the meat of the
discussion is in the area in between.  I would not claim that anything is
ever "100% accessible" - that is a theoretical place that we can perhaps get
within epsilon of (for another delta of work).  But we will never reach it. 
I think a much more appropriate standard is "substantially accessible" -
that most things work pretty well for users with any given disability.

> This is exactly how we treat i18n and every other feature.

Generally, on average, how long would you say it takes a new app in the
GNOME desktop to support I18N after it becomes part of the desktop (not
localized into all languages mind you, but simply to have all strings and
user interface elements localizable)?  


Thanks,


Peter Korn
Sun Accessibility team