On Wed, 2010-03-31 at 09:28 -0400, Willie Walker wrote: > Hi Owen: > > Many thanks to the GNOME Shell team for writing this and the WIKI page. It > is very promising to >see accessibility included in the roadmap. I have a few questions: > > 1) I believe accessibility should be a requirement for GNOME Shell for GNOME > 3. Does the > presence of it in the roadmap mean there is a commitment to making this so?
The roadmap includes both items that I think are essential for GNOME 3 and items that I just think are very important for GNOME 3. I don't think we should ever believe that it's enough to have accessibility that is there as a bullet point, or to have accessibility that someone who is extraordinarily motivated can "suffer through". In my mind accessibility has to be held to the same high standards as everything else in GNOME - that means that developers are actively testing their applications against it, that it can be on by default without introducing huge performance or stability problems, that it has a clear and easy to use configuration system, that we've thought through user experience, and as much as possible, it just works. Getting accessibility fully to that standard isn't going to happen for GNOME 3.0... we've never been there for GNOME 2, we aren't going to be there in 4-5 months even if it was the only thing we worked on. But where I definitely want to be for GNOME 3.0 - in the next 4-5 months is to make sure we've laid the groundwork properly so that we can get there in follow-on releases, both on a technical level and on a user-experience level. At a technical level, once he finishes up his current immediate work on the message tray Dan Winship is going to dedicate a chunk of time (probably around a month or so) to pushing things forward. What exactly he works is going to depend on further investigation, but I would imagine he'll do is work with the Clutter and Ca11y folks to figure out a solid Clutter+ATK story (is ca11y something separate, should it be integrated into Clutter, if it's separate, how do the modules get loaded, etc), then figure out how that fits in with the GNOME Shell toolkit and the ways that we build our user interface. Because individually making clutter actors accessible isn't going to produce a comprehensible, useful screen read of the shell. And I think if we get the technical foundations right, that will also (roughly) get us back to 3.0 to the status quo of having something that someone who is sufficiently motivated can work with. I'm also hoping that if the technical foundations are settled it should be possible for a broader range of contributors to jump in and make small fixes to improve things... to add missing roles, etc. Separately, I've turned the job of working with Joseph to get his magnification patches landed over to Colin, since I was completely failing to get it done. Colin did a review of the latest patches last week, and I expect that to move forward pretty quickly now. Keynav is probably the place where we need the most help and the immediate help we need is on the keynav design. To give a taste of the questions: - Can the current 'search-based' keynav be extended to be complete or we need an alternate "navigation" design that more literally maps to mouse actions? - If we need a navigation design, what specific keys are used to trigger navigation and to navigate and to activate actions? Basically, we need to come up with a complete specification for how keynav works before we can proceed to the subsequent steps of figuring out the necessary infrastructure and implementing it. At this point, I don't see that all coming together prior to GNOME 3.0, but there is going to be *some* keynav there - all the current Metacity keynav still works, a lot of functionality is accessible by search. What is more at risk is completeness - making sure that *all* functionality is accessible. > 2) In the "Appearance" section on the WIKI, there is mention of theming. > Will this hook into the desktop appearance settings we have available > in GNOME today? In the roadmap, what I meant by "theme" was really more in terms of "overall appearance" rather than "alternate overall appearance". Because every single bit of the shell appearance is driven out of CSS stylesheets, there is great possibility for configurable theming, but because every single bit of the shell appearance is driven out of CSS stylesheets, there is also a great interdependence with the code, and possibility for themes to break as the code is developed. For that reason I'm not crazy about the idea of allowing users to install new themes and have them picked in appearance properties for this development cycle. But if there's someone who's willing to do maintenance, I think we could definitely have "hacks" like loading an additional stylesheet if the GTK+ theme name has specific recognized name like "HighContrast". We certainly will be following the preferences for font and font size prior to 3.0. - Owen _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list