Making Accessible Educational DocumentsMaking Accessible Educational Documentsby John Brandt
Not all people are the same and not all people use technology in the same way. Some people, because of their disability, need specialized equipment and software called assistive technologies (AT) that allow them to participate, contribute and collaborate more fully. But unfortunately, many of these assistive technologies can get "hung up" by things other people do. This is especially true when dealing with digital documents. Sometimes these digital documents will simply not work with some of these assistive technologies and this will exclude people with disabilities from accessing their content.
In this article series, we will discuss how educators can ensure that the content they are creating or providing for students, their families, other educators, or the general public will be accessible to all. The first in the series will deal with "text documents," including word processor files and Portable Document Format (PDF) files. In future articles we will discuss other formats including video, audio, presentational, animations and special formats.
Documents created by educators come in many shapes and sizes. They may be web pages used to inform students and their families of past, current, or future activities. They may be actual curriculum pieces: notes, handouts, syllabi, tests, textbooks, outlines or reading materials saved in word processor or in Portable Document Format (PDF) files. They may be presentation materials made in PowerPoint or Keynote. Or they may be other students’ work in a NoteShare file or a multimedia attachment in a Learning Management System (LMS) like Moodle. All of these document types or formats have the potential of becoming inaccessible to people using AT.
In its purest form, "plain text" is the most accessible and adaptable way of presenting content. Just about all assistive technologies can import and "read" plain text. But the world would be pretty bland if everything was in plain text. So, we should expect that most content, be it a word processed document, a PDF, or web content, will have some degree of formatting and style features that makes it more appealing. It is the addition of these features that often causes issue with AT, so this is what we will focus on.
In most instances, the text document can very easily be made accessible by following some basic rules. Those rules fit into a nice acronym - H.I.T. The "H" stands for Headings, the "I" stands for Images, and the "T" stands for Tables. This is not to say that there aren’t other accessibility issues to be concerned about, but if the author attends to these three, they will be addressing the ones that often cause the most problems with users of AT.
Contrary to popular belief, the purpose of Headings in a document is not to make the font larger and more distinctive. The real reason is to create a semantic framework for understanding the relationship between and among the sections of content. The use of this semantic layout is essential for persons using AT.
When a person with a visual impairment, using a screen reader or some other AT device, reads a document, they most typically use the Headings to scan the document in exactly the same way a sighted person would scan it visually. Printers and typographers learned long ago that by changing the size, shape and spacing of the font, the reader can more easily semantically understand the organization of the document. The person with a visual impairment uses the hierarchical order of the Headings to semantically understand the document. Using a feature built into their screen reader, the user will simply jump from Heading to Heading to peruse the document. The hierarchical order of the headings cues the reader of the importance of the heading and the content that follows.
If you think of a typical textbook, the document starts with a title page that includes the name of the book and other identifying information (the name of the author, publisher, etc.). The most important information on that page is the title itself. For this reason, the title should always be Heading 1 and all other headings below this should be numbered Heading 2, 3, 4 and so on. While some will argue with me on this point, my general recommendation is to have only one Heading 1 in each document. My logic is that documents have only one Title.
In the typical textbook, there are usually a number of chapters and sub-chapters or sections. In our example, each of the chapter numbers and names would use Heading 2. Sub-chapters would then be styled with Heading 3 and sections within each would be Heading 4, 5, 6 as needed (Note: it is rare to see more that three or four sub headings in most documents). This is illustrated in Figure 1.
It is noted that different applications may call Headings by different names, but they all operate the same way. In Microsoft Word 2007, Headings can be found in the Styles section of the Ribbon. In Apple’s iWork Pages, the Headings elements are found in the Styles Drawer. And in Open Office Writer, the Heading can be found in the Styles drop-down bar.
Whether they are on a web page, in a PDF, or in a word processed document, images can present difficulties to many people using AT. Screen reading software, when encountering an image in a document, will announce the discovery by stating the word "image" followed by the alternative (or ALT) description provided by the author. Without the ALT description, the screen reader simply announces "image" leaving the user to guess what this means. This can be particularly problematic when the image in question is graphic text, that is, text embedded into an image such as in a logo. Even worse is when this image contains a hyperlink to some other resource. In these cases, without an ALT description, the screen reader user has to go to that new link to find out (or try to find out) what that resource is. It all makes for a rather confusing experience.
When creating web pages in HTML, the author is required to use ALT description for the image. But the author also has the option of using something called the "null" ALT attribute - that is ATL="" - which is a command to the screen reader to simply skip over the image completely. When creating other documents, whether they be word processed or PDFs, there is an option for adding a descriptive text to the image. However, unfortunately there is no capacity to make this a "null ALT" so all images must have a description.
Most images in documents are simply "pretty pictures" designed to "catch one’s eye" and to make the overall document more visually appealing. They may be used as placeholders, to fill in white space, or to simply attenuate the topic of the writing. But in most cases, they add little to the understanding of the document. So choosing an ALT description for a PDF document can present some challenges. The general consensus among the designers I know is to try to keep ALT descriptions short and to the point. Here is a more thorough discussion on how to write good ALT descriptions.
Finally tables, or tabled data, in a document can present challenges to users of AT if the tables are not constructed correctly. To understand a table, the reader must understand the meaning of the data in each cell and this is typically accomplished by the use of column and/or row headers. Most tables use the top row of the columns for this header information so word processors software packages, when they create a table, will often automatically assign this top row as the header.
For example in Table 1, the first column contains the list of months; the second column the number of cars sold. A screen reader will read this as: Month, car sales, Jan, 67, Feb, 56, etc. In other words, the screen reader will read each cell starting in the upper left corner and read across the page to the right and then down to the next row.
In a large table with many rows and columns, a person using a screen reader could easily become lost in the data not knowing what row or column they are on. By using the "Table Mode" and special commands commonly found in most screen reader software, users are able to navigate around the table in various ways (e.g., reading columns or rows separately). But if the layout of the Table is not correct, the screen reader user can easily get lost in a sea of numbers and disconnected data.
Table 1.
Month |
Car Sales |
Jan |
67 |
Feb |
56 |
Mar |
34 |
Apr |
67 |
May |
86 |
Jun |
56 |
Jul |
44 |
Therefore, tabled information in documents should generally be kept as simple as possible and the author must ensure that the layout of tables is constructed in such a way as to make the information understandable to all users. If a large complex table is required, it is best practice to publish this on a separate page in the document (or on a separate webpage if an HTML document). Ideally, a complex data tables should be kept in a spreadsheet application (e.g., MS Excel) and sent along as a separate document.
One last word about documents created on a word processor. Although used rarely, columns can present challenges to people using screen readers. This is particularly true when the columned content is converted into another format. We will address this issue in greater detail in a future article that deals with the use of desktop publishing software like Adobe inDesign or MS-Publisher.
The Adobe Corporation introduced the Acrobat product in 1993 as a means of providing a universal document format that would allow various files to be read on any computer, using any operating system. At the time, there were several operating systems in popular use. Add to this a number of competing word processors and desktop publishing applications and the introduction of a universal format made a lot of sense. Acrobat’s Portable Document Format appeared on the market around the time HyperText Markup Language (HTML) was introduced and had it not been for that, the WWW may have looked very different.
In the early years, the Portable Document Format (PDF) was basically a graphic image (PostScript) of a finished document. Using the free Adobe Acrobat Reader application, it was impossible to edit or modify a PDF file once it was created. Indeed, this was considered a desirable feature. The goal was to allow the author of a PDF to control the layout, design and content in much the same way the author of a printed documents could, but at the same time allow for the content to be viewed and read on any computer operating system.
The PDF has come a long way since then, and while one is still required to use a special reader to view the file, there are now a number of applications that will save and read a document in PDF.
Nearly all PDF document start their life as something else. In most cases they start as a word processor document, but they may come from any number of document-creating applications like MS PowerPoint or Adobe inDesign. You can also make Acrobat "forms" within the Acrobat Professional application. So in most cases, the creation of a PDF is actually a process of converting a document.
Converting documents into PDF format can be done by many different conversion solutions. The most robust converter of these is the Adobe Acrobat PDFMaker, a plug-in that comes with the Adobe Acrobat Professional suite. However, the Office Add-in: "Microsoft Save as PDF" does a pretty good job of converting Office files with few errors.
If you are using Open Office 3.1, the application has a built-in "save as PDF" feature. However, my experiments with this feature showed mixed results with most converted PDF documents failing to pass the accessibility test.
Similarly, you can "export" documents created in Apple's iWork Pages as a PDF. However, as of this writing, attempts at getting of Apple iWork09 to creating accessible documents have been unsuccessful. Pages in iWork09 appears to lack the capacity to add alternative descriptions to images. In addition, the files saved in the native Pages format cannot be opened by any other program. Thus, educators using Pages as their word processor will need to save these documents in Word format or RTF if they wish to share their documents digitally. PDF conversions made from Pages documents can be made accessible, however this requires additional steps in Adobe Acrobat Professional to edit them.
Once a document is converted into a PDF it is essential that the document be checked for accessibility. The best way to do this - apart from asking someone who is a screen reader user to proofread your document using a screen reader - is to use the Accessibility Checker wizard built into Adobe Acrobat Professional.
Adobe Acrobat Professional's Accessibility tool will check the status of the PDF and will provide a detailed description and tutorials to assist the user in fixing any accessibility errors that occur. It should be noted that while the testing process takes seconds to accomplish, the remediation of accessibility issues may take some time based upon the severity and number of accessibility errors.
There is not enough space in this article to provide step by step directions for testing, remediating and validating PDF for accessibility. However, the Maine CITE Program has published a series of articles on how to produce accessible digital documents. Many of the articles have tutorials, video clips and links to other resources to help educators achieve this goal. Please visit the Maine CITE Accessible Document website for more information.
---------
John Brandt is a web designer and technology consultant to the Maine CITE Program in Augusta. He can be reached at jeb@jebswebs.com
Maine CITE provides additional resources that can help you with your goal of creating accessible documents. http://www.mainecite.org/awd/
John Brandt is a web designer and consultant who works with the Maine CITE Program in the area of accessibility and universal design. He may be reached at jeb@jebswebs.com