By Victoria Rasmussen and Keaton Walker
Keywords:
World Wide Web accessibility, WebCT, blind, equal access, online education
Abstract:
In this case study the authors evaluate several common WebCT tools to determine their accessibility for blind students. We review the bulletin, quiz, my scores, calendar and path tools. The case study first describes the WebCT experiences of Keaton Walker, a blind college freshman at the University of Utah. In most cases, the descriptive comments include Keaton's first impressions of the tools and screens when using them without assistance, and then his impressions after receiving some explanation of the screens which were not comprehensible. We complete our study with recommendations and suggestions to improve the usability both for WebCT developers and individual designers/instructors.
The global, asynchronous nature of the Internet allows education to be more accessible to many people, and has the potential to reach even larger audiences as time goes by. The Internet offers many educational possibilities, especially for people with physical disabilities. For example, hearing impaired students can now participate in discussions and "chat" on equal footing with all students. Those who have mobility and geographical access issues can participate in learning communities from their own homes. However, the World Wide Web has a strong visual bias. This creates a unique set of issues for those who are visually impaired. The Internet provides some advantages for blind students, for example: various kinds of written communication such as email, news, journals, books, applications, bulletins and tests can be voiced. Computerized printed materials are read with speech output generated by a combination of a screen reading program and a speech synthesizer. Voice technology gives a blind student the ability to read his or her own course materials without having to hire a sighted person to read them. With increased awareness, a web page designer can boost the independence of visually impaired students, rather than provide roadblocks. Unfortunately, without some designer vigilance, web pages can be frustrating or even impossible for some students to use.
Because WebCT use has grown dramatically at the University of Utah during the last year, a staff member in the University of Utah Disability Services department had recommended that the Faculty Assistance Center, which manages the campus WebCT system, investigate the issues associated with use of WebCT by blind students. One student in particular, Keaton, is currently enrolled in a course which has extensive online materials, though they are not based on WebCT. He volunteered to evaluate WebCT course materials. He is also contributing insight gained from his experiences with the non-WebCT course materials.
Top
At the University of Utah, WebCT is almost entirely used to supplement traditional courses and not as a tool for fully online distance education courses. Faculty began offering course materials to students in Fall of 1998, so it is still relatively new to the campus. The tools in use by virtually all of our courses include the bulletin board, private mail, my scores, calendar, and the single page or path tools. We evaluate the test feature also, because we anticipate the use of tests and surveys to increase as people become more comfortable with the system.
We have created a sample course including the above features. The course is not a "real" active course, but includes standard design elements such as a banner, header and footer, and several pages of course content under the path tool. The sample test includes at least one of each type of question, and we use the bulletin board for some communication between the authors.
The course content is primarily text. Because content design varies greatly depending on the course and the content creator, we do not evaluate content so much as the design of the path feature. For information about general web page design, see the summary of W3C guidelines and several additional references at the end of this paper.
The WebCT course and materials have been created using Netscape on a PC. We review the course primarily with Netscape Navigator version 3.1, although using version 4.1 or higher eliminates a couple of problems as noted later. The Linx text-only Web browser has a few advantages, but is not always available on public computers. Version three of Jaws speech synthesizing software provides the speech output. (A newer version, recently released, may improve the readability of frames; however, the upgrade is not available to us at the time of writing.) Jaws is a standard synthesizer widely used by the blind, and the only product available on our campus.
A student, when "surfing" the WWW, has each new page read by Jaws, beginning with the location bar, and progressing line by line down the screen. He then has the option of using a standard PC-type cursor which works in the same manner for sighted folks: by tabbing from one link or field to the next link or field over the entire screen.
The Jaws cursor is necessary to read text without selecting it. The student uses this cursor to scroll, and to read selected areas of text on the screen. To move and position this cursor, the numbers on the keypad function as arrow keys moving from one "object" - a word, graphic, or box - to the next, in the direction indicated by the key. Once the Jaws cursor is positioned where the user wants, it can deliver a click just like a mouse. Keaton, the student gathering data for our study, describes this as moving from one "area of interest" to the next, skipping the "wastelands" of space and images in between. It is important to note that, to the non-sighted, there is no particular indication that there is more than one screen full of text. Unless a sentence is unfinished, or a thought incomplete, the student may not immediately realize the need to scroll down for additional information.
In order to limit the scope of our case study, we focus on five tools. We also set criteria for evaluating these tools. Students with physical disabilities often receive various forms of assistance to help them meet course objectives. We feel it is useful to evaluate WebCT pages with the framework of acceptability ranging from best - helps increase students' independence, to acceptable - can be managed independently after some orientation, or falls within the range of typical assistance required, to frustrating - something which is so confounding that the student doesn't know how to get assistance, or that requires assistance beyond that which is usually acceptable.
Our case study includes first a description of Keaton's experience with the opening screens and each of the WebCT tools we evaluate. In the second part, we make recommendations both for the WebCT developers and for course designers which might improve the accessibility of materials in WebCT. Finally, we include general Web design guidelines from W3C and a few other resources in Appendix A.
Our evaluation begins with the WebCT course listing page which is automatically generated by the WebCT system. At the University of Utah, categories are department names and there are about twenty-eight departments in the system. The image at the top is customized to include "University of Utah".
Our first observation, which applies throughout WebCT, is the lack of availability of the "alt" tag for images. HTML allows a programmer to provide a text label for WWW images. A sighted user can rest the cursor over an image and see a little popup line captioning or describing the picture. If the images are not shown, or if a person can't see the images on the screen, the "alternate" text replaces the picture. In WebCT, the screen reader detects an image, but can not describe the image or even indicate what it is for.
It is very easy for Keaton to locate the category in the list using the screen reader and tabbing to move from link to link on the page. Unfortunately, this feature is not consistent throughout WebCT. And, after clicking on the "Example and Test Courses" category, things get a little muddled.
A screen reader reads from left to right across a page. It does not detect visual borders such as columns or even lines in a table. Thus, as it read every link, what we heard was "category image Bambie's test course art chemistry image brent communication image image CTLE [pronounced not spelled out] test course English image default template ethnic studies example and test image image default template one courses..." and so on. Notice also that, because the category Example and Test Courses wraps onto two separate lines, the reader is unable to read it continuously - it reads "test", then keeps going across the page and gets to the word "courses" only after finishing the previous line on the page.
The page becomes much easier to understand once we discuss the layout of the page - Keaton can listen for the difference between a department name and a course name, and ignore the images by using the link to link option of his voicing software. Also, most students will bookmark the actual course home page and will not be required to use this page more than once.
The key icon for creating a course ID is not readable, and will not be recognizable to a blind student who requires it. The speech reader simply says "graphic" followed by a number.
The layout of the WebCT course home page in general is perfect for a screen reader, especially if the banner image can have an alt text tag. The header text reads normally from left to right, and it is easy to follow. In the sample course, text is positioned beneath the icons with four columns of icons across the page. Thus, the page reads "image image image image test one bulletin board private mail calendar of". If students use the link-reading cursor, their reader skips the images and just reads the text of each link.
As on the course listing screen, the issue of a text label which wraps onto two lines is also problematic here. Rather than just being a one-word title, the calendar tool is labeled with the text "calendar of course events". The "course events" part is on a separate line and therefore gets split up by the reader. Keaton had mistaken this as another tool to investigate. Again, after the page's appearance has been described, the page design is simple to understand.
The test feature performs well, with only a few minor problems. The top lines of the test page are a little bewildering. The screen reader does not recognize the box containing bullets for each question which change from red to green as each answer is recorded. It ignores these and says something like "answered, unanswered, one, two, three, four..." etc. Luckily, this information is not necessary to take the quiz, since it serves only as a visual reminder to the student of which questions have been completed.
The next problem is more difficult. The most common way for a person using a screen reader to navigate through a page is to press the tab key to move from link to link, or answer option to answer option. This concrete sequential method of moving works well for many blind people because they do not have a good idea of how the screen appearance is organized. The terms "page lay out" or "visually pleasing" hold little meaning for a person who as never seen the "page" to which they refer. Moving forward with tab, or backward with shift-tab provides a linear organization which is easy for unsighted people to conceptualize.
When the test page is first opened, tabbing from option to option is not supported. The first answer must be selected by clicking. For someone who can not see, this means fishing around the screen with the Jaws cursor.
Once the first click is made, everything changes. The test form becomes
active and can be easily navigated using the tab key. After these
initial difficulties are taken care of, the test is manageable. The
radio buttons and edit fields are nothing out of the ordinary, and
the combo box matching questions make sense after a little explanation.
The "Save Answer" button icons which appear after each set
of possible answers provide a handy way of keeping answer possibilities
separate.
The first page of course content in a path is an index page. Because this page lists only a table of contents composed of links, it is relatively easy to navigate. Once in the actual content page however, other issues arise.
The actual text presents no problems as long as it is not in columns. In the upper frame of all path pages the navigation buttons (which are parts of a single image) lack alt tags, and can not be used without assistance. The other buttons for the bulletin board, index, and my notes, also do not have alt tags. Fortunately, since they manifest as separate graphics, they can be labeled by the screen reader with a little sighted help. The labels stayed with the images in all paths and content pages, but they did not stick with the same images in other areas such as on the home page. One can tab to the various buttons if the browser is current enough.
Rather than the browser reading "Document: Done" in the bottom status bar, in the path it read "Course Content: Page 2/3" which is a helpful label.
We did not evaluate the single page tool, because the readability of a single page would depend entirely on HTML created outside of WebCT. General recommendations for web page design appearing at the end of this paper apply to content found under a single page tool.
The Bulletin Board is a rich feature, necessarily rather complex and somewhat variable. Though it is a powerful tool, it is doubtful that most people could start using it without a little introduction. Blind students are no exception; this tool requires some preparatory instruction before being completely usable.
Although it is simple to tab from one link to the next, when trying to read the screen completely (from left to right), the navigation buttons in a column on the left get interspersed with the subject lines and author lines in the message index on the right. This feature is confusing because most of the screen is filled with the message index and options, leaving little room for the message text. When a message is accessed, pressing the space bar appears to move to the next message, instead of scrolling down further in the same message.
As in the test and other features, we find here the same issue of hitting the enter key to activate a link versus having to click on it to activate it. Obviously, for a person who can not see where they are clicking, it is much easier to select an item with the tab key and hit enter. This works for the buttons in the bulletin feature, but not for the message links.
The ability to scroll with the space bar versus having to click on an up or down symbol also occurs in several places in WebCT. For the same reason described above, it is preferable to move from one screen to another using the space bar, rather than clicking on the down arrow in the scroll bar to read one additional line at a time.
When exploring the initial bulletin help screen, click-scrolling was necessary, while the space bar worked in some subsequent screens; more consistency with this navigation feature will help. The help screens work well overall because it is not difficult to tab from one link to the next to view additional help topics.
Due to the fact that the interface for the Private Mail feature is almost identical to the Bulletin Board, we feel that this information applies equally well to both.
The screen reading program represents the calendar fairly well. It is well organized and not hard to use with just a bit of preparation. The main page works especially well. The days of the week are listed across a line, and two lines below them the first row of numbers begins. Unfortunately, since the screen reader does not read the lines separating the calendar cells, it is unclear whether the first is lined up under a Sunday, or a Wednesday.
Using the Jaws cursor to move from one date link to the next, a student may use the enter key to access the date information. Although the new entry window contained a number of confusing fields, Keaton guessed correctly that the two tabbable options (which read as blank and blank), were the add and cancel buttons.
The main difficulty in the calendar tool is the "new entry" window. Tabbing is not supported when the new entry screen is first opened. Using the newer version of Netscape makes it possible to tab through the fields; however, like the quiz page, one of the fields must be manually clicked before the form becomes active. As in the my notes tool in the path, Keaton began typing immediately upon opening the window. He did not know that the edit field does not activate by default, and thus his calendar entry does not appear in the system. Without someone to alert him to the fact that his typing is not appearing on the screen, he assumes that it is going into the system as it should. Finally, there are fields labeled "req'd" and "opt'l" - recked? optal? The reader pronounces the abbreviations for required and optional rather than spelling them! In spite of these issues, the calendar remains one of Keaton's favorite tools.
As sighted and unsighted, the authors have very different experiences with the student scores feature. Quoting from Keaton's notes: "I appear to have gotten 100 points on my 'no midterm', 10 participation points and no final exam or over all grade. Tab goes to three possible links, although not the home button. The first two say 'space' and try to request files from the server when they are pressed. After authorizing the 'transfer' nothing changes. The third link is not voiced at all, and is an email link."
When literally "viewing" the same page, the home button is visible, and no other links. The scores Keaton reports are in fact from the header row, and reflect the amount possible, not the actual scores of the student. Further, even after floating the cursor over the screen, there is no clickable area. There is no email link.
If the row of assignments, tests and so on exceeded the width of the screen, it would not be readable. Without someone to indicate the need for the horizontal scroll bar, and some time to locate it by "feeling around" with the Jaws cursor, anything outside of the window would simply be overlooked.
This tool is the most difficult of all to use, especially since the column headings become completely divorced from the score in each column. Since someone else would have to read the screen, it defeats the purpose of having anywhere, anytime access to scores. Linx, which helps with some column issues, does not improve the readability of this feature. The column headings separate from the data because the information is in two rows rather than one.
Based on our evaluation of these most common tools, we feel that WebCT provides reasonable access for blind students. However, there are many cases where small changes could make big improvements in its accessibility.
Four design issues apply to the entire WebCT system. The first, lack of "alt" tags for images, is probably the most significant, particularly in the path pages where designers do not have the option of including text links along with the tool icons.
The second, the use of frames and tables for layout, is one which must be carefully weighed. In some cases, it might be acceptable to expect the blind to obtain some assistance in reading these pages - particularly since most screens require only an initial orientation, and then some reasonable, albeit time-consuming, exploration by the blind to interpret. An example would be the bulletin screen which conveniently provides navigation buttons, message index and actual messages all on one screen in a visually easy-to-recognize format. Altering this format sufficiently to make it user-friendly for blind students could eliminate considerable benefit currently enjoyed by the sighted.
In other cases, it seems correctional steps might benefit the unsighted student, without hindering the sighted. For example, the category and course listing screen might be made into two independent screens. A student can easily click the category, and does not seem to need the categories repeated when viewing the list of courses within a single category. If the individual courses in a category are listed on the screen alone, it will greatly simplify course location for the blind.
With only two columns, and a single row, Linx presents the content of the left column in its entirety before moving on to the right column. This overcomes the issues related to contents of two columns become intermingled. Unfortunately, with multiple rows and multiple columns such as those found in my scores, Linx does not present the information in any more coherent manner than Netscape or Internet Explorer.
The third area which applies to virtually all of the tools is the inconsistent ability to use the tab key to move from one button or link to the next, and the inconsistent ability to click links or activate them with the enter key. Our research suggests that this problem might be partly alleviated by using the most recent version of the Web browser.
As the authors reviewed screens together, it became apparent that having not seen the screen, Keaton did not distinguish between a button-type link (small gray box, with text command inside), and more traditional underlined text links, including icon title links and links such as those used for the bulletin tools. So, there is a little more consistency to the cursor's behavior than at first recognized. However, if there were a consistent rule to indicate which links were usable with the tab and the enter key, and which links needed to be clicked on, this would simplify the initial experience with the system for blind students.
The last function which causes difficulty in several places is the use of the space bar. In many cases of web design, the space bar is used to scroll onto the next screen. This function is not consistent in throughout WebCT screen. If the space bar is already assigned to perform a function, then allowing for the use of the page up and page down buttons built into the keyboard works nicely. Or make the up and down arrows on the scroll bar into buttons to which the regular cursor can tab; using the enter key once the arrow was selected will scroll the screen.
Since these pages are automatically generated, we have only one suggestion for the developers. The list of courses will be simple to read if, rather than refreshing the list of categories and adding the category contents to the same page, the script simply replaces the category list with the category contents list. This eliminates the need for students to mentally separate what they are hearing into two columns and somehow detect which words belong in which column.
For WebCT administrators, note that if you can keep category and course names short enough that they do not wrap to another line, this greatly simplifies their readability using a speech synthesizer.
In this case, the columns are understandable if the student uses the Linx browser - as long as they realize that the course listing is added below the category list. When one clicks the category link, the screen does not change at all, because the additional information is added on below.
The developers have created a home page template which is easy to customize into an accessible screen.
If the designer arranges the icons so that the text label is to the right, and makes titles of two or fewer words, or sets the icon layout to two columns only, the home page will sound pretty good without any orientation, e.g. "image test one image bulletin board, image private mail". This arrangement eliminates the need for orientation to the page appearance.
Note that it is important to include text titles for the icons - without them, the student hears only "image image image image" and has no idea what any of the images are, or what they do. It is important to provide text links in addition to image links whenever possible.
The testing feature is quite usable, especially with a little initial explanation. Even without that, however, Keaton was able to complete the short sample quiz with only one error. The most puzzling part of the quiz, the small box which was voiced as "answered, unanswered, one, two, three..." is easily ignored. Since it is a visual reminder to indicate to students which questions were answered or not, it has no meaning to blind students.
The WebCT developers might consider a format where each question would begin at the top of the screen (using an anchor tag, for example). This would prevent an unsighted student from associating the answer box with the wrong question, and would also help to keep all of the possible answers on one screen without requiring scrolling.
Designers could address the same issue by alternating question types - rather than placing all short answer questions together, try alternating short answer with multiple choice or matching. This would help blind students to distinguish one question and answer blank from the next.
In spite of these issues, Keaton likes the test feature because it allows more independence than a traditional paper and pencil test which must be read aloud to blind students.
The path feature is useful, especially because it allows course materials to be voiced by the computer rather than requiring a human reader such as is necessary for many textbooks and articles. Since neither the space bar or page down key cause the screen to scroll, it is difficult to read more than one screen of information at a time.
Developers might consider addressing the space bar scrolling issue, beginning with this section of the software where it is of critical importance.
Designers can alleviate some of the scrolling issues by trying to keep content on one screen rather than having many screens of content in one document.
The bulletin feature is the most difficult to use with no orientation. However, after receiving some instruction, and guided practice, it is usable.
The developers might consider one alteration to make it more intelligible using synthesized speech: move at least some of the navigation buttons from the left vertical frame so that they are above or below the message list (rather than mixed up with the message list when reading across the page). We imagine something like a typical Windows or Macintosh menu bar to minimize space usage. Four or five expandable "menus" could be listed horizontally across the top or the bottom of the window. The "expansion" of the menus can work in the same way as the message and options menu do currently.
Since individual designers are not able to influence the appearance of this screen, our primary recommendation to them is to provide some explanation of the feature and how it works. We agree that many students will need some introduction to this tool in order to be able to use it effectively, so some time in class to describe it could be helpful to everyone.
The calendar is the most easily used feature. It took the least amount of investigation and exploration to utilize, and requires no particular assistance. As cited in other recommendations, the ability to tab from one link or button to the next could be improved in the new entry window.
One other small suggestion for WebCT developers is to fill in the blank day squares in the first week of each month with an inactive character - the revised version of the top row of the calendar might read "* * * one two three" and so on. This would indicate, to a person who could not see the table's dividing lines, which day of the week the first falls on.
We find this tool the most frustrating. The difficulty of having column headings wrap onto two or even three lines is more or less necessary for the sighted person to see more columns in the window. However, the screen reader reads "first last student test participation name name no midterm slash one hundred" and so on. By the time it starts at the left and reads the name and scores, the student really has no hope of remembering with which column heading the apparently random numbers are associated.
Due to the spread sheet format of the data, we recognize that there
is little the developers can do to make this table more readable without
vision. We recommend that individual designers either force column
headings to be on one line by not putting a space between two words
in the headings (first-name for example), or that the designer simply
provide other means of accessing scores for blind students.
The W3C (World Wide Web Consortium) includes a working group called the Web Accessibility Initiative (WAI).
"The W3C's commitment to lead the Web to its full potential includes promoting a high degree of usability for people with disabilities. The Web Accessibility Initiative (WAI), in coordination with organizations around the world, is pursuing accessibility of the Web through five primary areas of work: technology, guidelines, tools, education & outreach, and research & development."
Their Website at http://www.w3c.org/WAI provides a list of several resource links. They have a longer document that provides discussion, rationale and specific coding guidelines for creating Web pages. Refer to the WAI Page Author Guidelines - Working Draft link for this information. They also provide ten Quick Tips which summarize the highest priority information.
The authors of the Quick Tips section remind us that the tips are meant only to help people remember some basic ideas. They recommend reading the complete WAI Page Author Guidelines to understand the principles behind the design.
Quick tips to make your Web site accessible to everyone, including people with disabilities, handheld devices & slow connections.
1. Images, Photographs & Animations: Use the alt attribute to concisely describe the function of all visuals.
2. Page Orientation: Use headings, lists, table summaries, and clear and consistent page structure to make pages quick to scan.
3. Image maps: Many people cannot use a mouse. Use client-side MAP to provide alternative text for ImageMap hotspots.
4. Hypertext Links: Descriptive link text improves access for those who cannot see. Ensure that each link makes sense when read alone.
5. Graphs & Charts: Summarize Content or use the longdesc attribute.
6. Audio & Video: Provide captions or transcripts of audio content, and text or audio descriptions of video content.
7. Scripts, Applets, Plug-ins: Provide alternate content for scripting, applets or plug-ins so that no important information is lost when unsupported or turned off.
8. Frames: Label each frame with title or name, and include a hypertext start-page in NOFRAMES element.
9. Tables: Avoid using tables to format text columns. Make sure cell-by-cell reading order makes sense for tabular data.
10. Evaluate: Validate the HTML & CSS of your site. Check accessibility with available tools, and with images, sounds & animations off.
Copyright © 1999 W3C (MIT, INRIA, Keio ),
All Rights Reserved
