In my earlier post “Digital Collections and Accessibility”, I touched upon the considerations we would need to address when building or creating digital collections (or other things that rely heavily on utilizing images such as data visualization) for public use. Here are the questions I put down in that post:
“Given the ubiquitous nature of digital collections, the goal that these collections would be used as part of scholarly activities, and the library’s mission to disseminate the information as widely as possible, there is one aspect that many of us need to address when we plan for a digitization project: how do people with disabilities access these collections without getting lost? Can they also get the same access and benefit from our collections if they only rely on their screen readers (or refreshable Braille, or any other assistive technology)? Can people move around our website easily using just a keyboard (for those with hand-coordination difficulty who cannot use a mouse)?”
So: planning. Planning is an important part when incorporating accessibility into building a collection. Typically, building a digital collection starts with designing the metadata (PDF) and then proceeds to further development activities such as database design, content creation, data entry, and coding/front end development. Whichever process that we develop, we would like to see that the website is well designed and the information presented is useful for our audience (I am assuming that most digital collections created and made available are designed for web access, with an added bonus if they also employ a responsive design.)
If you visit digital collections developed by various institutions, you’ll see that they present their collections differently. Many would display the collections be like a catalog that shows an image, the physical description, and related information such as the owner, creator, and copyright statement at the minimum.) Some also include an interpretation of the object (think the label of an object or painting displayed in a museum.)
Regardless how the object is presented (by description or interpretation), accessibility considerations are still the same. The most common considerations: the web page needs to be properly structured by using proper headings; the flow of information presented on the page needa to make sense for screen reader users or keyboard-only users; search forms need to be properly labeled; images need to have alternative text (usually referred to as “alt-text”.) This is when the planning for the page design and coding becomes important.
Consider this page:
and consider how the flow of information would be read by a screen reader and how a screen reader user might hear it:
Typical screen readers read the information displayed as if the CSS is disabled; they read web content in the order that it appears in the code.
(Bonus: if you have not seen or heard how screen reader users interact with a website, you can view the recording of accessibility test of our e-resources page (.mp4) done by my blind student. We did this as part of our accessibility test routines for the library electronic resources.)
Both images above should be sufficient to give us ideas of how a sighted user might interact with the page and how a screen reader users might hear it. Our eyes can focus on and narrow down to a certain section faster while screen reader users need to listen to the whole thing first before they can work on distinguishing the part that provides the actual information of the object being displayed. Hence, careful planning when designing the metadata and the page is needed to make sure our collection is both useful and usable for our audience regardless how they access it.
A lot of data visualization rely on colored graphics when conveying the information. It is trickier to tackle because of the colors used and, unlike most images used in digital collections, data visualization conveys very rich information.
Consider this example with three different color representations:
By looking at the colors used on the image above, we can see that the information is grouped based on the region (South Asia, East Asia and Pacific, Africa, Europe, etc.) and the color density of each individual block reflects the population density of the area.
The second image shows how the visualization might be seen by those with the red green color blindness (protanopia), one of the most common types of color blindness. Here, East Asian and African regions are no longer distinguishable. Similarly, South American,Russian, and European regions are also no longer distinguishable.
This last image shows how those colors don’t really convey the grouping of the regions to those with total color blindness (achromatopsia, which is a rare condition but still exists.)
The point of these examples: do not use color alone to convey meaning.
As far as I know, there is no practical solution yet for making data visualization fully accessible. Several options that can help increasing the accessibility: supplement the color with text or provide summaries or text description right after the image (alt-text or image caption). If the description is too long to be listed on the same page, create a separate page and link to it. Similar to designing for digital collection, designing for visualization also needs careful planning.
Designing for accessibility for our digital collection or data visualization should be done as part of the planning phase. This would allow us to optimize the output of our work and eliminate or reduce the need to revisit the design for corrections later on. Careful planning on how we want to display the information and to convey the meaning of the graphics/images would benefit all of our users regardless how they access our collections.
Meloncon, Lisa K. Rhetorical Accessability: At the Intersection of Technical Communication and Disability Studies. Amityville, N.Y: Baywood Pub, 2012.
Pullin, Graham. Design Meets Disability. Cambridge, Mass: MIT Press, 2009.
Last month, Google announced the new no-captcha reCAPTCHA that is supposedly more accurate and better at preventing spams. We’ll see how this goes.
In the mean time, plenty of websites that employ Google’s reCAPTCHA still use the old version like this:
The problem with this reCAPTCHA is that it fundamentally doesn’t work with screen readers (among other things, like forcing you crossed your eyes trying to figure out each character in the string.) Some people pointed out that reCAPTCHA offers the sound version (see that little red speaker?) that should mitigate the problem.
For something to exist, it has to have a position in time and space.
And this explains why nine-tenths of the mass of the universe is unaccounted for.
Nine-tenths of the universe is the knowledge of the position and direction of everything in the other tenth. Every atom has its biography, every star its file, every chemical exchange its equivalent of the inspector with a clipboard. It is unaccounted for because it is doing the accounting for the rest of it, and you cannot see the back of your own head.*
Nine-tenths of the universe, in fact, is the paperwork.
Like many other academic libraries, our collection consists of not only print materials, but also electronic collections. Typical electronic resources can be those we subscribe to through a vendor (ProQuest, JSTOR, Elsevier, etc.), or ones that we produce in-house such as https://www.lib.msu.edu/exhibits/).
The typical outcome from these digitization projects are images, metadata, and text, represented either as an image of printed or handwritten material or as a transcript. We then create a Web presence for these outcomes, including features like search, browse, and perhaps some additional application to display and interact with the images. User interaction with these digital collections should be straightforward: users should be able to visit the site, search or browse, and read the information presented on the page with ease. We also want to make the presentation of these collections pleasing to the eye, with background color or images, font type and color, and consistent placement of the images with the associated metadata (image on the top with metadata on the bottom, or image on the left with metadata on the right, or the whatever design decision we make to present the collection.) We also want to make sure that our institution’s branding is visible. So we add the banner, image or logo of our institution, some navigation so visitors can also go to our main website, and footers to provide visitors with contact information, acknowledgement of the funder, link to the privacy statement, etc.
Eventually, we produce a set of rich interfaces, chock full of images, text, and links. And probably some audio, too, for a sound project.
Given the ubiquitous nature of digital collections, the goal that these collections would be used as part of scholarly activities, and the library’s mission to disseminate the information as widely as possible, there is one aspect that many of us need to address when we plan for a digitization project: how do people with disabilities access these collections without getting lost? Can they also get the same access and benefit of our collections if they only rely on their screen readers (or refreshable Braille, or any other assistive technology)? Can people move around our website easily using just a keyboard (for those with hand-coordination difficulty who cannot use a mouse)?
Consider these questions when you begin working on any digital humanities project. Data visualization is now being used a lot. Sighted users can review the image representations easily; we can distinguish the information by shape and colors. Mundane data that used to be presented as text can now have pretty face. Information can be conveyed faster because we can see the charts and colors right away without having to go through lengthy text. But how can those who rely on sound be able to infer the information from those charts? Can color-blind people distinguish the color palette that you use? How are you going to explain the conclusion of your charts “verbally”? These are areas that have yet be addressed fully. We still have a lot of work to do.