We all know what accessibility means, right? It means designing physical spaces for wheelchairs and websites for screenreaders.
Hmm. It's clearly nonsense when I say it like that, isn't it? We know that there are a multitude of different disabilities, and we need to design both our physical spaces and our software to accommodate those disabilities.
Do you see the major error I still have in the previous sentence? We shouldn't be designing for disabilities, we should be designing for people. Just as we have to design our finding aids and discovery tools to serve people with a variety of different backgrounds -- scholars, archivists, genealogists, undergraduates, hobbyists, etc. -- we need to design our physical spaces and software tools to serve people who might have a variety of different needs. It's universal design, baby.
There's a lot of back-office work that goes on in archives, enabling us to describe, curate, and preserve our collections. And sometimes, we have to do that back-office work with tools which have not been written using universal design principles. In fact, as a general rule, when people think of accessibility they think of accessibility for end-users, not back office users.
I've made a couple of screencasts of me accessing objects in our Fedora Commons repository using the Fedora Commons client tools. I'm not picking on Fedora because it's a particularly egregious example. In fact, Fedora provides something most other tools don't: command line interfaces to all of their administrative commands. I generally don't use the graphical interfaces I'm demonstrating below (for reasons which will become obvious). Usually I work at the command line, where I can use dictation macros I've written to speed up my tasks. And we should remember that the list of tools with accessibility problems is exceedingly long. During the course of making these videos and writing this post, I fought with accessibility problems in my screencast software, Adobe AIR, Windows Media Player, the WordPress dashboard, and the Java installer. (Guess who was worst? I'll give you a hint: it was Adobe AIR.)
We get a lot of queries at DCA about Fedora and whether other archives should use it, and in general our answer is "It depends on your development support structure". To that I'll add "As with any tool, make sure your back-office users can use it before you commit." Archivists, this should be our mantra: We will not have usable and accessible software unless we demand it.
Enough babbling. Here are the videos, both with closed captions, and transcripts included below. The first is of the legacy Java interface to Fedora, and the second is to the vastly-less accessible web interface. (The web interface was written with Adobe Flex, incorrectly identified in the screencast as Adobe AIR. Flex is just the framework used to write the tool, which is presented to the user as a Flash application; I don't make this clear in the screencast.)