Chapter 21
Reframing the Conversation: Digital Humanists, Disabilities, and Accessibility
Megan R. Brett, Jessica Marie Otis, and Mills Kelly
Making software, websites, and other digital products more accessible is a growing consideration in the digital humanities (DH).1 Whether incorporated into design conversations, tacked on before a project launch, or retrofitted onto projects with long-standing problems, accessibility is slowly becoming part of the DH workflow. But while conversations around design and access are a necessary and welcome development, these conversations often remain limited by two crucial factors: the oversimplification of disability and the perception that people with disabilities are external to DH communities.
For digital humanists to take a proactive approach to addressing accessibility, we must first understand that people with disabilities are not just in our audiences. “They” are us, and we have diverse, often competing needs for accommodations that enable us to fully participate in the creation, consumption, and analysis of digital scholarship. Creating accessible work or accommodations for people with disabilities is not a hypothetical need or a requirement imposed by law; rather, it is a moral imperative if the digital humanities are to be the inclusive and welcoming community we publicly aspire to be.2
The authors of this chapter have a variety of disabilities—including sensory, motor, and cognitive disabilities—that impact their DH work. One author has astigmatism as well as auditory processing issues and intermittent hearing loss, which can make it difficult to hear or follow conversations in loud spaces like conference halls. Another has migraines and astigmatism that makes it painful to read white text on black backgrounds—ironically, a design choice many make to accommodate forms of visual disability requiring high contrast (Otis). She also has asthma, which has been triggered by DH conference locations, and knee issues that have prevented her from being able to access DH conference spaces. The third author has met the legal definition of deaf/hard of hearing since high school, has worn bifocals for more than two decades, and was diagnosed with severe osteoarthritis a decade ago, a condition that makes sitting for more than thirty minutes painful. Thus, while our individual practices are variably informed by disability studies, this chapter is grounded largely in the lived experiences of the authors as disabled practitioners of DH.
What Are Disabilities?
In the United States, where the authors are based, disability is legally defined as a physical or mental impairment that substantially limits the ability of an individual to perform a “major life activity” as compared to most people in the general population (Department of Justice, “Final Regulatory Assessment, Final Rule”). The 1990 Americans with Disabilities Act (ADA) made it illegal to discriminate against individuals “on the basis of disability in the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation” (“Americans with Disabilities Act of 1990, as Amended”). Eight years later, as the importance of computers and the internet became increasingly apparent, the Rehabilitation Act of 1973 was updated to mandate the creation of accessible “electronic and information technology” (Department of Justice, “Workforce Investment Act of 1998”). Together, the ADA and Section 508 of the Rehabilitation Act created an ideal of full inclusion for people with legal disabilities into all aspects of American society, including the digital. Although Canada and the European Union member states take similar approaches, and the United Nations adopted the Convention on the Rights of Persons with Disabilities in 2006, policies and enforcement vary widely around the world.
Reality in the United States often falls far short of the ideals expressed in these laws, in part because disabilities are more complicated than the legal definition. Major life activities, as defined by law, include walking, breathing, and thinking, but not driving, caring for children, or using a computer. Disabilities that do not warrant legal accommodation, such as moderate carpal tunnel syndrome, may still significantly affect a scholar’s ability to engage with the digital humanities. Conversely, some people with legally recognized disabilities, such as cancer, may feel their disabilities have little to no impact on their engagement with DH (Forlano).3 An individual remains legally disabled even if medication or assistive technology gives them the ability to perform those life activities, with the sole exclusion of glasses and contact lenses; this technology has become so normalized that only uncorrectable vision problems (20/200 vision or lower vision acuity) qualify as legal disabilities. An individual may be completely asymptomatic—such as a cancer patient in remission—yet legally disabled. Disabilities are thus complex conditions that may or may not be constant in the experience of an individual (as anyone with depression can attest) and that exist on a spectrum that includes, but is not limited to, conditions with legal recognition.
The social model of disability reframes the understanding of disability not as the individual impairment but rather the societal barriers—physical, cultural, or digital—that cause unequal access for persons with an impairment (Goering). Accessibility is the process of removing barriers, mitigating access, or creating alternate points of entry. The Web Content Accessibility Guidelines (WCAG) are organized around four characteristics for all accessible content: perceivable, through multiple means including assistive technologies; operable, regardless of input device; understandable, both in language and layout; and robust, or broadly compatible with a range of assistive technologies (“WCAG 2.1 at a Glance”). Whereas accessibility is built in to the system, accommodations provide access by modifying an existing structure or system. A physical world example would be the difference between an entrance with stairs and a ramp (accessible) and a folding ramp placed over stairs temporarily (accommodation).
While disabilities and accessibility are universal concerns, they affect digital humanists directly. No one in DH communities lives untouched by disability, whether they have a disability themselves or their relatives, collaborators, or students do. In America, one in four adults is legally considered to have a disability (“Disability Impacts All of Us”). Approximately 75 percent of Americans need vision correction, while around 4.4 billion people worldwide have myopia and other vision impairments (World Health Organization; Vision Council of America). Color blindness affects one in 12 men and one in 200 women worldwide (“Color Vision Deficiency”). Over 31 percent of Americans will experience an anxiety disorder at some point during their lives, and 20 percent of college students were diagnosed with anxiety in 2018 (Kane). Similarly, 13 percent of American adults aged 18 to 25 have at least one major depressive episode, making anxiety and depression the most common mental health concerns among college students (“Any Anxiety Disorder”; “Major Depression”). Difficulty walking or climbing stairs affects 14 percent of American adults, while 11 percent have serious difficulty concentrating, remembering, or making decisions (“Disability Impacts All of Us”). These and other disabilities can be “invisible,” making it easy to overlook their prevalence within the DH communities and among our audiences. But given the ubiquity of people with disabilities and an emerging consensus about accessibility best practices, digital humanists must become more attentive to the complexities of disabilities and accessibility as we plan and execute our projects.
How We Fail
Digital humanists are familiar with failure and often embrace it pedagogically, although we are less comfortable with being public about the failure of high-status projects.4 Yet when it comes to accessibility, digital humanists often fail to notice we are failing. For examples of failures to meet even the most basic web accessibility standards as laid out in WCAG, we the authors did not need to look very far. Though our center, the Roy Rosenzweig Center for History and New Media, was founded in 1994, we did not start consistently adding subtitles or closed captions to videos and screencasts until 2015. Since then, we have endeavored to make new videos more accessible but have not had the resources to completely remediate our older materials. We are not the only ones. A quick scan of recent winners of the Roy Rosenzweig Prize for Innovation in Digital History, completed using the WAVE Web Accessibility Evaluation Tool, flagged accessibility issues in every site’s home page.5 Some issues are easily remediated, such as changing font colors or adding alt-text. But others are baked into the project design. Entire technologies such as the now-deprecated Flash can be inherently inaccessible and only partially modified for accessibility, while other technologies such as JavaScript may have only limited accessibility even if set up correctly, which digital humanists often fail to do.6
Digital humanists do not have the resources to plan for accessibility for all disabilities, especially given the wide range of permanent and transitory disabilities people experience. Indeed, there are certain forms of DH projects that may be inherently inaccessible to people with certain types of disabilities; for example, we have yet to figure out a way to make a network “hairball” visualization fully comprehensible to a screen reader. However, we still need to be attentive to accessibility concerns among our colleagues and our audiences and consider creating multiple avenues of access to our scholarly evidence, data, analyses, and arguments. For example, the data driving a network visualization may be presented in a fully accessible manner, even if the visualization of that data cannot be described by a screen reader. In general, we need to budget more time and money for accessibility. We need to coordinate with our primary stakeholders in order to assess our projects for accessibility and revise them if necessary. We need to call on our funders to allocate money to accessibility and make accessibility a priority in proposal evaluation processes. Most importantly, we need to not be afraid of trying and failing to do better.7 Try-fail cycles are a normal part of the DH workflow; the only permanent failure is in not trying.
How We Can Succeed
We have spent several years thinking critically about how digital humanists can incorporate greater consideration of people with disabilities into our work. There is no straightforward “quick fix” or even a difficult but attainable universal design that can solve all our problems: Disabilities are myriad, complex, and the accommodations needed by one person may cause problems for someone else. For example, a ramp may seem more accessible than stairs, but there are disabilities that render ramps difficult to manage. Instead of a one-size-fits-all approach, a multimodal approach can accommodate a wider range of people.8 Our conversations have given rise to a series of proposed first steps we can take toward a more proactive approach to accommodation in several areas of intervention relevant to the field. We intend these initial proposals to be just that—a place to start, not a set of standards to be adhered to. We hope these proposals will be a starting point for productive conversations among those working in the digital humanities.
Communities of Practice
Teams and Collaborations
The first and necessary step for digital humanities scholars is to acknowledge the existence of and respect the lived experiences of colleagues with disabilities. Whether DH work is taking place within an informal collaboration or a formally organized center, department, or team, we can start by adopting a set of guiding principles for accessibility. It is incumbent on those in positions of formal or informal authority to press their colleagues to think critically about what such guiding principles might look like and how they might shape future projects. Collaborators and teams should have open, honest conversations about their own accessibility needs and make self-identification of disability something that feels safe and normal, while understanding that team members may still decide not to disclose their disabilities (as discussed later). Holding a conversation about accommodation needs in the first meeting of a new collaboration makes it clear these issues are being taken seriously. Regardless of whether team members have conditions that have been legally recognized as disabilities, identifying and meeting those team members’ needs will make the process of creating a DH project more productive, enjoyable, and inclusive for everyone.
Even small accommodations can have a significant impact for ourselves and our colleagues. For example, most people can point to the experience of taking part in an audio-only conference call where they have had difficulty hearing a speaker, but a person with a hearing impairment may have difficulty understanding or tracking anyone on the call and become completely unable to contribute. Agreeing to conduct remote meetings by video conversation platforms like Zoom or Google Meet—which many people became familiar with during the Covid-19 pandemic—rather than audio only makes it possible for those with hearing impairment to read visual cues or employ live captioning and better follow the conversation. Alternatively, learning that a team member is color-blind might steer the team away from project planning tools that use color as the only signifier of importance—again, denying that team member access to information necessary for full participation—while at the same time helping the team to identify the team members who might be best able to assess the readability of information on a project web page.9 Acknowledging the myriad ways we perceive, process, and store information makes it possible to accommodate those team members’ accessibility needs within the context of a project and can improve collaboration on multiple levels.
Scheduling is another potential area of accommodation, and one that digital humanists are particularly apt to ignore during periods of intense concentration or in the excitement surrounding the start of a new project. One of the authors of this chapter has a congenital orthopedic issue that makes sitting in a chair for more than thirty minutes increasingly painful and distracting. Other conditions can cause a person to require frequent and longer bathroom breaks. Those with cognitive differences, including attention-deficit/hyperactivity disorder (ADHD) and processing disorders, need periodic short breaks to completely process any given information. There is evidence that even neurotypical people can become more focused and productive after a bathroom or stretch break, so that an accommodation intended for one person can actually benefit the whole team (Weir).
However, it must be emphasized that we cannot assume that all collaborators will initially be comfortable self-disclosing their accommodation needs. They may prefer to do so in a one-on-one conversation or at a later date once they are more comfortable with the team. They may wish to disclose anonymously, through human resources, or they may not wish to disclose at all. No matter how normalized discussions about disability might become within DH communities, our wider cultures continue to stigmatize people with disabilities. One need only skim the stories in the Twitter hashtags #AcademicAbleism and #ChronicallyAcademic to see how people with disabilities are mistreated in academia, which simply indicates that academia is no different from the wider societies where we work. We should remain mindful that people may be hesitant to ask for an accommodation and make it clear that our collaborators can disclose needs when and how they are most comfortable. We must respect our colleagues’ right to privacy. It is also important to remember that not all disabilities are lifelong or constant; people may have events in their lives that require new or changing accommodations.
Once an initial accommodation plan for a project team is completed, everyone involved should have time to review the plan to ensure that their current needs, and those of their colleagues, have been clearly understood and met. Optionally, if the project has access to a campus office of disability services or assistive technology, an ADA compliance officer, or a similar accessibility group, these professionals can be asked to review the team’s plan, both at the start of the project and as needs change, to see if they have additional suggestions. A caveat is necessary here because the quality of available services can vary greatly from organization to organization. If the services most readily available are not well regarded by members of the local disability community, the team should look elsewhere. Many academic campuses have community groups that discuss accessibility and disability, and some cultural heritage organizations have access to consultants and companies that contract to perform accessibility assessments. Once the team asks for professional assistance, they should invite that person or group to take a holistic approach to their work, assessing their processes as well as their end results.
Social Media
Beyond the project team, digital humanists create communities of practice online through social media platforms. Given the importance of social media and “gray literature” for knowledge sharing in DH, this is a vital space to make inclusive for our colleagues with disabilities, particularly on digital humanists’ current platform of choice: Twitter. While not perfect, Twitter currently offers built-in accessibility features that we should learn to use consistently. We should also be alert to new accessibility features as they are introduced, and we should advocate for the creation of such features for all our digital content.
Most notably, Twitter has an option for “alt-text” or textual descriptions to be added to images, to make them describable by screen readers (Twitter Help Center). This is vital given the current trend of creating images from plain text. Twitter’s user interface for this is not ideal, as it sometimes leads people to accidentally post tweets as alt-text when tweeting an image taken from within the smartphone app. At the time we wrote this, it also displayed the text (or partial version of longer text) as a caption on top of the image in very small font, rendering it illegible and obscuring the image for anyone not using a screen reader. However, this small blip aside, Twitter makes it easy for users to generate accessible images.
Even when not using images, there are ways to make our presence on Twitter and other social media platforms more accessible. We should always camelCase our hashtags, starting each new word with a capital letter, as this allows screen readers to recognize the tag is made up of multiple words (“Camel Case”). Hashtags written in camelCase are also easier for everyone to read: Consider the difference between #demouser—which could be read as de-mouser—and #DemoUser. “Threading” tweets, using the thread functionality or by replying to oneself, also improves the readability of our content by establishing a linear flow of connected tweets. This reduces the cognitive load of following a conversation on Twitter and speeds up the process of using a screen reader to find and listen to a conversation.
Adding an image description, using camelCase, and threading a conversation requires only a few moments for most users and can vastly improve the accessibility of our professional conversations on social media platforms. For some of us, these techniques may be challenging to implement because of workflow issues when using speech-to-text, additional cognitive load, or additional typing time. However, those of us who are able to take these steps with a minimal investment of time and energy should make it standard practice to use social media in a more accessible manner.
Public Presentations
Another area where we can make significant improvements to the accessibility of our communities of practice is in presentations at conferences, at public talks, and in our classrooms. Beyond the basic ability to access the presentation space—which is not a given, especially when doors are heavy, aisles narrow, chairs tightly packed, and platforms raised—there are a host of physical, sensory, and cognitive accessibility issues at play in these spaces. Event organizers should pay specific attention to the accessibility of their spaces and solicit accommodation requests during preregistration. Attendees should hold organizers accountable for choosing physically accessible spaces, proactively and publicly identifying potential hazards, providing assistive technology, creating spaces such as quiet rooms, and ensuring attendees have easy avenues of communication for on-site difficulties.
While many organizational decisions are ultimately out of the control of event participants, speakers can control the accessibility of their presentations. The most common battles over presentation accessibility have been over auditory accommodations. Many of us have experienced presenters opting to shout rather than use a microphone. While the speaker’s volume—and the signal-to-noise ratio between their voice and the ambient room noise—is an important component of being heard by those with and without hearing impairments, it is only one of several factors in intelligibility, even when direct transmission from the microphone to a hearing aid is not involved. Speaking “louder” changes the decibel level and frequency of the sound waves the speaker produces, distorting the voice and paradoxically making it more difficult to understand. Crucially, for those speaking in atonal languages such as English, the most important sounds are those produced by consonants, which are produced at pitches over 500 hertz (Hz) and primarily around 2000 Hz for all genders as compared to vowels at 100 to 120 Hz for men’s voices. These higher frequencies do not travel as far as low frequencies and must be artificially amplified to be audible, particularly to those with hearing impairments in those ranges (“Facts about Speech Intelligibility”). The sound-dampening properties of most speaking venues, in the form of carpeted floors and fabric-covered walls, further distort and prevent the travel of sound waves to all corners of a room.
For audience members with hearing impairments, speakers who refuse a microphone are often very difficult to hear, forcing listeners to choose between interrupting the speaker, self-identifying as having an auditory disability, or not hearing the speaker at all. As a speaker, choosing not to use the microphone prioritizes one’s own convenience over the needs and privacy of the audience members. Similarly, faculty members who ban laptops from their classrooms, except for students with accommodations, single out their students with disabilities for all to see (Rose). If microphones are available at an event, everyone should insist on their use by both speakers and audience members with questions.10 If microphones are not available—and this is something speakers should ask about in advance—speakers should print out large font (18 point) versions of their notes or speech and make them discreetly available at the room entrance so that attendees can have a written transcript to supplement the spoken word.
Whenever possible, it is vital that event organizers ensure every room has at least one microphone. They should also coordinate with any required American Sign Language (ASL) or transliterated English interpreters. For events or organizations with the resources to go further, there are additional possibilities. In the past decade, real-time video captioning has improved dramatically, to the point where one of the authors recently attended a small conference where all three keynote presentations used closed-captioning in real time. The system used for those presentations managed to correctly capture more than 90 percent of what the speakers were saying.11 Those of us at cultural heritage institutions could inquire about obtaining access to such technology for our presentation spaces, while faculty, staff, and students at U.S. institutions of higher education should have some sort of office of disability services that can help us obtain access to similar tools to improve the accessibility of our presentations. All of us can independently explore community resources as well.
Another issue that receives far too little attention is the need for presentation materials to be visually accessible. How often have you sat through a presentation where the text on the screen is smaller than 24 points and the presenter says, “I know this is kind of hard to read. . . .” Or a presentation where there is text displayed over an image? Or where the color contrast between the text and the background color makes it difficult to read? Or where the font is difficult to read from the middle or back of the room? All of these same readability issues exist in DH projects, and all can be easily avoided.
We might want to choose artful fonts, but readability is more important than aesthetics. Arial (the font the authors used when drafting this chapter) may be boring, but it is also known to be more legible to people with visual impairments or dyslexia than many other fonts (Rello and Baeza-Yates). The Penn State IT Accessibility Group maintains an excellent guide to accessible fonts, and there are many other resources online. Accessibility best practices also argue against placing text across an image or, if doing so seems critical to the design, making sure that the color contrast is so strong that those with visual challenges can read the text despite the background image. The website A11y.com offers a free color contrast accessibility validator that lets you test for readability.12 Bear in mind that choices that are accessible for some may be inaccessible for others; for example, light text on a dark background can be ideal for viewers with light sensitivity but terrible for those with astigmatism.
The best way to create accessible presentations is to begin with established best practices and then adapt as needed, based on feedback from your audience. It may ultimately be the case that the easiest way to accommodate a particular person is to give them digital copies of your files and let them adjust their copy of the presentation themselves in order to fit their specific circumstances. We need to be flexible to ensure that our colleagues and our audience members have the tools they need to engage with our scholarship. We also need to be willing to listen to the needs expressed by our audience members so that everyone in the room has equal access to the content of our presentations.
What We Build
From Collaborators to Users
While it is vital to consider accessibility within our communities of practice, it is also necessary to extend this consideration to our users and make accessibility a normalized part of design conversations. Just as we make space from the beginning for collaborators to request accommodations, we should invite potential users into our work early on through peer review or user testing. Having people with a variety of abilities attempt to use a research product and record what happens allows us to find and correct potential accessibility problems. Selecting testers and reviewers should be done with the openness and care to ensure that they represent a diverse user base. For larger projects, a local or institutional disability service or ADA compliance officer might even help the team convene a user testing group that includes people with the specific disabilities that are expected to be present in the project’s users and audiences. By inviting feedback on our work early in the process, we have a higher chance of a more accessible final project, regardless of what form(s) it takes, and we can avoid problems that are obvious to someone with a particular disability that might otherwise escape our notice until after we no longer have the resources to fix them.
Websites
Many DH projects include the production of a website, often as the home for a tool, argument, or dataset. There are abundant resources regarding the basics of creating an accessible website or page. They range from the formal guidelines of Section 508 and WCAG to online articles and a full suite of accessibility checkers like WAVE. These resources can seem like a blessing to someone just starting to think about accessibility in their work, or they can seem overwhelming. But many of the same basic accessibility improvements that we discussed in the context of communities of practice—from color contrasts to camelCase—can also be deployed to make websites more accessible. Others can be identified through a straightforward process of user testing.
At the most basic level, user testing helps identify issues with navigation and design for physical, sensory, and cognitive disabilities. It can tell us whether the tab order for site navigation makes sense, if the internal navigation links are functional, and whether we have implemented visual navigation (icons and text) in a consistent manner throughout the site. User testing can help ensure that the site’s JavaScript is configured properly for visual accessibility, with attention paid to focus management, polite alerts, and dynamic content changes. Project creators can discover if they have built a site that cannot be navigated without reliance on a mouse, or if they have made assumptions about a user’s speed in navigating the site, forms, or dynamic content that might prevent people with a variety of disabilities from using the site as intended.13 While some of these issues might be anticipated by an alert programmer, one thing that can arise in user testing that is harder to predict is clarity: things that make “intuitive” sense to us as creators may create steep learning curves for our potential users.14
User testing can also assess the overall cognitive accessibility of our work and whether our project succeeds in the scholarly goals we have set for it. We should ask audience members and peers to engage with our content and summarize what they understand to be the key points of the project. What is the argument, the big idea? Ideally, most testers should be able to articulate at least one goal of the project. If they cannot, we need to evaluate the readability of the text, images, and other graphical elements, as well as the cognitive load imposed by navigating the site’s pages.
For academics used to reading dense and specialized jargon, a point of particular concern is making our text “readable” to a web audience (WCAG 2.1, “Understanding Guideline 3.1”; “Cognitive Accessibility”). Accessibility guideline 3.1 suggests including a glossary of specialist terms through a linked page or as hover text. It also recommends providing short summaries of longer selections of text and of nontextual material, written in clear, simple language.
We can also make our writing more readable for the web by using shorter paragraphs, breaking ideas and key points into separate chunks of information (“Writing for the Web”). Shorter paragraphs not only help lessen the cognitive load of reading, they are also easier to view for people who increase text display size to address vision issues or who are attempting to read on the small screen of a smartphone. In general, we should give serious consideration to our word choices and text structure. Lessening the cognitive load of reading a paragraph allows the user’s brain more room to understand the overall concepts. If users are struggling to simply parse what we are trying to say, it will take them additional time and effort to understand the larger argument. Many will simply click away before understanding the major concepts or analytical methods.
Tools
In addition to building websites, many digital humanists also build software tools, which have their own accessibility challenges to consider. Is our code accessible to programmers with disabilities, especially if we are using an open-source license? Is our tool accessible to users with disabilities, both in terms of using it to create something and of the products it creates? Is our tool documented, and is that documentation accessible? All of these factors have to be taken into consideration over the life span of a tool, for as long as it is supported. While this approach may take longer to implement and more effort to maintain, the upside is that taking more time to release the tool gives us the opportunity to correct previous failings and incorporate new techniques and technologies along the way. This, in turn, allows us to improve the accessibility of our tools and their attendant resources. It is always our goal to create tools that will be used by the greatest number of people, so being attentive to accessibility at the front end of tool creation will help ensure we have done everything possible to maximize our user base.
Code
While there are not as many resources on making code itself more accessible, some of the same practices that we use for websites can be employed in our coding to similar effect. Programmers with disabilities already know which development environments and settings will maximize their access to code, so the primary thing we must pay attention to is the code itself (Doustdar). Using camelCase or underscores make variables more legible, while using logical and memorable variable names can aid programmers with cognitive disabilities as well as those who cannot easily scroll to see how “foobar” was defined. In languages such as JavaScript, that don’t assign meaning to white space, using additional white space might help someone visually process information. At the same time, white space must be used carefully because indentations and repeated spaces are tedious to read through with a screen reader (Stevenson; Radaelli).
Most importantly, we must always comment our code. While this is generally best practice for programming, adding explanatory comments to code also accommodates a variety of disabilities, from people who need assistance cognitively processing a complicated subprogram to people who are using screen readers and need to be able to skip through the program to the code of interest. Writing comments with these issues in mind will result in more useful, legible code for everyone.
User Interface and Products
In addition to the code, we must ensure that the user interfaces of our tools and the products which these tools produce are accessible to users with a wide variety of abilities. The processes we use to guide the creation of websites can be helpful here as well. The fact that many DH tools are open-source tools adds a wrinkle to working toward accessibility: We can guarantee the original work we launched onto the internet but not what our community of users creates from it. There is no guarantee that every member of the developer community who contributes to a tool is aware of or abides by standards of accessibility, even to the point of meeting the legal minimum for their home country. However, an open-source project also makes it possible for us to accept the contributions of others to a codebase. Semitechnical users can file issues against projects on GitHub (and they have) to point out, for example, inadequate contrast between text and background or their inability to select and manipulate something with a keyboard.
It is therefore important to make clear to our communities that we strive to create accessible tools. We can provide links to the standards that we use and to existing resources for accessible development, as well as highlight any key code or design requirements that are likely to crop up when developing our tools.15 This information could be contained in the tool’s ReadMe file or wherever the developers feel it is appropriate. The purpose is to include accessibility in our processes and communicate the ways in which diverse abilities can be accommodated in our work.
Documentation
In addition to making the tool itself accessible, we must ensure our documentation is as accessible as possible. There are four main rules that we follow when writing documentation: (1) Always include an image description or alt-text when using images. (2) Add captioning or subtitles to all videos, as well as ensure access to a transcript of the audio. (3) Emphasize clarity of language. (4) Break any process down into small steps.
The first two rules we have already discussed in other contexts above. Image descriptions and alt-text are essential for anyone with vision-related disabilities. We use the Amara service to create subtitles for all of our screencasts, a process that requires someone on the project to transcribe the screencast and assign timings to the subtitles. We now incorporate the estimated time to subtitle into our estimations of producing any screencast.
The key point for accessibility in documentation, however, is the language used. Regardless of how digital humanists choose to write elsewhere, they need to follow standards for cognitive accessibility in their documentation (“Cognitive Accessibility”). Reading documentation should not take effort because the action of working with the tool is already a cognitive activity. Although documentation necessarily includes some jargon, we must strive to write clearly, using common language whenever possible. For example, the documentation guidelines for Omeka S encourage shorter paragraphs and breaking tasks out into lists whenever possible (Omeka Team). Our overall ethos in writing documentation is the model of the “exact instructions challenge,” in which adults ask children to write instructions for making a peanut butter sandwich, beginning with a bagged loaf of bread, a jar of peanut butter, and a knife.16 In general, we find it is better to include steps that might seem obvious to an experienced user; it is easier to skip a step when reading instructions than to try and intuit a step that is not there.
Voluntary Product Assessment Templates and Accessibility Conformance Reports
A clear way to assess and communicate our commitment to creating accessible DH tools is to complete a Voluntary Product Assessment Template (VPAT) for the tool, resulting in an Accessibility Conformance Report (ACR), and to ensure that an up-to-date ACR is always available on the tool’s website or documentation.17 We recognize this process is not without challenges, particularly for scholars working independently, but the effort yields enough downstream results to make it well worthwhile. The VPAT 2.3 International Form uses WCAG guidelines in addition to the United States’ (Section 508) and European Union’s standards for digital accessibility (EN 301 549). The WCAG section helpfully includes links to explanations of success criteria for each, with examples of techniques and failures. There are free tools to help a team conduct their own assessment, such as the WAVE Web Accessibility Evaluation Tool, Accessibility Insights for the Web, color contrast checkers, color-blindness simulators, and text-to-speech readers, which can be used to complete the VPAT.18 However, even with these resources, it can be difficult for someone just learning about accessibility to gauge where their tool falls in the possible choices of conformance to accessibility standards.
When completing a VPAT for a team project, we need to involve the entire team, including designers and developers who can make code changes, as necessary. One approach is for one or two members to do a preliminary pass through the VPAT once the tool is close to being released, in order to identify errors and problems. They can then bring this initial report to the entire team, ensuring that issues are resolved before the final release. Because this process can be time-consuming, teams should be sure to schedule adequate time in their work plans to conduct a VPAT evaluation and tweak the tool as needed before every release or update. Although the time and effort required to create an ACR may seem like a burden, there are organizations—including educational institutions—that cannot use a tool unless it comes with an ACR.
Furthermore, having an ACR demonstrates a commitment to accessibility on the part of the project team. It can also serve as a starting point for any cultural heritage organization or university/college that must conduct an accessibility review before using a tool. Our own center only adopted this process in 2015, but the ACRs for all three versions of the content management platform Omeka are linked from the accessibility statements in their documentation.19 In addition, a dedicated page for your accessibility statement provides an opportunity for translating the legal language and technical requirements of the VPAT into a readable, accessible series of paragraphs or bullet points.
Multimodality at the Limits
While there are many areas of intervention where digital humanists can successfully improve the accessibility of our scholarship, we acknowledge there are practical limits. We do not intend to argue that all digital humanists should be expected to provide 100 percent accessibility for all possible audiences in everything that we make, create, or present—especially given the possibility of people with competing and mutually exclusive accommodation needs. Digital humanists are almost always “making do” with limited resources. Many people engaged in DH work do so as sole practitioners and not as part of a team or center. Even those who do work at such a center are often stretched thin across multiple projects. Despite these limits, we can be mindful and deliberate about designing our scholarship to accommodate the most common disabilities found in our intended audiences. We can also provide multiple routes into our research products to improve the probability that even people who we have not deliberately accommodated—or who our decisions may have accidentally disaccommodated—can still access our work.
Similarly, digital humanists are often engaged in pushing the boundaries of the digital and creating products that do not easily fit into established accommodation conventions. But just because it is difficult or, at times, not possible to make an experimental research product accessible to certain audiences does not absolve us, as a field, of the responsibility to make our arguments and sources as accessible as possible. Just as alt-text can be used to label an image, it can be used to label the important features of a network diagram. Information presented on an interactive visualization or layered map can also be provided using tables and text that allow people with disabilities to access it differently. By designing a project with accessibility in mind from the beginning, we can anticipate when our decisions will cause issues for people with disabilities and either find new, creative, and innovative ways to build our project or at least build in alternative routes to our core arguments and ideas when the technology does not—yet—do what we need.
Where Do We Go from Here?
Digital humanists need to become more proactive in our approaches to the many and complex issues surrounding accessibility. One step we can take toward this goal is to identify members of our professional networks who have expertise related to specific disabilities. Many people with disabilities are already working in DH and can contribute their own expertise and experiences to making our work more accessible. Furthermore, we can partner as needed with local disability advocacy groups, offices of disability services, and consultants who specialize in access and disability. No one needs to be an expert in all things; we only need to reach out to experts when we find ourselves encountering unfamiliar challenges. Refusing to seek advice—especially when it is freely offered and costs us only time—actively contributes to the marginalization and exclusion of people with disabilities from DH.
An additional solution that we believe holds some of the greatest promise is the deliberate development of professional capacity networks that will allow digital humanists to share knowledge and expertise. Through these networks, we can share information about accessibility tools, how we use them, and what does and does not work for the kinds of projects we are creating and our disabilities or access needs. If someone has worked with a particular disability community to determine an accessible alternative presentation of the data contained in a D3 visualization, they could present that method to their professional networks, thereby enabling even more accessible visualizations. The more widely these experiences are shared, the more likely they are to become standards of practice in our field.
Sharing our varied experiences, as digital humanists with disabilities and as digital humanists working toward accessibility, and respecting the experiences of others, benefits DH communities as a whole. It furthers the spirit of collaboration that is held up as a standard in DH. An accessibility lens also forces a team to identify what is essential to their project or an element of that project, in order to ensure that these key elements are communicated in every accessible iteration of the project. Yet that is not the reason to create accessible work and include accommodations. These are collateral benefits that come from taking the ethical course of action to ensure that we, disabled members of DH communities, are included in the work of those communities.
Living with a disability is a complicated reality, one that should not be limited by definitions of legal disability or by expectations that a disability be permanent or visible. Either through our own lived experience or through interactions with others, we all encounter disabilities in our lives. As DH communities, we should acknowledge this reality and strive to improve the accessibility of our work. We will fail and we will make mistakes, but we must accept these failures as an opportunity to learn and improve rather than denying them or becoming unproductively defensive. Although there is no “magic bullet” for accessibility, no single solution that makes something universally accessible, we hope that DH communities will use the areas of intervention that we have identified and the suggestions that we have laid out to move forward with making accessibility a consistent and active part of their work, for themselves, their collaborators, and their audiences.
Notes
See, for example, Williams, along with pushback on Williams’s ideas about universal design from Godden and Hsy. See also Hill.
See, for example, Dacos’s 2011 “Manifesto for the Digital Humanities,” or Tom Scheinfeldt’s “Why Digital Humanities Is ‘Nice.’”
Different cancers had varying impacts, of course, but one author’s experience with cancer had no real impact on her DH work.
See, for example, Graham; Croxall and Warnick; Mlynaryk.
Some of the links from the American Historical Association’s list of Roy Rosenzweig prize winners (https://www.historians.org/awards-and-grants/past-recipients/roy-rosenzweig-prize-recipients) failed to resolve to live sites. WAVE is available at https://wave.webaim.org.
For more on Flash and content accessibility, see https://www.washington.edu/doit/flash-content-accessible. For Cascading Style Sheets (CSS) and JavaScript best practices, see https://developer.mozilla.org/en-US/docs/Learn/Accessibility/CSS_and_JavaScript.
One caveat is that some people with disabilities need to expend exponentially more effort to complete a try-fail cycle of try, fail, and try again. They may not have such effort available to give for these activities; to use a common disability metaphor, they run out of spoons. It is incumbent on those of us who can implement a try-fail cycle more easily to do so and to be empathetic toward those of us who cannot (“Spoon Theory,” Wikipedia, December 8, 2019, https://en.wikipedia.org/wiki/Spoon_theory).
Confusingly, educational technologists often call this “universal design for learning,” which is distinct from the older idea of “universal design” that originated in architecture and interior design.
For a good website on designing for color blindness, see https://usabilla.com/blog/how-to-design-for-color-blindness/.
A caveat should be made regarding the use of “catch box” microphones, which are a good example of an accommodation causing accessibility issues for people with a different set of disabilities. Not everyone is physically able to catch such a device; speakers should accommodate their needs by having someone else bring them the microphone or repeating an unamplified question into the microphone before answering it.
These systems are not always so accurate. The automatic captions on Google’s YouTube are of inconsistent quality, and one software purporting to automatically caption images determined that our university’s home page was, in fact, a picture of a dog.
The A11y Color Contrast Accessibility Validator is available at https://color.a11y.com/Contrast/; another free contrast evaluation tool can be found at Contrast Ratio (https://contrast-ratio.com/). The WCAG 2.0 statement on contrast ratio for text (https://www.w3.org/TR/WCAG/#contrast-minimum) explains which ratios are acceptable for font sizes and uses.
For examples of known issues to look out for when designing websites, see https://www.accessiblemetrics.com/blog/top-8-most-common-accessibility-issues-to-avoid-and-solve/, https://medium.com/@matuzo/writing-javascript-with-accessibility-in-mind-a1f6a5f467b9, and https://alistapart.com/article/standards-for-writing-accessibly/.
In an extreme example, one of the coauthors was so baffled by her first iPod that she had to use a computer to search online for how to turn it on. Apple products notoriously come without instructions, and what is intuitive to the person who designed a product is not intuitive to everyone.
See, for example, the A11Y Style Guide at https://a11y-style-guide.com/style-guide/.
The peanut butter challenge, which is one variation of the “exact instructions” challenge, went viral in 2017 thanks to videos posted by parents doing the challenge with their children, most notably Josh Darnit (https://www.youtube.com/watch?v=cDA3_5982h8).
VPAT resources are available from the Information Technology Industry Council (ITI) at https://www.itic.org/policy/accessibility/vpat.
See WAVE (https://wave.webaim.org/); Accessibility Insights (https://accessibilityinsights.io/).
For an example of an accessibility statement, see https://omeka.org/s/docs/user-manual/accessibility/.
Bibliography
“Americans with Disabilities Act of 1990, as Amended with ADA Amendments Act of 2008.” ADA.gov. January 1, 2009, https://www.ada.gov/pubs/adastatute08.htm#12182.
“Any Anxiety Disorder.” National Institute of Mental Health. Last updated November 2017, https://www.nimh.nih.gov/health/statistics/any-anxiety-disorder.shtml.
“Attention-Deficit/Hyperactivity Disorder (ADHD).” National Institute of Mental Health. Last updated November 2017, https://www.nimh.nih.gov/health/statistics/attention-deficit-hyperactivity-disorder-adhd.shtml.
“Camel Case.” Wikipedia. Last edited January 30, 2020, https://en.wikipedia.org/w/index.php?title=Camel_case&oldid=938311603.
“Cognitive Accessibility.” MDN Web Docs. Accessed June 20, 2021, https://developer.mozilla.org/en-US/docs/Web/Accessibility/Cognitive_accessibility.
Collinge, Robyn. “How to Design for Color Blindness.” Usabilla Blog (blog). January 17, 2017, https://usabilla.com/blog/how-to-design-for-color-blindness/.
“Color Vision Deficiency.” Genetics Home Reference. MedlinePlus. Accessed June 20, 2021, https://ghr.nlm.nih.gov/condition/color-vision-deficiency.
Croxall, Brian, and Quinn Warnick. “Failure.” In Digital Pedagogy in the Humanities, edited by Rebecca Frost Davis, Matthew Gold, Katherine Harris, and Jentery Sayers. New York: Modern Language Association, 2020, https://digitalpedagogy.mla.hcommons.org/keywords/failure/.
Dacos, Marin. “Manifesto for the Digital Humanities.” THATCamp Paris (blog). Last updated March 26, 2011, https://tcp.hypotheses.org/411.
“Data and Statistics about ADHD.” Centers for Disease Control and Prevention. October 15, 2019, https://www.cdc.gov/ncbddd/adhd/data.html.
Department of Justice. “Final Regulatory Assessment, Final Rule—Amendment of ADA Title II and Title III Regulations to Implement ADA Amendments Act of 2008.” 2016, https://www.ada.gov/regs2016/final_rule_adaaa.html.
Department of Justice. “Workforce Investment Act of 1998, Section 506. Electronic and Information Technology.” August 6, 2015, https://www.access-board.gov/law/ra.html#section-508-federal-electronic-and-information-technology.
“Disability Impacts All of Us.” Centers for Disease Control and Prevention infographic. March 8, 2019, https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html.
Dombrowski, Quinn. “Towards a Taxonomy of Failure.” Quinn Dombrowski (blog). January 30, 2019, https://quinndombrowski.com/blog/2019/01/30/towards-taxonomy-failure/.
Doustdar, Parham. “The Tools of a Blind Programmer.” Parham Doustdar’s Blog. Accessed June 20, 2021, https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-programmer/.
“Facts about Speech Intelligibility.” DPA Microphones. March 3, 2021, https://www.dpamicrophones.com/mic-university/facts-about-speech-intelligibility.
Forlano, Laura. “Data Rituals in Intimate Infrastructures: Crip Time and the Disabled Cyborg Body as an Epistemic Site of Feminist Science.” Catalyst 3, no. 2 (2017): Science Out of Feminist Theory Part 2: Remaking Science(s), https://catalystjournal.org/index.php/catalyst/article/view/28843.
Goering, Sara. “Rethinking Disability: The Social Model of Disability and Chronic Disease.” Current Reviews in Musculoskeletal Medicine 8, no. 2 (2015): 134–38, https://doi.org/10.1007/s12178-015-9273-z.
Godden, Rick, and Jonathan Hsy. “Universal Design and Its Discontents.” In Disrupting the Digital Humanities, edited by Dorothy Kim and Jesse Stommel, 91–115. Santa Barbara, Calif.: Punctum Books, 2018, http://www.disruptingdh.com/universal-design-and-its-discontents/.
Graham, Shawn. Failing Gloriously and Other Essays. Fargo: University of North Dakota, 2019, https://thedigitalpress.org/failing-gloriously/.
Hill, Heather. “Universal Design: An Accessibility Solution for Digital Humanities?” IXD@PRATT. October 4, 2017, http://ixd.prattsi.org/2017/10/universal-design-an-accessibility-solution-for-digital-humanities/.
Kane, Will. “Anxiety ‘Epidemic’ Brewing on College Campuses.” University of California. April 22, 2019, https://www.universityofcalifornia.edu/news/anxiety-epidemic-brewing-college-campuses.
“Major Depression.” National Institute of Mental Health. Last updated February 2019, https://www.nimh.nih.gov/health/statistics/major-depression.shtml.
Matuzovic, Manuel. “Writing JavaScript with Accessibility in Mind.” Medium. September 19, 2018, https://medium.com/@matuzo/writing-javascript-with-accessibility-in-mind-a1f6a5f467b9.
Metts, Michael J., and Andy Welfle. “Standards for Writing Accessibly.” A List Apart (blog). January 23, 2020, https://alistapart.com/article/standards-for-writing-accessibly/.
Mlynaryk, Jenna. “Working Failures in Traditional and Digital Humanities.” HASTAC (blog). February 15, 2016, https://www.hastac.org/blogs/jennamly/2016/02/15/working-failures-traditional-and-digital-humanities.
Omeka Team. “Documentation Guidelines, Omeka S Enduser.” Last updated January 17, 2018, https://github.com/omeka/omeka-s-enduser/wiki/Documentation-guidelines.
Otis, Jessica. “Never Use White Text on a Black Background: Astigmatism and Conference Slides.” The Dev Log (blog). November 6, 2017, https://jessicaotis.com/academia/never-use-white-text-on-a-black-background-astygmatism-and-conference-slides/.
Penn State IT Accessibility Group. “Font Face on the Web.” December 18, 2013, https://accessibility.psu.edu/fontfacehtml/.
“Quick Statistics about Hearing.” National Institute on Deafness and Other Communication Disorders. August 18, 2015, https://www.nidcd.nih.gov/health/statistics/quick-statistics-hearing.
Radaelli, Lucas. “How Do Blind Computer Programmers Code?” Huffington Post. April 28, 2015, https://www.huffpost.com/entry/how-do-blind-computer-pro_b_7163674.
Rello, Luz, and Ricardo Baeza-Yates. “Good Fonts for Dyslexia.” Presentation at the Fifteenth International ACM SIGACCESS Conference on Computers and Accessibility, Bellevue, Washington, October 2013, http://dyslexiahelp.umich.edu/sites/default/files/good_fonts_for_dyslexia_study.pdf.
Rose, Katie. “When You Talk about Banning Laptops, You Throw Disabled Students under the Bus.” Huffington Post. November 27, 2017, https://www.huffpost.com/entry/when-you-talk-about-banning-laptops-you-throw-disabled_b_5a1ccb4ee4b07bcab2c6997d.
Scheinfeldt, Tom. “Why Digital Humanities Is ‘Nice.’” Found History (blog). May 26, 2010, https://foundhistory.org/2010/05/why-digital-humanities-is-nice/.
Stemler, Sam. “Top 8 Most Common Accessibility Issues to Avoid and Solve.” Accessible Metrics (blog). July 16, 2019, https://www.accessiblemetrics.com/blog/top-8-most-common-accessibility-issues-to-avoid-and-solve/.
Stevenson, Leeann. “Whitespace: Not Just a Waste of Space!” Callia Web. October 17, 2018, https://www.calliaweb.co.uk/whitespace-not-just-a-waste-of-space/.
Twitter Help Center. “How to Make Images Accessible for People.” Accessed August June 20, 2021, https://help.twitter.com/en/using-twitter/picture-descriptions.
United Nations. “Convention on the Rights of Persons with Disabilities and Optional Protocol.” December 13, 2006, https://www.un.org/disabilities/documents/convention/convoptprot-e.pdf.
Vision Council of America. “U.S. Optical Overview and Outlook.” December 2015, https://web.archive.org/web/20190501162429/https://www.thevisioncouncil.org/sites/default/files/Q415-Topline-Overview-Presentation-Stats-with-Notes-FINAL.PDF.
WCAG 2.1. “Understanding Guideline 3.1: Readable.” Accessed August 24, 2022, https://www.w3.org/WAI/WCAG21/Understanding/readable.
“WCAG 2.1 at a Glance.” July 2008, updated June 5, 2018, https://www.w3.org/WAI/standards-guidelines/wcag/glance/.
Weir, Kirsten. “Give Me a Break.” Monitor on Psychology. January 2019, https://www.apa.org/monitor/2019/01/break.
Williams, George. “Disability, Universal Design, and the Digital Humanities.” In Debates in the Digital Humanities 2012, edited by Matthew K. Gold. Minneapolis: University of Minnesota Press, 2012, https://dhdebates.gc.cuny.edu/read/untitled-88c11800-9446-469b-a3be-3fdb36bfbd1e/section/2a59a6fe-3e93-43ae-a42f-1b26d1b4becc.
World Health Organization. World Report on Vision: Executive Summary. Geneva: WHO, 2019, https://www.visionimpactinstitute.org/research/world-report-on-vision-%7C-world-health-organization.
“Writing for the Web.” Usability.gov. December 7, 2016, https://www.usability.gov/how-to-and-tools/methods/writing-for-the-web.html.