Re: Removing gthtml2 (was Proposed modules for 2.10 wanted NOW)

Hi Shaun:

Thanks for replying, and for pointing me to your previous post.  This is
the first time I've seen it - and I was offline for the past day or so. 
I'll reply in-line below:

On Wed, 2004-11-03 at 20:45, Shaun McCance wrote:
> On Tue, 2004-11-02 at 09:20, Bill Haneman wrote:
> > Mark McLoughlin wrote:
> > > 	I thought this had happened before now - I was confusing yelp with
> > > devhelp, though. So, for anyone else who doesn't know, 2.9.1 was the
> > > first yelp release using gecko.
> > > 
> > > 
> > >>Please DONT do this; if you use the gecko component, the help system
> > >>become inaccessible.
> > > 
> > > 
> > > 	Its an unfortunate regression in accessibility given the amount of work
> > > done on gtkhtml2 accessibility, but you would agree that its the way
> > > forward, right? You would agree that maintaining one less html renderer
> > > (and the accessibility support therein) is good, right?
> > 
> > Only when the remaining html renderer is substantially accessible.  That 
> > is not yet the case, and I don't see a committment in the GNOME 
> > community to make sure this happens for 2.10.
> Oh come on.  From my previous email[1] (which you haven't replied to):

Sorry Shaun, I didn't see it until you pointed to it again.

>     I've put a lot of work into making Yelp respect theme and font
>     settings, and it's better in that respect than it's ever been
>     before.
> When I said "a lot of work", I didn't mean "a little work, but I'll
> exaggerate to make myself look good."  From my gnome-doc-utils proposal
> on desktop-devel-list[2]:

Thanks for doing this work; it's vital work that is much appreciated.  I
am sorry that those of us in the a11y team rarely have the time to say
so.  We really do need the support of GNOME maintainers across the board
if we have any hope of succeeding in delivering an accessible desktop,
so this work counts for a lot.

>     There are a few known accessibility problems with the HTML produced
>     by the stylesheets.  These, in turn, affect accessibility for Yelp.
>     I'm firmly committed to working with our accessibility team to
>     produce the most accessible documentation system possible.
> So I'll ask again what I asked in my previous email (which, remember,
> you haven't replied to):
>     Could you tell me exactly what accessibility problems Gecko has?

I believe that (other than some stylesheet issues which you mention
above) the main issues have to do with ATK implementation.  I also am
uncertain about the current functionality of gecko's ATK implementation
when used as an embedded component; there are reports that it does work
to zero-order, but I have not been able to verify this.

Assuming that it does, or can be made to do so, the main questions

1) "what serious problems does the gecko ATK implementation have?"  and
2) "which of these problems will affect gnome-help when using the gecko
rendering engine?"

The folks in Beijung currently working on gecko/ATK in the Mozilla
context, and their QA team, are in the best position to answer the first
question.  I do know that the current ATK implementation in the Mozilla
context is currently insufficient even in the branch, and there is a
_lot_ of functionality that hasn't been merged into mozilla-trunk yet. 

The best way to answer the second question, IMO, is both to look at the
buglist from #1, and actually do some accessibility testing of
gnome-help/gecko + gnopernicus and gok.  Probably side-by-side tests
with gnome-help/gtkhtml2 would be key to understanding what regressions
there might be.

> Very few of the Gnome hackers know the accessibility infastructure as
> well as you.  I need you to tell me what needs to be done.  Otherwise,
> there's no way I can do it.

I don't have all the answers, nor do I have resources to do the testing
at the moment.  I do know that gecko-HEAD's ATK support has lots of bugs
logged against it in mozilla's bugzilla, and there is a lot of
as-yet-unintegrated work in mozilla branches.  I will do what I can to
help others understand what the help browser is expected to do, and how
to test it.  The test assertions regarding the gnome-help system in the
accessibility sanity test suite (test gnome27) may be a start:

Note that the intro to this document may give some idea of how to go
from the task-based tests in the test suite to the "assistive technology
test scenarios".  The test scenarios can be carried out with no
additional hardware other than a second mouse/pointing device.  On Linux
you will need for one pointing device to be connected to the PS/2 port
(or equivalent, such as a laptop built-in touchpad), and one connected
to a USB port.  The GNOME Accessibility Guide has some information that you probably may find
useful as well.  Unfortunately it doesn't (yet) include directions for
configuring a "non-core" input device, as required by GOK, but I believe
the GOK README does have some info about this.

I also think you would find the following document
very useful.

> Tell me what's broken, and I'll do my best to fix it.

Shaun, many thanks for this offer.  I'll give as much support as I can,
but I think I'll need your help finding as well as fixing.  As I think I
implied in my previous post, one of my main concerns about moving from
gtkhtml2 to gecko was not knowing that we had resources or commitment to
fix the accessibility regressions that inevitably accompany changes of
this sort.  Your willingness to help find and fix may make difference
here; at least, working together we should be able to assess the
gnome-help/gecko accessibility gaps better.  Without a willingness to
fix them, finding them would be of limited help.



> [1]
> [2]
> --
> Shaun
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org

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