Presentation Summaries

Hadi Rangin gives a presentation on working with vendors at the Accessible IT CBI.

Overview of IT Accessibility Issues

Presenter: Sheryl Burgstahler

In order for IT to be considered accessible to and usable by people with disabilities, it must afford those individuals the opportunity to acquire the same information, interactions, and services as people without disabilities. People with disabilities must be able to obtain and use information presented as fully as people without disabilities. The Department of Justice’s Office of Civil Rights (OCR) and courts of law have resolved civil rights complaints with respect to IT access for individuals with disabilities at more than a dozen postsecondary institutions in the United States. How can these resolutions help guide other campuses in making IT (e.g., websites, videos, online learning) accessible to students, faculty, staff, and visitors with disabilities?

Resolutions to these OCR complaints suggest that institutions of higher education consider

  • conducting accessibility audits and developing corrective action strategies
  • developing and disseminating an accessible IT policy
  • creating IT accessibility standards
  • providing training and education
  • developing procurement policies and procedures
  • developing and publicizing grievance procedures
  • addressing accessibility within already developed, procured, and used IT, including websites, LMSs, classroom technologies, and purchased software

The UW has come a long way in spearheading efforts related to making IT accessible since 1984, when IT accessibility support was embraced by the Microcomputer Support Group under what became Computing and Communications (now called UW-IT). In 1990, the Access Technology Lab opened, providing access to assistive technology, and, in 1992, the DO-IT Center received National Science Foundation funding to provide complementary, nationwide efforts. A UW accessible web user group started meeting regularly in 2002, UW hosted a nationwide IT accessibility CBI in 2006, and UW-IT began using Siteimprove to test the accessibility of campus websites in 2011. Since 2012, efforts at UW have increased with the creation of an IT accessibility campus-wide task force, the launch of a proactive initiative to test website accessibility, a draft of wording to include in purchasing questions for IT vendors, and a signed contract with Automatic Sync for captioning.

UW-IT continues to grow and create more promotion, tools, and procedures about accessibility. In the ideal state that we strive for, we would have

  • a campus-level task force with annual reports
  • a guidance website
  • standard accessible web page templates
  • IT accessibility consulting/testing services
  • accessibility included on IT development and support teams
  • collaboration between vendors and UW staff for creating and purchasing accessible software and technology
  • IT accessibility courses offered
  • accessibility included in general IT training
  • accessibility included in IT job postings
  • an IT accessibility leader in each campus unit
  • captions promoted as a best practice
  • grant writers encouraged to include accessible technology in grant outcomes
  • accessibility-awareness activities and products
  • IT accessibility capacity-building institutes conducted for UW and beyond
  • grants secured to supplement and expand the reach of IT accessibility efforts
  • leadership related to IT accessibility in professional organizations and publications
  • students with disabilities as accessibility testers

Although the UW is not doing all of these things currently, the UW-IT Accessibility Task Force engages in ongoing activities and makes recommendations regarding the enhancement of online resources, the promotion of accessible IT, and iteratively improves policies and procedures. UW is working to promote accessibility within a context of universal design, usability, and an inclusive culture. We are empowering users through Accessible Technology Services, which serves as a resource, catalyst, and community-builder to empower the infrastructure. 

Web Accessibility

Presenter: Terrill Thompson

When we’re creating digital content such as web pages or online documents, we may envision our typical user as an able-bodied person using a desktop computer. In reality, users utilize a wide variety of technologies to access the web including assistive technologies, mobile devices, and more; everyone has different levels of ability when it comes to seeing, hearing, or using a mouse or keyboard. Since the World Wide Web was invented, HTML has had alt tags and other accessibility features as one of its standards. WCAG 2.0 (Web Content Accessibility Guidelines, second version) aims to bring all web content up to an accessible level so that all users have equivalent access. WCAG 2.0 follows four main principles; information should be perceivable, operable, understandable, and robust. Each of these principles is defined by more specific guidelines, and those are further defined by specific success criteria, which are assigned Level A, AA, or AAA, with Level A success criteria including the most critical issues for accessibility. Level A success criteria are fairly easy to meet. In resolution agreements and legal settlements, the U.S. Department of Justice and the Department of Education OCR have identified WCAG 2.0 Level AA as a reasonable target to ensure websites are accessible.

