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

[Willie Walker <William Walker Sun COM>]

Thanks Aaron!  

If were to summarize in one sentence:  "we agree it should be done, but
it's too hard and nobody is willing to take it on."

Darn.

I understand the Mozilla team has done a lot for accessibility (believe
me, I know it is often a thankless job), and I thank them for that.  I
wish, however, there were more resources and people committed to taking
it a step further with respect to keyboard traversal.  :-(  

Is there any creative way to get someone fired up to do this?

Will

On Fri, 2006-09-15 at 09:38 -0400, Aaron Leventhal wrote:
> 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
> >>     
> >
> >
> >   
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel