Accessibility of Online Course Materials
Though much of web content is simple (often poorly marked up!) HTML content, there is no doubt we are seeing a wider variety of data formats and increasingly interactive and dynamic web resources. Multimedia has made web-delivered educational content "richer" and often more complex, especially from the perspective of students with disabilities.
Instructors and content developers can create content without knowing whether the format they choose will work for their students. For example, they may create forms in PDF without any knowledge of how a student might fill out the form. Or they might scan a journal article to PDF without realizing that the scan creates an image with no actual text content that can be copied and pasted, searched or read aloud by a screen reader to enable access for a blind student. Instructors may create PowerPoint slides or documents in Microsoft Word and post them to the web or learning management system without realizing that HTML might have been a better choice, since properly designed HTML provides greater ease of navigation, simplify searching, and can be more effectively re-purposed in other formats for the student to use.
A Flash of Insight
Multimedia content, in particular Flash-based content and applications, is another beast that users with disabilities often contend with. While it is certainly possible to create inaccessible HTML, following basic markup principles will likely ensure that content is at least minimally accessible. This is not the case with a technology like Flash, in which the developer must be highly conscious of Flash's accessibility features, must enable them and program to them, in order to create accessible content and interactivity. Most Flash can be made to be accessible, but it is not a novice effort. In addition, there exist very few tools that, "out-of-the-box," will produce Flash content that is fully accessible to both the keyboard alone and to a screen reader. One will find that the majority of Flash content on the web has not been produced with accessibility in mind—a situation that commonly confronts students with disabilities.
Common Tools with Unpredictable Results
Instructors and instructional designers tend to use the tools at their immediate disposal, and these tend to be the standard complement of programs used on PC's and MAC's in educational settings—Microsoft Word, PowerPoint, Excel, Publisher, FrontPage, Adobe Acrobat, Photoshop, Captivate, TechSmith, Camtasia, etc. The majority of instructors and instructional designers do not have any formal training on how to use these tools. They tend to learn through experimentation or from peers, many of whom have no training either. Unfortunately, these common content creation tools tend not to create accessible content by default. To take a common example, what may appear to be the most intuitive way to create different text sizes for creating section headings in MS Word—using the font-size menu—does not create text that can be differentiated and "seen" as a heading by a screen reader user but using the "styles" facilities in Word to create a proper heading structure will.
So, it is possible to create accessible content with the common array of tools. However, this requires specialized training—a deep knowledge about the various types of accessibility and the potential access issues related to each tool. It is probably unrealistic to expect individual content creators to know about the specific sets of access issues facing each disability group and to try to account for each when authoring content with the wide variety of tools. In addition to the problem of multiple data formats publishable on the web, there are no commonly accepted guidelines indicating how these multiple formats should be posted within web pages or other digital resources. Each instructor and designer has their own idiosyncratic way of posting content to the web and their knowledge (or lack of knowledge) of HTML, the web's lingua franca, produces content with varying accessibility.
Best Practices Makes Perfect
All of this variation can make the experience of the web very different from digital resource to digital resource for a user with a disability. Though a sighted user may easily ignore the differences, a blind user, relying on a screen reader to navigate a web resource, can be dramatically affected. Screen reader users have very limited access to the web page at any given time. They will not be able to effectively navigate the page to locate a desired section of content unless the content creator has authored the page following certain markup guidelines and best practices. To take a basic example, if the page is not structured logically and hierarchically using properly nested headings, the screen reader user will not be able to "skim" the page for relevant content. He/She will have to read the entire page from top to bottom and will not be able to discover if an informational graphic contains relevant content unless the author has provided proper alternative text. And so on.
Let's give a few more examples to further illustrate. Without consistent markup, a student cannot predict what will happen when a link is clicked. Does the link open in a new window or on top of the same window? Does the link open a PDF document or some other propriety content? Does the linked PDF open within the browser window or in its native application? For multimedia content, the situation can be worse. Many multimedia players are capable of playing a variety of content formats. These players compete with each other for file type associations and can sometimes change the computer settings without the student's knowledge. As a result, the student may discover that her multimedia content is no longer played in a player she is familiar with (or even a player she can access). For example, many multimedia players can play MP3 audio files. Some blind students prefer using RealPlayer for MP3 playback. If the student or another user of the computer installs or even starts iTunes, she may set the program to be the default player, perhaps unwittingly. The next time the blind user tries to listen to an MP3, she discovers that a player she is not familiar with gets launched. It may be that the visually impaired user can fiddle around and discover a level of access that will allow for her access technology to use iTunes, but at a minimum the experience will be disorienting and time consuming.
On top of all of these issues, students may have different applications in which they are proficient, and they may purposely set up specialized configurations and other personalizations—in fact, this is very often the case with students with disabilities. Given that instructors and course developers can only control their own design process and have little direct influence on which applications a student uses to access content and zero control over the configuration settings within applications, we must ask what the instructor can do to minimize the possibilities for confusion, upset, and lack of access when designing a course. There is advice and best practices guidelines to help answer this question.