Making Accessible Futures

Review of the Accessible Future Workshop at Emory University, April 10-11, 2015

Anne Donlon, Emory University

The Accessible Future workshop urged participants to make digital material accessible to audiences with visual, aural, and cognitive disabilities, and to advocate for accessibility at our universities. The two-day meeting at Emory was the fourth such workshop offered over the past year and a half, and was funded by the National Endowment of the Humanities Office of Digital Humanities. Jennifer Guiliano, George Williams, and Tina Herzberg organized the workshop, with Clay Jeffcoat, Jeremy Boggs, James Smith, and Cory Bohon also leading presentations. Attendees at Emory included faculty, graduate students, curators, librarians, instructional designers, and an Office of Disability Services staff person. Participants entered the workshop with diverse experiences in accessibility practices and knowledge of disability studies. But, judging from reactions during the workshop, they were united in learning many new things that ranged across topics of screen readers, cognitive disability, Deaf culture, HTML, CSS, WordPress, and Omeka.

Conceiving of disability as a continuum of states that people move through, rather than a straightforward, medically-defined binary of disabled or not, the presenters taught us methods to make digital content accessible. A wide range of potential audiences–not only people with diagnosed limitations of sight, hearing, attention, or mobility–can benefit from increased use of white space, transcripts, headings, and careful inclusion of images. If we pay attention to accessibility concerns, that effort can improve the overall design and composition of our online writing and projects. However, if we fail to make ourselves aware of the implications of our design decisions, audiences with certain disabilities will not be able to reach the material that we intend to circulate to a public.

Universal Design?

Throughout the workshop discussions, there was a return to the tension around the concept of “universal design.” It is a term taken from architectural design to describe how changes to improve accessibility can increase usability for users in general, while maintaining or enhancing the aesthetics of the design. George Williams, one of the workshop organizers and author of the chapter “Disability, Universal Design, and the Digital Humanities” in Debates in the Digital Humanities (2012), offered the example of the curb cut, which, as he says in his chapter, was designed to facilitate wheelchair users crossing the street, but “became recognized as useful also to other people such as someone making a delivery with a dolly, a traveler pulling luggage on wheels, a parent pushing a child in a stroller, or a person walking beside their bicycle.” Williams urged us to recognize the broad benefits of accessible design, while also raising questions about the “universal” in universal design.

The idea of “universal design” provoked questions for the group: who gets to define what is universally acceptable (and what are the colonial implications that attend such a decision)? And what happens when particular needs of populations are in conflict with one another?

Nonetheless, there were several moments when the point was made that attending to accessibility helps to focus the goals of a project. For instance, if one has a hard time coming up with alternative text for an image, perhaps that image doesn’t need to be included. Or, as Clay Jeffcoat said about Google’s “I’m Feeling Lucky Button”: “Does anyone use it? So why is it there?”

Another thread that emerged in discussions was that accessibility challenges can be thought of as generative constraints–i.e. what at first seems like a limitation can become something transformative. Similarly, an accessibility accommodation can be a space for creativity:

Visual description can also be a new kind of disability aesthetics. #AFAtlanta

— Ann Fox (@annfoxdavidson) April 11, 2015

While the creative potential of disability was not an explicit focus of the workshop, these contributions to the discussion suggested a further line of exploration for writers, scholars, and artists putting things on the web.

Making Accessible

In our roles as designers (in the words of George Williams, “surprise! we’re all making design decisions all the time”), we have a responsibility–as educators, communicators, and digital humanists–to be aware of the accessibility implications of our design decisions.

Several of the presentations instructed us on how to make online material accessible for several key populations. I’ve outlined many of the recommendations below, in the Practices to Implement Appendix.

Clay Jeffcoat demonstrated how he uses a screen reader to navigate content online. He slowed down the screen reader so that the uninitiated among us could register the meaning of the words that he was able to understand at a much faster speed. The screen reader moves linearly across a page, starting at the top, so getting to the main idea of a webpage can be difficult (whereas a sighted person can usually find the main content quickly, not stopping to read all of the navigational links and menus in the order they appear). He outlined practices in structuring the page, links, and images that make it much easier for a user of a screen reader to browse and navigate a page.

Jennifer Guiliano’s presentation on information density and the challenges it poses for people with cognitive disabilities continued on this theme. Navigating the web requires feats of memory, problem solving, and attention (passwords, location of menus and navigational links, content flow). She offered guidelines to address such challenges in web design, many of which seemed (from Guiliano’s comments and affirmed by comments in the room) to be good design tips in general: eliminate extraneous content, use topic sentences and whitespace, and simplify use of colors and images. Guiliano also presented on accessibility for deaf (hearing impaired) / Deaf (the Deaf community) audiences, emphasizing the difference between providing a transcription and a translation into sign language.

The second day of the workshop focused on hands-on applications of these accessibility practices, with sessions on HTML, CSS, WordPress accessibility-ready themes and plugins, and Omeka plugins.

Testing for Accessibility