A push for accessible tools and features will help make all web content more accessible. Using accessible themes in WordPress and Drupal is an easy way to spread accessibility across campus and utilize necessary accessibility features such as keyboard accessible drop-down menus and proper headings. ARIA (Accessible Rich Internet Applications) can be used to analyze accessibility, and it communicates the interface elements to users and designers. Canvas and similar learning management systems need to be made accessible and used accessibly; faculty need to learn about headings and alt text and the right questions to ask about accessibility.

For more information about web accessibility, check out these resources:

Document Accessibility

Presenter: Dan Comden

A document is written, printed, or electronic matter that provides information or evidence. Ignoring video and audio, which are two important but fundamentally different types of files, typical types of documents used on campus are Word, PDF, Plain Text and Rich Text, PowerPoint, and HTML. We need to ensure that all information given to students is accessible.

Evaluating over a hundred courses over a year at the UW, we observed over 5,000 documents used, and over 100,000 pages from those documents were shared through our LMS. Through all of these, the percentage of documents that were accessible was very low. On average, only about 11% of Word documents included headings, one of the most important structural accessibility features in Word. For PDFs, one of the most important features of accessibility is text selectibility so that text-to-speech software can make sense of the document. Most quarters, about 70% or more of the pdfs used were text-selectable. Yet, an average of only 26% of PDFs had bookmarks or tags and less than 8% had both bookmarks and tags.

It is important to focus on headings, lists, alternative text for images, and the language choice for all documents. Headings provide easy navigation of the information for anyone approaching the text. Lists need to be labeled and are a good way to provide structured information to the reader. Alternative text for images allows someone who can’t access the image visually to get a description of the content within an image and allows image content to be searched. Selecting the language provides information to a speech synthesizer. When exporting your document to PDF, make sure you check for accessibility with Acrobat’s accessibility checker. Scanned PDFs can be a huge problem, as they are often just an image rather than text and lack the structure provided by tags. Inaccessible PDFs often need additional software to read, which delays delivery to students.

HTML will always be the most accessible way to convey information, followed by structured Word documents. How do we encourage faculty to use accessible documents? How do we train faculty to create them? These are ongoing questions. The following websites provide tools for making your website accessible:

Working with Vendors

Presenter: Hadi Rangin

UW-IT has been working with vendors for many years to encourage them to increase the accessibility of their products. These vendors include educational vendors such as Blackboard, Desire2Learn, Instructure, Moodle, Ebsco Publishing, Elsevier, Ex Libris, BB Collaborate, Qualtrics, Elucian, and many more. We have received very positive responses from companies, indicating that this sort of collaboration can result in positive changes.

We continue to strive to increase designers’ and developers’ knowledge of accessible design so products that they develop are accessible out of box. The goal is to be able to purchase a product with an accessible design rather than buy a product and address accessibility issues later. Unfortunately, accessibility is rarely included in IT design, implementation, and quality assurance; consequently, many products entering the market are either inaccessible or haven’t been tested for accessibility.

Occasionally, vendors provide Voluntary Product Accessibility Template (VPAT) forms, which is a vendor-generated statement that provides relevant information on how a vendor’s product or service claims to conform to Section 508, IT accessibility standards used by the federal government. Many VPATs emphasize the vendors’ commitments to accessibility without providing a clear description of whether the products are accessible. Purchasers may not be savvy enough to recognize this distinction. Consequently, these products are purchased and deployed on our campuses without being fully tested for accessibility.

Some universities, including the UW, promote the consideration of accessibility as part of the product testing and evaluation in the purchasing process. In these cases, products are tested independently for accessibility and shortcomings are identified. But what should we do when there is no viable alternative for the product being purchased? Should a lack of accessibility be a deal breaker? It all depends on the necessity of the product and the availability of an accessible alternative.

We believe the solution is collaboration. It is important to bring the purchasing department and vendors together to come up with an accessibility plan. A full accessibility/usability evaluation should be performed, issues should be identified and prioritized based on their severity, and a plan should be incorporated into the contract. The contract should specify clearly what issues will be addressed and what the consequences are if the vendor fails to deliver. It is best when the respective campus department leads the collaboration and takes responsibility for following through with the contract. When evaluating a product, it is important to focus on usability rather than technical aspects of the product. Examples of good questions to ask are

  • Can users accomplish particular tasks?
  • Can users post to a particular forum/thread?
  • Can users determine how much time is remaining for their quiz?