Re: a11y readiness [was Re: On Documentation]

Mark McLoughlin wrote:
On Fri, 2004-07-23 at 11:54, Bill Haneman wrote:
	(How did I know you'd take issue with this?)

I did infer that it depends on what exactly you meant by it. I think we're mostly in agreement.

	You'll not that I was saying we shouldn't expect every new module to be
*fully* accessible before being accepted into the desktop.

I wasn't saying "fully accessible either.

	I guess my point is that you can only place a certain number of
reasonable requirements on new modules. You cannot require that every
module be fully translated, documented or accessible before considering
its addition to the desktop.

Sure. Where I think we run into trouble is when the net effect is significant regression. Unfortunately, we had some significant cases of this in 2.6, and we'll have more if we are not more proactive. By "we" I mean all of d-d-l, not just the fulltime a11y hackers.

You can only expect a certain amount from
any new module - mostly because you cannot expect to have the author of
new modules to have the skills or time to meet those requirements. If
these authors have made a good effort towards these goals and could only
be reasonably expected to make further progress on those goals with the
help of members of the l10n docs and a11y sub-projects, then its time
we give these people a break and get their cool new stuff in GNOME.

Sure, if the end result is better for GNOME generally. In a resource limited situation though, we have to decide where to draw the lines, and what degree of existing accessibility we're willing to sacrifice. As for entirely new stuff, I would be happy with an "N + 1" policy towards integration that postponed full-featured accessibility until the "next" GNOME release for new modules. A "try to fix in *.1" policy would be even better, but as I said, we have freeze issues to deal with that sometimes prevent fixes in dot releases.

However, if the new stuff replaces some old (and possibly otherwise broken) stuff that was reasonably accessible, then we have a different kind of problem. Do you agree that we shouldn't deprecate/replace accessible stuff until the replacement is mostly accessible? We would object to this kind of breakage in other aspects of the desktop; why not accessibility?[1]



[1] If the answer is, "accessibility isn't as important", then we need to rethink the messages we're giving publicly.

[2] (below): Mostly I think it's a problem with developers not _testing_ accessibility. We do have much better accessibility testing docs now, and testing accessibility need not be the deep mystery it once was:


P.S - I've a good idea where this conversation will go:

 <billh> | hackers shouldn't need the support of the GAP to make their apps accessible
<markmc> | yes, but unfortunately they do
 <billh> | but we have docs !
<markmc> | yes, but its still H A R D - keynav is hard enough in itself
 <billh> | but !
<markmc> | yes, but ... :-)))

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