a11y readiness [was Re: On Documentation]

[Bill Haneman <Bill Haneman Sun COM>]

Mark said:


> 	This is similar to i18n, and to a lesser extent a11y. 
> [we have] ...for a11y, a sub-project which supports
> hackers in making their software fully accessible. We don't expect this
> stuff done upfront, but we do expect that new module maintainers be
> amenable to working with the sub-projects to get this stuff done in a
> timely manner.

I am not sure I agree with Mark's assessment of "not expecting a11y 
stuff to be done upfront" - at least, if by that one means that we 
expect to integrate projects and components into the GNOME official 
desktop without good a11y support.  Perhaps that's the been our practice 
up until now, but it can lead to very serious problems.

GNOME 2.6 has represented an accessibility regression on several fronts, 
even as the infrastructure and assistive technologies get better; that's 
not just because new GNOME components get integrated with incomplete 
accessibility support, it's because existing components regress from an 
a11y perspective as new code is integrated, and accessible old stuff 
gets deprecated and replaced with new, inaccessible stuff.  GNOME 2.8 is 
at risk in the same way.

Given that fact that every GNOME Roadmap presentation and document which 
I've seen in the past 2 years has featured accessibility prominently, I 
think we need to reconsider the current strategy.  We should either 
promise less (accessibility wise) or step up to deliver more; the 
accessibility team alone is not big enough to regression test each new 
GNOME release in advance, let alone fix the issues that appear.

It seems to me that it would be entirely reasonable for GNOME to apply a 
"must not regress accessibility" requirement to new desktop and 
developer platform components just as it expects a reasonable degree of 
internationalization for new components.  Unlike GDP and GTP, 
accessibility can't be added in from outside, even with lots of effort; 
the accessibility has to be built into the components from the inside. 
Fixing accessibility issues with new platform components is rarely 
possible without breaking API and UI freezes, so it's not practical to 
do this late in the release cycle (for instance, after a module has been 
officially accepted).

We may feel that as a community we aren't able to meet such a 
requirement, or that the need for new cool stuff in the desktop 
outweighs our desire for universal access.  But if that it the case, we 
need to re-examine what we are claiming with respect to GNOME's goals.

regards

Bill