a11y readiness [was Re: On Documentation]

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]