Re: [g-a-devel] New docs up: "Mozilla Support for Linux/UNIX Assistive Technology Developers"

[Aaron Leventhal <aaron moonset net>]

Will, first let me apologize for the long essay. I dislike 
reading them
myself :) But, this is a complicated issue.

I don't think it's very easy for just Firefox to support the 
keyboard
proposal. My advice is still "avoid this". If you care for 
the details
on why or want to debate it, read on ....

The 3 ways I can think of supporting that keyboard proposal 
at all all
have problems.

1) A XUL extension (current example exists -- Fire Vox)
/Strength: /can do lots of cool settings and UI features in 
addition.
Could do something HPR-like.
/Weakness/: only works with Firefox, not with Yelp or 
anything that
builds Gecko in. Gecko is a component of Eclipse, and can 
easily be
added to any app.  Doesn't work with plugins.

2) An XPCOM startup component (current example exists -- 
SeaMonkey's
nsTypeAheadFind extension or "find as you type")
/Strength:/ can work with any Gecko, even if no XUL 
involved. Can be
done in JavaScript or C++.
/Weakness: /No guarantee you'd get community approval to 
have it built
in. In fact, I'd be surprised if you got it. One reason 
Firefox was
created was because Seamonkey was too considered too fat. 
Every new
prompt is fought for in Firefox. Perf/bloat reasons aside, 
no one wants
to have a redundant component -- they will tell you there is 
no sense
creating some new built-in component just because it is too 
hard to fix
the old one.
Okay, if not built-in, you could just use a JS component 
which would
avoid any binary compatibility issues. If it's in the
[bindir]/components directory it will just work, but could 
I'm not sure
how to do the right thing for proper versioning, 
installation and
uninstallation. I think there's a way to put it outside of that
directory and call something in the Mozilla directory to 
register it,
but you'd have to ask an XPCOM expert. Seems like a 
headache, but
doable. Still not "out of the box though", and still doesn't 
work with
plug-ins, but you can support all apps and are free to 
design it.

3) Fix Mozilla's caret browsing
/Strength: /built-into every install
/Weakness/: no one wants to work on it, brittle code, it may be
difficult to get all the proposal features in so that 
everyone's
satisfied (remember the 1000 emails last time this was 
discussed).
Touches core layout code, and hard to get the multiple level 
of reviews
required for each touchy change. Easy to make regressions 
that affect
basic editing. I don't know anyone who is up to this task, 
sorry!
Personally I think someone needs to own that code, and I 
will push for
that when I can.

General problems with any caret browsing soluton:
a) Plug-ins. Home Page Reader had to solve this by bundling 
a separate
MSAA screen reader called MDR. This is possibly the worst 
problem. Even
if some of the plugins support full keynav I'm skeptical 
that it won't
be inconsistent with caret browsing.
b) Dealing with static text such as list bullets and ALT text.
c) Dealing with some form controls will be a challenge -- 
e.g. comboboxes.
d) Dealing with non-HTML content types will be a challenge 
(DHTML and
even XUL can be in content)

As far as bulding it in (#3). There is a lot of cross over 
in key
navigation needs, but IMO screen reader users need more than 
the built
in keyboard navigation  Screen reader users want to 
efficiently move
through document structures without accidentally entering 
information in
forms. The thinking about where to move is usually less visual
(obviously). They also want to be able to move character by 
character
through any text, including alt text and list bullets. I 
also don't see
exactly the same needs from sighted non-mouse users. I'm 
sure someone
will correct me on this :/

Yes, we should fix the problems that are there in the 
built-in caret nav
and continue to make it better. This would be useful for a 
lot of
people, and should get done, but it's not going happen 
easily because of
problems with the code itself. Unfortunately, even if it 
does happen, it
will take longer than we're willing to wait, it will not go 
as far as we
want, and be difficult to change.

Just in case anyone wonders, I'm not at all a bottleneck 
keeping better
keyboard navigation out of Firefox. I recently gave 
ownership of that
module over to Mozilla, because I'm too busy improving core
accessibility API support to handle much else. That said, 
anything that
involves touching core Mozilla keyboard code or any kind of 
new built-in
component will be a major nightmare. There are those who 
think it's a
question of technical ability, and that they can do it 
better so it's no
problem .... I wish you good luck :) Yee've been warned.

- Aaron

Willie Walker wrote:
> Hi Aaron:
>
> Thanks for sending this on.  Look like good work.  In the keyboard
> section, I notice there's a link to the following:
>
>    http://www.mozilla.org/support/firefox/keyboard
>
> One thing that I think is very important to include is keyboard
> traversal and caret navigation of the web content itself.  There's a
> proposal for this, which may or may not be up-to-date:
>
>    http://www.mozilla.org/access/keyboard/proposal
>
> If Firefox were to support this proposal (or an update form of it), I
> think it would be very useful to a large population: screen readers
> wouldn't need to define their own navigation model, people with physical
> impairments (and people like me who don't like using the mouse) would
> have a supported model for navigating and doing cut/paste operations,
> etc.
>
> Thanks!
>
> Will
>
> On Wed, 2006-09-13 at 00:47 -0400, Aaron Leventhal wrote:
>   
> > This new document describes the current state of Mozilla's support for 
> > AT-SPI, on experimental trunk builds:
> > http://www.mozilla.org/access/unix/atspi-support
> >
> > It's a work-in-progress. I plan to keep it up-to-date as we make 
> > changes. Feedback is welcome. Let me know if you want more items 
> > clarified or added to the "To Do" section after the table of contents.
> >
> > Eventually I'll get this up on a wiki as well.
> >
> > - Aaron
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >     
>
>
>