2008/11/7 Willie Walker <[EMAIL PROTECTED]>: > It took a very long time to get accessibility support added to Gecko, > and it involved a lot of collaborative work between the assistive > technology and Gecko developers. There is a *lot* of testing that needs > to be done to make sure the implementation really is doing the right > thing.
I appreciate the impressive amount of work that has gone into Mozilla in that court. We stand on the shoulders of those giants wherever we use ATK's web-oriented capabilities and the ecosystem built around them. > >> The basics are already here and first class web accessibility is >> around the corner. It will happen sooner if we work together. > > This is great, and again, your work is appreciated. Hopefully all we > have really had here is a very unfortunate breakdown of communication. It sounds that way. I'm excited to see your positive response and think good things will happen in very short order. > >> Let me know if you will have the time to study the current state of >> the ATK and caret navigation patches (the ones in the bug tracker are >> a couple of weeks old) and we can start working together today and get >> this synced up to WebKit SVN within the week! > > I will try to set aside some time each day in the coming weeks to take a > look. The main things I'll look for initially are the ability to get to > the accessible content, the caret navigation, and the delivery of caret > movement events. Vincent has already offered to act as a go-between if communication breaks down but it sounds like we'll be working closely anyway if you can put aside that time. So, let's get some solid action items here: 1) Get caret navigation looked at and landed. 1.b) Add back support to Yelp and Epiphany (only a few lines of code). 1.c) Consider binding it to F7 via a configurable GtkBinding so all WebKit-based GTK+ applications can inherit caret navigation support without modification. 2) Get ATK looked at. See how many of the remaining issues listed in WebKit bug #21546 can be fixed rapidly now that we have feedback from the accessibility team (the DOM events like caret location and text node issues in particular), punting on the more difficult ones so we don't slip. 3) Ensure that GIMP, Yelp, Devhelp, Empathy and Conduit (and notification-daemon if they've merged the WebKit patch?) have _zero_ regressions in accessibility following (1) and (2). 4) Beyond next week: For Epiphany, assess what we need to do to to better support HTML5 / ARIA. 4.a) Develop better communication channels with the Apple accessibility team. 4.b) Help Google adapt the sandbox technology in Chrome/Linux so they don't have to fork WebKit/GTK+'s accessibility code any more and can work with us directly. 4.c) I heard Sun is integrating WebKit into Java. Do you have the internal Sun connections to find out if they can re-use our accessibility in Java for Linux? >From an advocacy point of view, David Bolter has some ideas on how we can increase the profile of web accessibility outside the Mozilla bubble which he'll be sharing. One more thing -- action point 0: It's high time to unblock the GNOME WebKit dependency situation. Good accessibility is central, but we also have a reputation for stability and internationalisation in GNOME. To achieve all three of these goals in time for release, we need to stop putting out old tarballs from 2.24 and start making development snapshots from trunk. We need feedback from distributions, users who speak, read and write in languages we've never heard of and run on platforms and devices we don't use ourselves. As Richard already mentioned, several critical bugs (crashers, printing support, memory footprint, multi-thousand line code cleanup to name a few) have been fixed thanks directly to the WebKit migration. By releasing development snapshots of these applications today, we can paralellise the remaining work. There is still plenty of it, cf. editing API for Evoluton, loader fixes for Epiphany, UI string l10n, GDOM. Willie, can you let the release team know that we're on schedule here so the developers working on all the other tricky bits that make a browser component get the testing and feedback they need? _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
