Re: a11y readiness [was Re: On Documentation]

[Bill Haneman <Bill Haneman Sun COM>]

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]

regards

Bill

[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:

http://developer.gnome.org/projects/gap/sanity-testing/index.html
http://developer.gnome.org/projects/gap/testing/index.html

> Cheers,
> Mark.
>
> 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 ... :-)))