Re: Accessibility and CSS [was: Changing Yelp to use GtkHtml1 instead of GtkHtml2]

[Alex Larsson <alexl redhat com>]

On 7 May 2002, Bill Haneman wrote:

> John said:
> ...
> 
> > So we've got a relatively straightforward technical question here:
> > 
> > Does Yelp need CSS to properly display help files? 
> > 
> > Sander's views are the only ones I care about, since he's the one trying
> > to make the whole stylesheet thing work, so I guess the answer is "no,
> > we don't need CSS".
> > 
> > Do I have this right? Is there something we're missing, like a possible
> > need for CSS to provide a11y for the help?
> 
> Actually I've received pretty clear information from the w3c's web
> accessibility guidelines folks that, in the future, CSS and DOM support
> will be required for compliance with their User Agent Guidelines,
> barring significant changes in the UAG.  It's not clear that Yelp will
> need to conform, but it's an issue for HTML/XML renderers generally.
> 
> There are three main accessibility "musts" for a help browser:
> 
> (1) It must respect system themes, in this case GTK+ RC-file themes when
> using the default engine.  That means that all test attribution like
> sizes must be relative to/with respect to the GTK+ default font.  Sander
> has been looking at doing this with stylesheets and I have agreed to
> prepare patches for gtkhtml2 to make its base text rendering sizes use
> the GTK+ RC-file font.
> 
> (2) It must support keyboard navigation, provide visible indication of
> focus on screen, and be fully usable in mouseless mode.
> 
> (3) It must support ATK interfaces, in particular AtkText and AtkImage,
> and AtkTable (if frames are used).
> 
> I believe that gtkhtml2 has significant support for (2) and (3) at this
> time and Sander and I are working on (1).  It's not clear that we can
> meet all of these requirements with gtkhtml1 in the 2.0 timeframe, so
> from an accessibility perspective I would argue strenuously against a
> change unless the gtkhtml1 team can commit to meeting these needs ASAP.

I don't understand this. I think it's pretty obvious that we just CANT USE 
GtkHTML2. It's unmaintained and broken. The "it's more work to add 
accessibility to GtkHTML1" argument is void, since it doesn't count  
the work needed (which won't happen) to make GtkHTML2 WORK AT ALL.

So, do we want an accessible, but fundamentally broken help browser?

Writing a good HTML layout engine is a lot of work. The fact that 
Evolution needs it gives us some sort of guarantee that GtkHTML1 will be 
made to work. GtkHTML2 has a nice initial codebase, and with a couple of 
manyears of work it could become a nice modern browser widget. But, since 
nobody is working on it, or plan to, it's essentially dead code, known to 
be slow and buggy.

People also argue that we're throwing out the testing we've gotten so far 
if we switch now. That is true, but it doesn't matter, since the testing 
we've gotten so far doesn't lead to bugs getting fixed. Spending time 
making GtkHTML2 accessible when we know we'll be switching to GtkHTML1 
soon makes even less sense. Especially when other apps (evo) needs 
GtkHTML1 to be accessible too.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an all-American Jewish dog-catcher with nothing left to lose. She's a 
ditzy mute barmaid from out of town. They fight crime!