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 > >> [email protected] > >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > >> > > > > > > > _______________________________________________ > Gnome-accessibility-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
