Access to education has always challenged students with disabilities. The increase of online instructional materials presents new opportunities—and possible barriers—for accessibility in higher education.
Despite rising numbers of students with disabilities in higher education, colleges and universities have not ensured accessibility of online learning environments for all students.1 To support the development of accessible online educational sites, the Accessibility Institute at the University of Texas at Austin created the Student Web Accessibility Project, in which a team of student evaluators identified accessibility concerns in instructional Web sites on campus. Their findings suggest a need for more training and awareness of accessibility issues by developers of online instructional sites whether they are faculty, administrative assistants, designers, or others.
Federal law, including the Rehabilitation Act of 1973 and the Americans with Disabilities Act of 1990, requires that university programs and activities be accessible to qualified students with disabilities. Specifically, Section 504 of the Rehabilitation Act2 states that public entities receiving federal financial assistance, which include colleges, universities, or other postsecondary institutions, cannot exclude qualified individuals with a disability from the participation in or benefits of programs and activities on the basis of their disability.
As universities become more digitized, accessibility of administrative and educational Web sites becomes a higher priority. The U.S. Department of Education's Office of Civil Rights (OCR) has consistently held that accessibility requirements apply to instructional materials provided online as well as in print. The OCR has issued numerous legal opinions concerning accessibility and higher education, signaling that colleges and universities have a legal obligation to meet accessibility standards.3
For Web-based content and tasks, two sets of standards/guidelines help define what makes a Web site accessible: Section 508 of the Rehabilitation Act of 19734 and the Web Content Accessibility Guidelines (WCAG).5 Section 508, which requires federal agencies to provide access to and use of information, data, and services to individuals with disabilities who are members of the public or federal employees, outlines a set of 16 provisions that specifically address Web-based information or applications. These 16 provisions were directly influenced by WCAG. Developed by a working group within the World Wide Web Consortium (W3C), WCAG offers an extensive list of checkpoints and techniques for creating accessible Web content.
Approximately 8–12 percent of students attending institutions of higher education in America have a disability.6 In 2003–2004, for example, 11 percent of undergraduates reported having a disability.7 Although physical access has improved on campus, little attention goes to technological access. Assistive technology helps increase access to the Web, but it alone cannot reduce the barriers to accessibility. Careful consideration must be given to how content is presented to users with and without disabilities.8
Organizations typically look to Section 508 or WCAG based on their own policies, resources, and legal requirements. Compliance with these standards and guidelines informs the development of accessible Web sites, that is, sites in which "information has been made available for use by just about everyone, including those with disabilities."9 However, accessibility does not just benefit those with disabilities. Accessible content improves the availability of information for all users, such as when accessing the Web with a mobile phone or in a noisy environment.
Educating designers about accessible design seems to be a key component for change because current Web interface design can accommodate issues of accessibility.10 The same logic holds true for developers of courseware applications, which are becoming more prevalent in postsecondary education instruction. These tools, which are designed to accommodate instructors who are not programmers, often do not support development of accessible course content.11 Since accessibility issues associated with technology originate in the development phase, barriers to accessibility can be eliminated with more rigorous initial user evaluation.12
Universities are beginning to endorse accessibility policies,13 yet ensuring accessibility in instructional content can be challenging. Research has shown that only a small number of university Web sites meet even the minimum standards for accessibility.14 The implications of meeting the challenge have long-term gains, however. Wattenberg determined that educational success, employment, and income were significantly affected by access to technology and the Internet.15 The purpose of educational software and applications is to support learning. Thus, it needs to be inclusive, taking into account the various ways students learn and interact with the computer.16 Increased accessibility improves independence and efficiency in the lives of users with disabilities.17
In education, most technologies are biased toward "a 'typical' learner, who sits at a desk using conventional keyboard, mouse, and monitor."18 Unless processes that support the development and review of accessible instructional Web content are in place, the online approach to education can present barriers to learning.
In response to current guidelines and legislation, UT Austin's accessibility policy, and the results of our office research at the Accessibility Institute, we designed a project to offer accessibility consultation to campus departments that create online instructional content. The university's accessibility policy focuses on compliance with Section 508 as a minimum standard. Therefore, the project initially focused on the Section 508 standards. This article reports on the project's methods and results, as well as the collaborative model created to promote the development of accessible instructional resources on campus.
A Model for Collaborative Evaluations
The Accessibility Institute is a research organization located on the UT Austin campus. The institute focuses on research of accessibility issues and offers training and consultation services to promote all aspects of Web and software accessibility for the university community. With the move to provide more educational content on the Web, we developed the Student Web Accessibility Project specifically to support accessibility of instructional resources on campus. The purpose of the project was to
- perform assessments of online instructional resources against Section 508 standards for Web accessibility,
- develop resources to support the creation of accessible online course materials, and
- assist developers in integrating accessibility into project planning and design of instructional sites.
During the 2005–2006 academic year, the Accessibility Institute received an internal technology grant and hired and trained a team of students to identify and investigate accessibility issues in a sample of instructional sites.
The team consisted of one graduate and three undergraduate students from diverse cultural backgrounds and age groups, with and without disabilities, from a variety of academic disciplines. All had some experience with computers; one had some experience with Web development, and one had experience with adaptive technology and used a screen reader.
Few students know much about accessibility whether they have a disability or not. As a result, all of the students on the team were new to the specific concepts of Web accessibility and accessibility standards and guidelines.
The team also included a staff member trained in Web accessibility from the Accessibility Institute (Kay Lewis) as the project director. The project director supervised the students' work throughout the project.
To identify Web sites for evaluation while maximizing team resources, we approached departments on campus that developed instructional sites and had previously expressed an interest in accessibility consultation. The interested departments identified the instructional sites they wanted evaluated and provided the sites' locations. Often departments requested evaluations of multiple sites, which tended to exhibit similarities. For example, one group of sites was developed using Flash. For another group of sites, the developers primarily used a content management system. A third group of sites emphasized the use of graphical content and multimedia and were developed through a collaboration between the department's instructional technology group and faculty.
The site developers varied in their knowledge of accessibility and experience in integrating it in their work. One team had worked with our office extensively, received accessibility training, and begun to integrate accessibility into their projects. Another group consisted of instructors who knew little about accessibility. Their department was trying to manage accessibility through a content management system.
Because the team members had no previous knowledge of accessibility issues, their training began with some materials that introduced accessibility concepts, the legislation related to Web accessibility, the accessibility standards and guidelines, and some hands-on activities with JAWS, a screen reader frequently used on campus. Some students also started exploring information about HTML. Learning was self-directed, with support from the project director and group discussions. Throughout the project, the students researched and shared other documents and Web sites that advanced their collaborative understanding of accessibility. This team-directed approach created an environment of mutuality and reciprocity in learning.
The team discovered that accessibility concepts and guidelines were easier to understand and discuss when applied to concrete examples in Web sites. Throughout the process of evaluating Web sites, the team continued to construct their knowledge of accessibility. To begin learning about accessibility evaluations, each team member observed the project director conducting an evaluation.
The collaborative evaluation process facilitated checking each student's level of understanding because team members could question each other and the project director about inconsistencies they noticed. In addition, the project director reviewed all the reports and summaries before they were delivered to the developers to ensure the students accurately and clearly explained the accessibility problems and possible solutions.
Once referred, a department site was assigned to a member of the team. She began the initial report by completing her evaluation using the Section 508 standards as a basis. Next, she passed the report to another team member, who then added her feedback.
The students' first evaluations of a site used an accessibility rubric from WebAim19 that offered a structured method for using tools available in the Accessibility Toolbar.20 This toolbar, which works with Internet Explorer, offers a number of ways to examine Web sites with accessibility tools.
As they became more comfortable with the standards, team members began to incorporate multiple methods and tools for evaluation, such as using the automated tools offered on the Accessibility Toolbar, reviewing targeted portions of the code, and interacting with the site using JAWS. Reports generated included positive comments about the site, observations, noncompliance issues, usability issues, and recommendations.
After the sites were evaluated individually, each team member added her observations, recommendations, and feedback to the report. The group and project director then discussed the report and answered questions or talked about areas of confusion. In later evaluations, although the reports were not generated by the entire team, sites continued to be evaluated by more than one team member. This collaborative evaluation process resulted in a more thorough summary of a site's accessibility issues because it allowed for multiple views of a Web site and took advantage of the strengths of individual team members.
Clients received either summaries of the results or more formalized versions of the reports depending on their needs. The team also offered to meet with departments to review results or consult on other projects. The departments then decided what steps they should take next—whether to implement recommended changes now or later, provide more sites to evaluate, recommend accessibility evaluations to different departments, or do nothing.
Increased Awareness of Accessibility Issues
The process of learning about accessibility included opportunities for the team to brainstorm about effective solutions to challenging areas of noncompliance. In these cases, the team reviewed a Web site together and interacted with the site in the areas of concern to better identify and discuss the problems. When necessary, team members conducted additional research on topics related to the areas of concern.
Throughout the process, students reflected on their experiences, and their knowledge of accessibility and compliance continued to expand. The feedback delivered to the departments increased their accessibility awareness, and based on conversations with the developers, the department's interest in implementing accessibility changes grew.
The student team evaluated 99 Web sites, of which 12 (12.1 percent) met all of the Section 508 standards and thus were considered accessible. The remaining 87 sites (87.88 percent) had documented areas of noncompliance with between one and 11 of the 16 standards and thus failed to comply with Section 508. Table 1 summarizes the number of sites with the most frequent accessibility issues according to the Section 508 standards.
|Most Frequent Accessibility Issues
|No. of Sites
|(o) A method shall be provided that permits users to skip repetitive navigation links.
|(a) A text equivalent for every nontext element shall be provided (e.g., via “alt”, “longdesc”, or in element content).
|(m) When a Web page requires that an applet, plug-in, or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with Â§1194.21(a) through (l).
|(n) When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
|(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
The accessibility issues identified in the evaluations varied in complexity and in how commonly they were used on the sample of sites. For example, at least 25 of the sites were developed using Flash. Flash sites presented a unique evaluation challenge because they did not allow evaluation by examining the code or using automated tools. The Flash sites that had accessibility problems were identified using a screen reader, but identifying the cause of the problem was difficult. Typical problems in Flash content included "no keyboard access, requiring the mouse to move objects, unlabeled buttons that the screen reader could not identify, illogical reading order of content, audio that played simultaneously with the screen reader, and graphics that had no text equivalent."21
Close to half of the sites were developed through a content management system. The instructors could choose a template for their class site, which allowed for consistent presentation and basic accessibility features without requiring the instructors to have knowledge of Web development. These sites also had common issues of noncompliance, however, which often were intrinsic to the template used to develop them. "Some accessibility problems we observed were (1) no method for skipping repetitive navigation, (2) graphics in the content with no alternative text, (3) form fields that did not have meaningful labels in the markup, and (4) confusing heading structure in the content."22
Development of Online Resources
In working with these instructional sites, the team researched and created handouts about topics relevant to the sites evaluated that had a potential accessibility impact. Some of these topics included blogs, content management systems, forms, graphics, headings, Java, Flash, Multiuser Domain Object-Oriented Environments (MOOs), Portable Document Format (PDF), and portals. These handouts are available on the Accessibility Institute's Web site at <http://www.utexas.edu/research/accessibility/research/summary/swat/
Helping developers integrate accessibility into their projects was the most difficult part and also led to the fewest observable results within one year. The departments had different levels of resources to devote to accessibility changes. One team of developers designated a student developer from their office to work with us, for example, and to be responsible for accessibility. Basic accessibility changes were made to a few sites, but the student worked in another building, and we had difficulty establishing a close working relationship with the student. The necessary training did not happen. The department continued to consult with us about accessibility issues as they had resources to address them, although the student collaboration did not continue.
The team of developers already incorporating accessibility in their work scheduled meetings with us regularly to discuss their projects and potential accessibility problems. They had already started designating resources for achieving accessibility and continued to progress toward accessibility in their projects.
Our site evaluation model incorporates automated tools and manual reviews, which proved to be the most effective approach. The strength of the evaluation process arose from the collaboration in training, evaluating sites, and constructing feedback.
Based on our study results, we crafted best practices for employing a collaborative approach to Web site evaluations. The model can be adapted as new students join the team. New students start with training, whereas returning students may start with soliciting clients. If clients have already been identified from previous semesters, student team members may start with evaluation.
Table 2 reflects the key points of the process reflected in our model. The specifics can be adjusted to meet the needs of different organizations, for example, by using different accessibility evaluation tools or the most relevant accessibility guidelines.
|Web Accessibility Evaluation Model
Answering the following questions:
Collaborative Approach to Accessibility
A primary lesson from the Student Web Accessibility Project was the importance of working collaboratively in learning about accessibility and conducting accessibility evaluations. The collaborative approach involved discussing sites and asking questions as a group, generating team reports, and sharing accessibility information. Members of the team reported that the interactive dialogue increased their understanding of accessibility. The many benefits of this approach included:
- Building on individual strengths such as a person's knowledge of JAWS or HTML
- Integrating multiple perspectives when identifying problems and possible solutions
- Creating a reliable process to identify accessibility issues
The benefits of collaboration also apply to the team's relationship with developers of instructional sites. Since the developers appeared to have different levels of knowledge of accessibility, resources to apply to achieving accessibility in their Web sites, and understanding of how to integrate accessibility into projects, regular communications to facilitate questions and sharing of information seemed helpful.
Accessibility in Educational Sites
The low compliance with Section 508 guidelines among our sampled sites indicates the need for more education and awareness of accessibility for developing instructional content. The specific focus on instructional sites is important because educational content presents some unique aspects to consider in relation to accessibility. For example, the sites we evaluated often emphasized interactive options and had expectations of student input; that is, the sites offered Flash applications, used blogs, or applied dynamically generated Java content. These sites were not all generated by instructors proficient in Web development, so their knowledge of accessibility was potentially limited even more.
One interesting consideration that seemed specific to instructional sites was the need to adapt accessibility features so as not to hinder the educational purpose of the content. For instance, one of the referred sites offered video clips of French dialogue to practice auditory comprehension of the language. Section 508 would suggest that synchronized captioning should be supplied with this multimedia. The instructor of the class had considered accessibility, however, and decided that offering captions would change the intention of this instructional content for the course. The instructor purposely chose not to offer captions but included the rationale for this decision on a page of the site.
One limitation of this model is that the pattern of observed results is likely influenced by the sample—the departments that referred sites. We worked with departments already interested in accessibility and, therefore, more likely to have already included some accessibility features in their sites. Evaluating groups of sites that used the same development processes also could have influenced the overall evaluation results because the development similarities across groups of sites, whether using Flash, a course management system, or visual content, resulted in clusters of similar areas of noncompliance.
Including only departments that expressed an interest in accessibility was an attempt to avoid providing unsolicited feedback to developers who might not appreciate it. In the future, the model will need to include methods for approaching developers who may not be aware of accessibility problems. The offer of accessibility support must be presented from an encouraging, positive perspective so that it is not seen as a criticism. Any evaluation of institutional risks exceeds the scope of our project, and the student team has no authority to consider the legal ramifications of noncompliance. Working cooperatively with departments is the basis of our work.
Another area to consider in implementing this model is the complexity of Web accessibility. Resources have to be dedicated to studying it and understanding it on the front end. This is true for our team of students as well as the developers themselves. Each individual's available time, resources, and motivation for learning about accessibility can influence this collaborative model's success.
The Student Web Accessibility Project team conducted accessibility evaluations of a number of instructional sites with the purpose of improving the online educational experience and usability of instructional content for students with disabilities. University Web sites are typically not accessible and could benefit from more awareness of and training in accessibility issues. The first year of the project focused on awareness and identification of the need for accessibility in instructional sites, as well as the generation of online resources. However, few accessibility changes were implemented due to the differing levels of accessibility knowledge and resources available for implementing changes.
The collaborative aspect of the model was particularly effective for learning about accessibility and applying a process of evaluation. As developers become more aware of accessibility issues, this collaborative approach may need to include them to better assist their integration of accessibility into instructional Web site projects.
In the future, the Accessibility Institute will continue to train students to evaluate accessibility of instructional Web sites through the Student Web Accessibility Project in order to raise awareness and encourage the development of accessible online instructional resources on campus. Groups interested in conducting their own accessibility evaluations of instructional Web sites can replicate and modify this model for their own purposes.
Implications for Future Research
This project highlighted several areas for follow-up in the field of Web accessibility. In reviewing the sites and the issues related to Section 508, we also observed issues affecting users with disabilities that were not addressed by Section 508 standards. Further investigation of these issues may identify areas where consideration of other accessibility guidelines may be needed or determine which areas of usability are particularly important for users with disabilities.
Additionally, accessibility is as much about the user as it is about the site. Further research into user approaches can help increase understanding about learning and educational interaction through the Web. This project serves as a foundation for future research into Web accessibility in higher education.