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