When creating digital content, accessibility should be part of the design process and workflow. Guiliano encouraged creators to go through several rounds of iterative review, making adjustments based on feedback from outside viewers. Guiliano also recommended including a way for a user to report accessibility difficulties on a website. Jeremy Boggs introduced us to several testing tools, including WebAIM’s Accessibility Evaluation Tool (WAVE), and the command line tool pa11y. Participants broke into groups to evaluate a few sites with the WebAIM tool, which flags accessibility issues on the page, such as an image that is missing alternative text, or a lack or misuse of heading tags. A couple of major issues arose when we compared notes. Visualizations (for example those on Visualizing Emancipation) tend not to offer alternative ways to access the data. Web-based DH tools that run a server window, like Voyant, also do not offer alternative access for users who cannot see. Guiliano noted that command line tools, which are text-based, tend to be much more accessible.

In addition to making digital environments accessible, the workshop aimed to empower participants to become advocates for accessibility practices institutionally. Some ideas for doing so included asking for a digital accessibility policy, hosting training opportunities, surveying “peer institutions” to apply pressure to administrators, advocating within professional organizations as well as funding and accrediting bodies to require accessibility standards, and convening a group of stakeholders to be informed and implement such digital standards.

Future Accessible Future Workshops

Accessible Future will be holding another workshop in Fall 2015; keep an eye on http://www.accessiblefuture.org/ for application details.

The workshop was extremely informative, bringing together a group of participants whose varied experience and perspectives made our discussions lively and diverse. Anyone who puts content online (which likely includes anyone reading this review) should be aware of digital accessibility principles–both the concrete and the conceptual. The details were too many to include in the body of this review, but in the appendices of practical takeaways and further reading and resources I have tried to represent many of the key ideas raised. Accessible Future is urging an important intervention in the digital humanities and academic digital culture more broadly.

Appendix A: Practices to Implement

For screen reading technology:

• Link meaningful text.
  • A reader using a screen reader can jump among hyperlinks, but if the linked text is “click here,” instead of “information on the workshop schedule,” the text doesn’t help the reader to browse the content.
• Use headers (<h1>, <h2>, <h3>), and use them semantically.
  • Headers change the appearance of the text, but they also structure the text semantically. A reader using screen reading technology will move between headers to get a quick overview of the page. Don’t do what I have been known to do and use <h3> because you like the way it looks. Use <h1> for your first heading, and then use subordinate headings in number order. Using headers semantically, rather than as simply a formatting mark, will make your work more accessible.
• Use alternative text when you upload images. The screen reader will read the text added with the <alt> attribute, so make it informative. (If the image isn’t conveying information, you may want to question whether it needs to be included at all.)
• Use descriptive file names for uploaded media, so that the screen reader doesn’t have to read off a random string of alpha-numeric characters when it reaches the file.
• The abbreviation tag can provide the fully spelled out version of an abbreviation or acronym. For example: <abbr title=”Accessible Future”>AF</abbr>.
• Include skip navigation links, to enable the screen reader to skip over the menus at the top of a page to reach the main content.
• Label form fields within the html.
  • <p>Your Name (required)<br />[text* your-name] </p>
• Label rows and columns in tables, using the scope attribute.
  • Tables can also include an html summary attribute.

For deaf/Deaf readers:

• Provide captions and transcripts for audio-visual content.
• Be aware of the distinction between a translation (to ASL) versus transcription.

For readers with cognitive disabilities:

• Use high-contrast colors, and only use up to three colors. (This is also important for colorblind readers.)
• Limit dynamic content that blinks (like an animated gif), plays (like auto-launching video), or moves on its own (like an image carousel).
• Be aware of how many links you include, because it can be confusing or distracting for a reader to be sent in multiple directions.
• Use a standard, single font type.
• Remove extraneous content, such as sidebars of menus and widgets.
• Make ample use of white space.
• Label navigation buttons and links (“previous page, view book, view page”).
• Announce terminal actions, like delete, submit, save.
• Caption images. Provide transcripts for video and audio.
• Outline steps (“This is step 2 of 4”).
• Provide a wrapper to customize pages for different users.
  • For instance, the Inclusive Design Research Center has a “show display options” tab that allows users to change font size, colors.
• Offer density options. The IDRC also offers an option to “simplify,” which turns a paragraph into a bullet point of information.
• Do not use photographs or images as a background.
• Use topic sentences.

Tools for increasing accessibility:

• Use an accessibility testing tool to check the accessibility of a webpage.
  • Webaim’s WAVE tool.
  • Pa11y, a command line tool.
• Create a campus testing group.
• Provide a way for users who encounter difficulties reading or navigating the site to give feedback.

When working with WordPress:

• Search for themes with the tag “accessibility ready.”
• Use an accessibility plugin.

When working with Omeka:

• Omeka plugins
• When adding documents, don’t use proprietary formats, always choose open standards.
• Add alternative text to images.
  • Go to settings, click on security, enable that “Enable HTML Filtering” is disabled.
  • In the HTML editor, add alternative text to images in exhibits, using <img src=“image url” alt=“alternative text here”>.
• Access Keys
  • Provides keyboard shortcuts, like “c” for skip to content.
• PDF text
  • Automatically indexes PDFs, so they are searchable.
• Zoom It
  • Enables a viewer to enlarge and zoom in on images.

Appendix B: Readings and Further Resources