Proceedings: University of Washington Accessible Information Technology Capacity Building Institute

March 3, 2008
HUB 106B, UW Seattle campus

• Introduction
• Agenda
• Group Discussion Notes
  • Problems and Concerns
  • Solutions, Answers, and Promising Practices
  • Next Steps for the UW
  • Next Steps for the Accessibility Working Group
  • Next Steps for Vendors
  • Next Steps for Individuals
• Conclusion

Introduction

The University of Washington (UW) Accessible Information Technology (IT) Capacity Building Institute (CBI) was funded by UW Technology Services and the National Science Foundation (grant #CNS-0540615) through The Alliance for Access to Computing Careers (AccessComputing), which is directed by the Department of Computer Science and Engineering and DO-IT at the UW. The goal of AccessComputing is to increase the participation of people with disabilities in computing fields.

The CBI was organized in response to the growing array of UW programs, services, and resources that are enhanced or driven by cutting-edge IT. With the increased utilization of IT, it is critical that UW's IT be accessible to all students, faculty, staff, and visitors, including individuals with disabilities. The goal of the CBI was to engage the UW community in a discussion that will lead to improved capacity within the university to carry out its educational mission in a way that is accessible to everyone. The CBI was attended by thirty-five people from all three UW campuses. They included web managers and developers, IT administrators and service providers, librarians, purchasing and contract officers, disability services providers, and faculty members. Representatives from Microsoft and Adobe also participated in the event.

Agenda

The agenda for the CBI was as follows:

8:30am

Check-in and continental breakfast

9:00am

Welcome and individual introductions
Sheryl Burgstahler, Director, Accessible Technology & DO-IT
UW Technology Services

9:30am

AT and IT accessibility overview
Dan Comden, Access Technology Consultant
Terry Thompson, Technology Accessibility Specialist
Wendy Chisholm, Web Accessibility Specialist
UW Technology Services

10:15am

Break

10:30am

Accessibility for simple to moderate-complexity DHTML web sites
Cynthia Shelly, Senior Technology Strategist, Accessibility Business Unit, Microsoft

11:30am

Small group discussion:

• What do you perceive to be the biggest problems related to IT accessibility on your campus?
• What do you perceive to be the answers? Do you have promising practices to share? What types of resources do you need in order to address these accessibility problems?

Noon

Lunch

12:30pm

Groups report findings from small group discussion.

1:00pm

Accessibility in procurement: An overview
Terry Thompson, Technology Accessibility Specialist
UW Technology Services

1:30pm

Accessibility from a vendor perspective
Matt May, Accessibility Engineer, Adobe

2:00pm

Accessibility and the UW purchasing process
Suzanne Blais, Senior Contracts Manager, UW Purchasing
Dave McCone, Contract & Technology Manager, UWEO/Tech Transfer

2:30pm

Break

2:45pm

Small group discussion:

• What are next steps for (a) the university, (b) we the attendees of the CBI, and (c) you individually, to move forward in improving IT accessibility at the UW?

3:30pm

Groups report findings from small group discussion.

3:50pm

Closing remarks

Group Discussion Notes

In morning and afternoon sessions, the CBI included small group discussions in which participants organized into four groups and discussed the following questions:

Morning Discussion

• What do you perceive to be the biggest problems related to IT accessibility on your campus?
• What do you perceive to be the answers? Do you have promising practices to share? What types of resources do you need in order to address these accessibility problems?

Afternoon Discussion

• What are next steps for (a) the university, (b) we the attendees of the CBI, and (c) you individually, to move forward in improving IT accessibility at the UW?

Small groups recorded the notes from their discussions in the Special Interest Group (SIG) on Accessibility in IT Wiki (UWNetID required for access), then reconvened with the whole group to report their findings. In this way, all CBI participants had an opportunity to ask questions and offer comments to each reporting group.

A compilation of notes taken by record-keepers in the discussion groups follows. They capture some of the issues discussed and suggestions made. There was no attempt to reach concensus or to correct errors in perceptions of current and needed resources. Any opinions, findings, and conclusions or recommendations expressed in these notes are those of the participants and do not necessarily reflect the views of the National Science Foundation or the University of Washington.

Problems and Concerns

Lack of Awareness

• General lack of awareness about accessibility.
• Lack of knowledge of standards-based methods for designing web sites.
• Lack of knowledge about IT accessibility problems and solutions.
• Lack of understanding of the legal issues related to accessibility.
• Limited or no consensus as to approach for achieving accessibility across UW web sites (i.e., a standard solution).
• Need to increase awareness of resources available to developers at the UW.

Lack of Accessibility for Faculty and Staff

• Faculty and staff with disabilities want independence, not personal assistants.

Need for Accessibility and Usability in Design, Development, and Production Workflow

• There often is no particular time given during the project schedule where accessibility issues are addressed.
• There are serious usability problems with many web sites, even those that comply with accessibility standards. Usability testing often is not given priority status in the project timeline.
• Since the population of individuals with disabilities is relatively small, it can be difficult to find participants for usability tests.
• We need a group of assistive technology users with average skills (not just expert users) for accessibility and usability testing.

Lack of Resources (Time and Staff)

• We need a greater investment in infrastructure for supporting IT accessibility, including full time accessibility professionals. Currently accessibility, particularly in colleges, departments, and units, is assigned to individuals as a small percentage of their responsibilities.

Decentralization and Lack of Authority/Need for Official Requirement

• Libraries, acdemic departments, and service units, among others, are developing and maintaining their own web sites. Few have incentive to change without someone declaring that this is what they need to do.
• Some departments and units contract out web site development, often with no requirement for accessibility.
• Frequently, a faculty member gets a grant, and his/her teaching assistant creates a web site without considering accessibility during development.
• The UW does not have a formalized process to determine if your web site is accessible. An official checklist is needed to ensure accessibility.
• There is a need for web design policies to ensure inter-department, inter-campus consistency. The current solution is to limit the technologies that can be used (e.g. web sites at the UW-Tacoma campus are built with HTML and ColdFusion only).

Need for Better Resources

• There are so many accessibility resources it is easy to get overwhelmed. We need cliff notes.
• It would be nice to have a place to share good code that works well.

Specific Technologies

• Some units run their web sites through a content management system and every department has its own web developers. Good guidelines should be provided to these web developers to make sure the pages they create are accessible.
• Building complex web applications is already complicated and risky. Adding accessibility concerns complicates this process even more.
• Web 2.0 technology can be difficult to make accessible.
• Use of online forms is being encouraged to reduce paper consumption and in-person resources. However, this introduces a greater risk for accessibility problems that must be considered before/during development.
• Online communities may be using inaccessible tools to support their discussions and collaboration.

Video and Pocasts

• There is no central service or standard process for making videos accessible.
• Podcasting is being used in class or as part of class and is great for some students. However, it is unclear who should be responsible for captioning and transcribing podcasts, especially in units where there are few resources for this type of service.

Accessibility of Vendor Products

• Many questions and concerens were raised about the accessibility of products that are currently used at the UW, including content management systems, learning management systems, web email aplications, authoring tools, and communication tools. A central resource is needeed to inform the campus community whether certain software products, and/or the products that are developed using that software, have been tested for accessibility.
• There are concerns about the accessibility of external course content services, such as Aplia, in which content is developed and provided entirely outside the UW.
• Accessibility has not been a major consideration when purchasing enterprise tools.
• In libraries, there are concerns about how to deal with the accessibility of third-party databases.
• Vendors sometimes overstate accessibility of their products.
• "The Easiness Opposition" - technology often makes it easier to do what you want but does not do it correctly.

Accessibility of Classrooms, Labs, Computer Networks, and the UW Campus in General

• It is unclear who should be responsible for assistive technologies at the UW.
• Nebula does not support assistive technologies.
• Many students have their own hardware.
• There is insufficient communication about what users with disabilities need (i.e., which software and hardware would best serve their needs). Communication tends to occur only after there's a problem.
• There is no standard on campus for assisted listening devices. There are currently many different products, requiring different devices.
• There are no publicly available video phones for individuals who use sign language.
• Buildings are made accessibile during new construction and renovation, but interference from politics, lack of foresight, property ownership issues, design of sky bridges, and the proximity of railroad tracks make accessibility difficult.

Solutions, Answers, and Promising Practices

The following items were documented in response to the question asking for solutions to accessibility problems. Additional solutions are documented in the Next Steps section of this document.

Video

• Disability Resources for Students has the capability to do captioning. They have a separate budget for acommodating students. They generally provide services on demand.
• Services are available that may lower the costs of captioning (e.g., CaptionSync from Automatic Sync Technologies). However, a transcript still needs to be produced.
• Promising practice: UW Bothell Library & Media Center has a project to find closed captioned videos. Videos and DVDs are inadequately labeled as to whether they were closed captioned, so the library collected information from faculty as to which videos they were using in their classes, and tested those for availability of closed captions. If the videos did nont have captions, they either suggested alternative titles to the faculty member or ordered transcripts.

Web sites

• Add time into project schedules that is dedicated to addressing accessibility concerns.
• Promising practice: The UW Admissions web site project worked to comply with Section 508 standards for accessibility. They had a timeline of six months, during which they made changes by hand and used scripts to convert old code.
• Promising practice: The Catalyst team has worked with the Access Technology Lab in the past to test WebQ with assistive technology users.

Raising Awareness

• Suggest that sites promote their accessibility conformance with a "badge" such as the W3C Web Content Accessibility Guidelines Conformance Logos.

Education and Resources

• Web developers need to be taught standards, structure, semantic markup, and separation of content from presentation.
• Develop a step-by-step list of prioritized actions you should take to make web sites accessible. The instructions could one section for web sites and one for web applications.
• Integrate available assistive technology and accessible IT products into the UW ADA Access Guide, which currently focuses on mobility access.

Support for Evaluating and Testing Web sites

• Web accessibility consulting services are available through UW Technology. The best point of contact is help@u.washington.edu.
• A DRAFT Accessibility Evaluation Procedure has been developed by the AccessibleWeb@U group. There is currently a need for community involvement in updating this draft.
• AccessComputing has developed a checklist for creating an accessible department (see Equal Access: Universal Design of Computing Departments).
• Screen readers are available for testing web pages and software applications. The Access Technology Lab has licenses available for Freedom Scientific JAWS. Additionally, a growing number of free screen readers (e.g., Firevox) are available for download. More information about both of these resources is available at UW Accessible IT: Tools and Resources.

Solutions for Classroom Accessibility Issues

• Delivering of classroom audio via the web should be explored as a solution to the problems that stem from non-standard assisted listening devices.

Next Steps for the UW

The following suggestions were among those made by participants:

Raising Awareness

• Continue the centralized accessibility awareness effort, including use of the SIG Wiki to learn, communicate, and collaborate.
• Improve awareness of the IT Accessibility web site through increased publicity.
• Have poster about the SIG and working group at BizTech.
• Just having SIG is great. We should get as many people involved as possible.
• Raise awareness that accessibility is not just about the web, nor just about students. Promote the accessibility of software and hardware, including products used by faculty and staff.
• Consider hosting an accessible design competition with a big award ceremony, similar to the Accessible Internet Rallies organized by Knowbility. We would need criteria, a panel of judges, and funding.
• Consider t-shirts (e.g., on the front "Accessibility"; on the back "It's the law!")
• At satellite campuses, begin holding brown bag events to disseminate accessibility information and get feedback from staff, faculty, students, and other stakeholders on campus.

Education

• Provide and publicize more training on how to create accessible content.
• Start a workshop or participate in an existing workshop.
• Host design review sessions.
• Offer more flexible trainings with regard to time and space, especially for those at satellite campuses who don't have time to come to Seattle more than once per year.
• Organize end-user accessibility trainings or tutorials offered by vendors.

Tools and Resources

• Develop a library of templates for creating accessible web sites.
• Keep a finger on the pulse of technical developments that could improve accessibility (e.g., advances in speech recognition for automatically transcribing/captioning video or podcasts). Keep the UW community informed about these developments.
• Continue development and revision of an evaluation procedure for accessibility.
• Develop boilerplate language for IT contracts and RFPs.
• Provide examples of good design and good code via the SIG Wiki.
• Develop before and after case studies contrasting inaccessible and accessible web sites (e.g., for the Featured web site section of the UW Accessible IT web site).

Policy

• We would like to see some kind of top-down movement, statement, or policy on accessible IT.
• We need to develop a UW IT accessibility policy, with an enforcement mechanism.
• We could make Section 508 a part of the purchasing process (not only at the Purchasing Department level, but also at the internal departmental level).
• We need specific, standard, "blessed" (i.e., in some way official) language for accessibility requirements in purchasing.
• We could tie accessibility efforts to Section 508, which covers a wide variety of information technologies.
• We should consider the big picture: Ensure that access to technology is not impeded by physical or environmental limitations.
• We could require student Technology Fee proposals to include an accessibility component.
• Satellite campuses can adopt formal policies and prodedures relatively quickly. These could potentially serve as models for the UW Seattle campus.
• The head of UW Technology could issue a directive related to IT accessibility.
• Directors of IT at Bothell and Tacoma could issue directives or make official statements regarding IT accessibility.

Top-level Institutional Support

• Put central funding behind accessible IT, rather than expecting all UW IT departments to absorb the cost of supporting accessible IT.
• Consider the role of legal and equal opportunity offices in addressing accessibility questions.
• Consider the relationship between accessibility and other technology-related issues in which the UW's vulnerability has resulted in top-level interest and involvement (e.g., copyright, privacy issues, security).

Community and Culture

• Keep accessibility a high priority for the new Web Group.
• Promote how accessibility serves the needs of a population of users; reply to feelings that addressing accessibility is a burden; frame the effort as help, not enforcement.
• Share knowledge between campuses. The Seattle campus (as an older campus) could share pitfalls and lessons learned with younger satellite campuses. Conversely, younger, smaller campuses may have more success adopting formal top-down policies and prodedures (see Policy section, above) that could serve as examples for UW Seattle.
• "We, the attendees of the CBI, vow to continue to seek out knowledge and pester our vendors. Schralp on!"

Next Steps for the Accessibility Working Group

The Accessibility site, the AccessibleWeb lunch series, and the SIG site are all part of a collaborative community of people working on accessibility in UW IT.

• Undertake specific projects, with defined deliverables, to address the needs identified in this CBI. Developing an evaluation procedure would be an example of such a project.
• Build interaction, cooperation, and sharing among IT developers through a well-managed SIG, an active program of lunch events including guest speakers, and an up-to-date Accessibility Web site.
• Build processes that make it easy for IT developers to get useful advice and review of their projects, such as through discussion rooms on the SIG and the email list.
• Reach out to managers of IT developers to better understand their needs in relation to including accessibility in the service design process.

Next Steps for Vendors

The following suggestions were among those made by participants:

• Continue to participate in the accessibility discussions at the UW.
• Offer periodic trainings specifically on accessibility features of their products.
• Spread the word about accessibility issues specific to higher education through their blogs, such as the Microsoft Accessibility blog and Adobe Accessibility blog.

Next Steps for Individuals

The following suggestions were among those made by participants:

• Evangelize—tell everyone we know about accessibility.
• Participate in the community. Specific opportunities for involvement are promoted through the Collaboration on Accessible IT web page.
• Subscribe to mailing lists, especially AccessibleWeb@U.
• Review resources on the IT Accessibility web site.
• Assess whether our own web sites, software tools, and other IT are currently accessible.
• Take information from the CBI to upcoming meetings. Get accessibility on the radar of our departments, units, working groups, and peers. Find out whether we have a stated committment to accessibility; bring up possible future issues as we produce new web content, videos, and software applications.
• Talk to program and project managers about including accessibility in development timelines.
• Integrate accessibility and usability into the UW Technology project management portal.
• At the beginning of a project, simply ask where we will make time to address accessibility.
• Use or modify the W3 checklist to develop clear standards within our groups.

Conclusion

In her opening statements, Sheryl Burgstahler identified milestones in the history of IT accessibility support at the UW, starting with the formation of the Micro Support Group in 1984. The current UW Accessible IT CBI marks another significant milestone in this history, as it is the first time a broad cross section of representatives from across the UW have gathered for a full day of discussion on IT accessibility issues that pertain specifically to our university. As the session concluded, participants enthusiastically expressed, both within their small group discussions and privately on CBI evaluation forms, a commitment to helping move this issue forward.

Potential clear, attainable next steps have been identified and documented in these proceedings. Groups have been established for collaboratively continuing the work, and tools are in place to support that collaboration. When asked on the CBI evaluation form to assess their confidence as to whether they were now able to consider accessibility in products that they develop and/or procure, 84.6% of respondents said they were either "confident" or "very confident." When asked whether they would implement elements of what they had learned, all but one of the participants responded "Yes." When asked whether they would consider attending a similar follow-up event, and, if so, how much time must lapse before they would consider attending, all respondents said they would consider attending a follow-up event after some time had passed (30.8% would attend after 3 months, 45.1% would attend after 6 months, and 23.1% would attend after one year).

Until the next CBI is organized, there are many steps that can be taken, both small and large, both individually and collectively, as part of the growing UW accessible IT community.