Daniel, I suppose the first question is “why does it need to be red?” Anything that animates is going to catch the user’s attention anyway, so I don’t see any great harm in keying the background to the theme.
That said, since gtk+ 2.10, haven’t themes been able to support additional named colours, to highlight things like ‘errors’ and ‘warnings’ where appropriate? So shouldn’t Clearlooks and the other themes be providing these now? Or did we just never decide what the standard list of named colours should be?
IBM announced last week that they’re scaling back their efforts on open source accessibility projects. As one of the major contributors to this area over the past few years, they’ll certainly leave a bit of a hole if the community doesn’t rally round to help fill it. There’s often a perception that accessibility is “one of those things that Sun or IBM will take care of”, but this announcement (along with Bill Haneman, the “accessibility name” that GNOME folks may be most familiar with, recently moving on from Sun) should make it clear that it’s not the case, nor was it ever meant to be.
The Ubuntu accessibility team are doing a great job now too, but now would be a good time for anyone who writes GNOME software to re-acquaint themselves with the basic accessibility requirements and testing tools, to help spread the load somewhat.Check out this thread on gnome-accessibility-list for more reaction and thoughts on continuing to move open source accessibility forward.
Just been chatting to Brian about how we can re-invigorate some interest in GNOME accessibility. There seem to be a couple of misconceptions floating around:
- We don’t hear much about accessibility on the mailing lists any more, and the Accessibility Project webpage hasn’t been updated in a year, so it must be ‘finished’
- We don’t have to worry about it, because it’s all in billh’s head, and Sun are doing all the work anyway
None of these are true While the bulk of the work in making gtk+ accessible is complete, that doesn’t automatically make every application accessible, and especially not if you use custom widgets. And nobody ever bothers to submit high and low contrast versions of their application icons to gnome-themes, for example. The list of currently open accessibility bugs speaks for itself.
We’d be interested to hear what you guys think you need to help you write more accessible GNOME applications. More information on how to test for accessibility? Better API docs? A better understanding of 508 legislation? GOK and Gnoperncius FAQs? More community involvement from the assistive technology hackers? Fire away and we’ll see what we can do.
Have spent most of today hacking away at gnome-themes again, trying to fill in the holes that our accessible themes currently leave on the development branch of JDS. If GNOME is serious about accessibility, ‘provision of a high contrast application icon’ really should be a mimimum integration criterion.
Will be spending the rest of the afternoon sticking my oar into the FTP login and Connect to
Server dialogs again, though, which should be more fun
So, Michael Schumacher wins another dull race and another dull F1 World Championship, and Motherwell’s dismal start to the new season is relentless. Blissful normality.
Plans to write the GNOME Human Interface Guidelines (mini-edition) continue apace, and we’ve now all agreed who’s writing what. I’ve hastily been trying to learn DocBook in preparation for this monumental task, by converting my latest draft of the GNOME Accessibility Guide. “Trivial” and “not” are two words that spring to mind.