[This is a joint post by Jen Guiliano, assistant director of the Maryland Institute for Technology in the Humanities, and George H. Williams, associate professor of English at the University of South Carolina Upstate.
This post was originally published on September 20, 2012 at ProfHacker.]
Consider this a call to digital humanists generally and more specifically to the project directors (from 34 different projects) who attended today’s Project Directors meeting at the National Endowment for the Humanities’ Office of Digital Humanities:
What is your project doing to address accessibility for people with disabilities?
Today’s meeting is a gathering of project directors from the Digital Humanities Start-up Grants, Digital Humanities Implementation Grants, and the Institutes for Advanced Topics in the Digital Humanities competitions. Each project gets just three minutes and three powerpoint slides to introduce their project and their concerns, so we’re taking the liberty of publishing a blog post as a follow-up.
Over the last several decades, scholars have developed standards for how best to create, organize, present, and preserve digital information so that future generations of teachers, students, scholars, and librarians may still use it. What has remained neglected for the most part, however, are the needs of people with disabilities. As a result, many of the otherwise most valuable digital resources are useless for people who are–for example–deaf or hard of hearing, as well as for people who are blind, have low vision, or have difficulty distinguishing particular colors.
One of the central values of digital humanities is the importance of open access. For example, most scholars in the field would never use a proprietary format for preserving and sharing our work, in part because to do so would be to exclude those people who cannot afford or do not have access to the necessary software to use that format. However, few of us think twice about whether or not the format we have chosen and the design choices we have made are excluding people with disabilities. As a result, inaccessible design choices remain a significant barrier to the digital humanities for people with disabilities. If our goals include–as they should–the ability to share our work with as wide and diverse an audience as possible, then we should embrace universal design principles.
For the 2012-2013 academic year, the BrailleSC project and the Maryland Institute for Technology in the Humanities have partnered to extend WordPress–a system recommended frequently here at ProfHacker–to the blind and low-vision communities by creating a plug-in that will allow anyone to translate WordPress content to braille text. We’ve titled our efforts “Making the Digital Humanities More Open.”
Why WordPress? WordPress is the chosen platform for “over 60 million people†and has been used by digital humanities projects and centers to power their research and content delivery. We’ll be able to deliver a plug-in that allows an integrated experience for blind and low-vision users who want to engage digital humanities content.
And while this is an important first step, we’re also using this project as an opportunity to evaluate our own development and design practices by keeping the following questions in mind:
- Are we building accessible sites and projects?
- Are we delivering our content (code, publications, digital objects, digital tools…) in forms that allow for use by blind and low-vision people?
- What do we need to know to integrate the work going on in braille and low-vision research communities into the work we are doing as digital humanists?
There’s much more work than this to be done, of course. People work in a digital environment with a wide variety of abilities and disabilities (not to mention a wide variety of hardware and software tools). Vision and its associated technologies are only one aspect of that work.
So, we’re inviting you to join us in learning more about accessibility this year:
What is accessible design? What can we in the digital humanities do to improve the work we are already doing? And how can project directors evaluate projects and tools to recognize accessible-compliant design and development?