In doing this week’s reading I was particularly drawn to the piece “Disability, Universal Design, and the Digital Humanities.” We’ve discussed accessibility a lot in this class, and I’ve thought about it more as a result. Universal Design on the other hand is something that I’ve been interested in for a long time, from a more selfish personal-accessibility perspective. I think it is often complicated to discuss accessibility with novices in terms of digital design, because on one hand we want our early offerings to be as aesthetically pleasing as possible, and on the other, we only have so much time to spare, as the real nuts and bolts of digital design can be intimidating to say the least.
This is where I think there is a disconnect between what an article like Williams’ presents and essential basics of computational design that I would argue should be focused on well before focusing on access for those with disabilities (for the sake of creating offerings that can be easily transformed into more accessible offerings).
“Accessibility would be much easier for most content creators to achieve if a suite of free and open-source accessibility tools were developed for popular content management systems (CMS). A list of the most commonly used CMSes for digital humanities projects would include – but not be limited to – WordPress, Drupal, Omeka, MediaWiki, and Joomla.” (Gold, 206)
He then goes onto say how easy each of these CMS frameworks are to install. This is for me the first warning sign. I don’t want to say that experts don’t or shouldn’t use a CMS, but what I would hasten to say that digital humanities scholars should be more concerned with web semantics in and of themselves before they start trying to wrap their heads around injecting appropriate accessibility into semi-corporate CMS systems.
Williams writes a few pages later:
“What I am arguing is that infusing the digital humanities with universal design principles will result in just this kind of reciprocal relationship (reciprocal relationship between design for those with disability and broad general design (my interpretation))” (Gold, 210).
The sentence that follows this is a warning from Matthew Kirschenbaum:
“the current state of new media studies as one in which the graphical user interface is often uncritically accepted as the ground zero of the user’s experience” (Gold, 210).
I believe that Williams is misreading Kirschenbaum’s emphasis. Williams seems to paradoxically relay a set of beliefs that places the typical digital humanist as a master of all digital trades and languages while at the same time needing to rely on CMSes for simplicities sake. I read Williams to say that a move away from graphical interface is a move toward the internet as experienced by those without sight. The issue is the bulk of us are without sight. The digital scholar that has not been trained in computer science is more often than not a victim of missing the forrest for the trees in a sense. They are using CMSes built on programs, built on programs, hosted on commercial servers that seem to work like magic to their uninitiated senses. To approach this crowd with the idea that they need to focus on literal accessibility by the disabled from within such a demented framework instead of focusing on understanding the actual landscape where their offerings exist, is going to lead to more wasted time than it is to actual construction of a more accessible web infrastructure.
I think the question you’re relating to is because you might be too focused on the “lonely hacker” mentality. You’re also assuming that the computer scientist is not, what you call, disabled.
If programs are a result of single authorship your results are never very accessible. Certainly there are some elements that can be easily “read” by others, but that’s because most of us are socialized human beings and therefore we can draw on a wealth of signs and symbols and methods that already have wide-spread currency. To my second point, someone who is blind, or who has dyslexia might construct a program extremely differently than someone with other abilities. There are also the issues, as you point out of fundamental design structures. In the same way our cultural signs and symbols on which we rely daily often fail to be fully inclusive so do our computer systems at their very basis. I think it’s a mistake to say, let’s not put on patches so that others can get involved so that we can redo everything and get it right on the underside.
The “getting it right” part of universal design is a process, not a point that can achieved now or in the future. I think the emphasis in DH on collaboration is what leads to increased accessibility, not single programers who have found a way that makes the most sense for them and that they’ve possibly found has the most currency. Also in a collaborative model, not everyone is programers — you have people who are using these tools and demanding changes and identifying issues — the feedback loop — that forwards the process toward universal design.
Interesting points, let me see if I can address them…
I think the concept of my leaning toward a “lonely hacker” mentality, or the idea that I do not think the crowd should be a major source of productive design, is to excusably misread my poorly written blog post.
It is not the disabled computer scientist, or any computer scientist for that matter, that I am addressing in my initial post. I am addressing the non-computer scientists that are dipping their feet into initial DH curriculum and before actually having the skills to design anything beyond the constraints of a CMS, they are being asked to contemplate something as high level as interface design for the disabled. The question isn’t should the disabled be afforded access, the question is shouldn’t we define and accomplish personal access before we start ruminating on providing access to the disabled. The issue I see is that many students approaching the DH field have blinders on in relation to processes like hacking, making, and building.
That said, I am not suggesting that DHers all be high level computer scientists or engineers. I am also not suggesting that collaboration should be anything shy of an important/essential feature of DH, however, there is a huge gap between those that do not understand how to utilize even basic HTML and CSS code and those that can engage in productive digital work on crowd-heavy productivity networks like GitHub, Sourceforge, and StackOverflow. By opening heavy handed rhetorical debates about the the current state of the digital in academia and placing that rhetoric side by side with heavily branded tools that are far more constrained than “newbs” might realize then there is at worst a slight disservice being done.
This comes back to trying to define what a DHer even is. If a DHer is a humanist that is collaborating with a computer scientist that has designed an app that works within some MOOC infrastructure and a blind student cannot access it, and the humanist “reports” this “bug,” then maybe the issue I’m taking is unnecessary… however I would argue that it doesn’t take anyone with any kind of “digital” or “computing” adjective prior to their title to report this bug. If a DHer is somebody who builds things, I think they need to understand the basics of foundation building. One should understand how to build a wall before they worry about building a house that is handicap accessible.
And as far as “universal design” goes, I think “universal design” is possible, and it is what companies like Apple and in the past a Sony (think Walkman), or even a company like Marlboro (the cigarette standard) have gotten right to a degree. These are examples that have gotten it right with a time stamp and with a reliance on industrial late capitalism. If computer scientists working with FOSS are going to tackle universal design to the degree the corporations have reached, they are going to need a stream of scholars with culture rich data sets that are familiar with some things beyond an already corporate (or even faux-corporate) set of content management systems. I don’t think some real initial exploration of pragmatic computing basics is too demanding for the humanities scholar if they hope to have a word like “digital” properly attached to their academic titles.