Data Viz Accessibility in 2021

In 2021, we in UW-IT Accessible Technology Services received a sizeable increase in requests for accessibility consultation related to data visualizations. On March 29, Hadi Rangin and I joined Kelly Gupton, Tableau’s Senior Director of Product Management, at the UW Tableau User Group (TUG) for a presentation and conversation on “data viz” accessibility. The recording of that session has been hosted in the TUG Canvas course, but was rotated out recently to make room for new content. Nine months after that meeting, we continue to receive requests for the recording, so we’re now hosting it in our own Accessible Technology Webinar archives. The archive page includes links to the PowerPoint slides (a general overview), and a web page of links to example sites and dashboards that were featured in the presentation.

To summarize, there are several best practices for creating Tableau dashboards to make them more inclusive. These are well-documented on the Tableau Accessibility FAQ, and anyone creating Tableau dashboards should devote some time to learning and applying these best practices. However, despite best efforts from dashboard creators, some users with disabilities, including screen reader users and sighted users who are physically unable to use a mouse, will find it very difficult, if not impossible, to access Tableau dashboards in any meaningful way.

There are similar best practices available from Microsoft regarding Accessibility in Power BI. but our tests with Power BI dashboards have yielded similar results to our tests with Tableau. A sighted user with a mouse can very easily explore data and trends within a visualization and quickly come away with a deeper understanding; whereas users who don’t have the ability to use a mouse or view the visualization do not have a comparable experience, and often have no idea what information is being presented in a dashboard, or how to navigate it.

In order to make a Tableau or Power BI dashboard fully accessible given the current state of accessibility of these products, an alternative version of your dashboard will likely be required. There are two excellent examples of this at the UW:

  • UW COVID-19 Case and Vaccination Tracking Dashboard: This is a dynamic site, updated nightly. The data is presented in a Tableau version, with a link to view a text-only version of the dashboard. The “text-only” version provides access to the most critical data, using accessible HTML headings, tables, and summary text. Both versions draw from the same source data; they’re just presented in different ways for different users.
  • UW Fast Facts: This dashboard is provided in multiple formats to meet the needs of a variety of users. In addition to the Tableau version, there are links at the top of page to a text-only version (which, like the previous example , presents the same data using accessible HTML headings, tables, and summary text), as well as a PDF version (suitable for printing).

Our presentation at the TUG meeting included a quick look at Highcharts as a possible alternative. Highcharts has put tremendous effort into making their dashboards accessible to a full spectrum of users. For example, keyboard users can navigate and interact with data points, menus, and other controls using the keyboard only (no mouse required); screen reader users can navigate, explore, and interact with dashboard content; users who can better “visualize” data trends using sound rather than sight can play charts using sonification; users of voice input software can interact with dashboards using voice commands; and much more. See more details about these and other features, including accompanying videos, on the Highcharts for Accessibility website.

Accessibility Review of Online Survey Tools

Here in UW-IT Accessible Technology Services (ATS), we are frequently asked which of the online survey tools that are commonly used at the UW produces the most accessible survey forms. To be sure we could confidently answer this question, the ATS IT Accessibility Team recently conducted a review of the following five tools, listed alphabetically:

  • Catalyst WebQ
  • Google Forms
  • Microsoft Office Forms
  • Qualtrics
  • Survey Monkey

With each survey tool, we created a test survey that included the following form fields:

  1. A simple text field of “Your name,” with supplemental instructions in addition to the label (“Enter your full name [first, middle, and last”]). In order to be accessible to screen reader users, both the label and help text need to be explicitly associated with the input field. The latter would require using of the aria-describedby attribute. This field is required.
  2. Another simple text field of “Your email,” with validation where available.
  3. A date field of “Your birthdate,” with validation where available.
  4. Two multiple choice questions, one with one possible answer (radio buttons) and another with multiple possible answers (checkboxes). For both of these questions, users must select at least one response.
  5. A grid of Likert-scale questions, where each row contains the item to be rated, and each column contains a radio button on which to rate that item (i.e., “Excellent”, “Good”, “Neutral”, “Bad”, “Horrible”). Users must select one item in each row (see screenshot below).

 A likert question for rating multiple conferences on a 6-point scale
We tested each form by attempting to complete it with keyboard alone (no mouse), then Hadi Rangin, a full-time screen reader user, tested each form with both JAWS and NVDA (Windows screen readers). We also inspected the HTML code to see whether the code conformed to HTML standards and accessibility best practices, and we checked for other accessibility issues such as color contrast.

The following is a high-level summary of what we found:

  • Both Google Forms and Microsoft Office Forms have highly sophisticated forms that use ARIA extensively for making complex relationships between a form field’s parts accessible to screen reader users. (ARIA stands for “Accessible Rich Internet Applications”; for more on its role in web accessibility, see Using ARIA for Web Applications). Google and Microsoft produce the most accessible survey forms of the tools tested, although the amount of information provided to screen reader users may in fact be excessive (the forms became extremely verbose).
  • Google Forms and Microsoft Office Forms seem to be the only tools tested that do client-side error checking. If WebQ, Qualtrics, or Survey Monkey have this capability, it wasn’t apparent when we were creating the test surveys. Client-side error checking is preferred since it provides immediate feedback if the user skips a required field or enters an invalid response. If the user doesn’t learn about their mistake until after they’ve submitted the form, it can be challenging for them to (a) figure out what they did wrong, and (b) find their way back to the field that requires fixing.
  • Qualtrics doesn’t seem to indicate whether fields are required (neither in the code nor in the user interface). It’s the only tool we tested that doesn’t at least place an asterisk (*) next to required fields. There are many possible methods for communicating this information, the best being the HTML required attribute, which is well-supported by browsers and assistive technologies. In a Qualtrics survey, users have no idea which fields are required until they’ve submitted the form. Then, they are, in a sense, reprimanded for breaking rules they didn’t know existed.
  • Both Qualtrics and Survey Monkey have quirky code, and screen readers are quirky in how they handle it. As we studied the code behind their surveys, we often found ourselves completely puzzled as to why they had coded something the way they did. I’ll be exploring that code in detail in a presentation at the HighEdWeb conference on October 5 (see below for more details). When testing with screen readers, we frequently experienced unexpected and inconsistent output with surveys created using these tools, which may be due to the quirky code.
  • The Likert question is presented visibly as a table. However, functionally it isn’t a table; it’s a form. Therefore, the best practice is to remove the table markup, either by using non-semantic elements such as <div> instead of table elements, or by adding role="presentation" to table elements. If the interface is not coded this way, screen readers announce both the table-related information and the form-related information, which makes the interface extremely verbose and therefore extremely cumbersome for users to complete. Another problem is that both JAWS and NVDA fail to recognize relationships between radio buttons when they’re distributed in separate table cells. If radio buttons are grouped together in a common block element, they’re announced by screen readers as “Radio button X of Y” where Y is the number of options, and X is the position of the current option within the set. If radio buttons are in separate table cells, screen readers announce each button as “Radio button 1 of 1”, which is inaccurate and potentially confusing for users. Google Forms and Microsoft Office Forms are the only tools tested that code this interface correctly.
  • In the default Qualtrics theme, there is no visible difference between checkboxes and radio buttons (see Figure 1, below).
  • The default Survey Monkey theme has very low color contrast (see Figure 2, below).
  • Catalyst WebQ has generally good HTML code, but is no longer actively developed, so does not use modern techniques for coding HTML forms or handling errors.

Figure 1: Radio buttons and checkboxes in Qualtrics

Fieldsets with radio buttons and checkboxes look exactly the same in Qualtrics

Figure 2: Color Contrast in Survey Monkey

Conclusion and Recommendations

We’ve been using Catalyst WebQ for decades for our own forms and surveys. We have trusted its accessibility and, if we found problems, we knew who to call. However, web coding practices have evolved over the years, including methods for coding forms and for making them accessible. Since WebQ is no longer actively developed, it no longer offers the most accessible survey solution.

Today, the best tools for creating accessible forms, based on our tests, are Google Forms and Microsoft Office Forms. However, which of these tools is best may change at a moment’s notice. When we did some preliminary tests two years ago, Google’s client-side validation was triggering an error message on every keystroke as users typed their response. This was silly and annoying to sighted users (of course that’s not a valid email address–I’ve only typed one character!) But for screen reader users, it constantly interrupted the user and made the form nearly impossible to complete. Google has since fixed that bug, and currently the forms produced by both Google and Microsoft are highly accessible. However, given the frequent updates that occur with these products, we recommend carefully testing your forms before deploying them, including testing with screen readers.

Email field with a single character typed, and an error message: That is not a valid email address!

More Details at HighEdWeb

I’ll be giving a presentation on this topic at the HighEdWeb virtual conference next week. The conference is Monday and Tuesday (October 4 and 5), and my presentation, Accessible Online Forms, is the last of the conference, at 2:00pm Pacific on Tuesday. Registration is open until Friday, October 1, at 11:59pm.

Before licensing that product or service, STOP. Is it accessible?

STOP sign

Technology used at the UW falls into either of two categories: Things we create and things we purchase or procure. For the latter, accessibility is the responsibility of the person making the procurement decision. Anyone making those decisions is assuming legal risk on behalf of the university. As risk owners, they must take steps to ensure the product or service they’re procuring is accessible to all users, including those with disabilities.

There are three steps described on our Procuring Accessible IT page:

  1. Solicit accessibility information.
  2. Validate accessibility information received.
  3. Include accessibility assurances in contracts.

A key resource in each of these steps is the Voluntary Product Accessibility Template (VPAT). VPATs are a standard form that vendors complete in order to document the accessibility of their products or services, as measured by accessibility standards such as the W3C Web Content Accessibility Guidelines 2.1.

VPATs are self-reports, typically completed by the vendor, who often don’t have sufficient accessibility expertise to fill out their own VPAT. Therefore, VPATs should not be accepted as the final answer for whether a product is accessible. Rather, VPATs provide a good starting point for a thorough discussion with the vendor about their product’s accessibility. In order to be used for that purpose, risk owners need to understand the basics of IT accessibility, including how to read a VPAT. They don’t need to be accessibility experts, but they need to have enough knowledge to be able to judge whether a vendor’s self-report is credible, as well as identify what follow-up questions are necessary in order to be able to make an informed decision about the level of risk associated with procuring the vendor’s product or service.

UW-IT Accessible Technology Services is available to help, but there are practical limits to our involvement, and generally we only get involved in enterprise-level purchases that affect a large number of students, faculty, and/or staff.  For all others, it’s the responsibility of risk owners to educate themselves on how to consider accessibility when making IT procurement decisions.

On June 30, 2021, I will be joined by Lynn Magill of UW Procurement Services to offer a webinar titled “Accessibility in Procurement: Partnering for Success and How to Read a VPAT”. This event is free, but requires registration. To attend, please submit our webinar registration form.

If you are unable to attend the live event, the webinar will also be recorded and available online via the Webinar Series Archives page.

Working Toward ZERO Errors in May 2021!

This blog post marks the official launch of the “Zero Errors” campaign, a university-wide effort in May 2021 to use accessibility checkers to reduce – or eliminate! – accessibility errors from UW websites, online courses, and other digital resources.

At the UW, we have a wide variety of tools available that can check our digital resources for accessibility. See our Tools and Resources page for an annotated list. If you are responsible for one or more websites, online courses, videos, or publicly available digital documents, please take time to learn about – and use – one or more of the available tools.

“Zero Errors” Activities

Throughout May, UW-IT Accessible Technology Services (ATS) will be providing support, training, and generally encouraging UW employees to eliminate the measurable accessibility errors in their websites and online courses, and to caption all of their videos. Follow is a list of formal scheduled activities.

  • Thursday May 6, 9:00 – 10:00am – Web Council Meeting *
  • Thursday May 6, 11:00 – Noon – Accessible Tech Office Hours
  • Monday May 10, 1:00 – 4:00pm – IT Accessibility Liaisons Meeting *
  • Thursday, May 14, 10:00 – 11:00am – Web Accessibility & Usability Meetup *
  • Thursday, May 20, All Day – Global Accessibility Awareness Day
  • Thursday, May 27, 3:00 – 4:00pm – Accessible Tech Webinar Series (on Document Accessibility) *

For details about these and other events, see our Events & Collaboration page.

* = Zero Errors is part of a larger agenda.

The Ultimate Goal: ZERO Errors!

Choose one or more accessibility checkers. And see if you can reduce – or eliminate! – the number of errors found. The following screen shots are provided for motivation.

Example Goal: A Perfect Score in WAVE

WAVE is an accessibility checker developed by WebAIM at Utah State University. You can check accessibility of your web pages via the WAVE website, or using the WAVE browser extension for either Chrome or Firefox.
WAVE extension results, showing 0 errors and 0 contrast errors

Example Goal: A Perfect Score in Lighthouse (in Chrome DevTools)

Lighthouse is a web quality auditor that’s integrated into Chrome DevTools. You can use it to check any web page, even those requiring authentication. In addition to checking accessibility, it has audits for performance, SEO, and more. For additional information see the Lighthouse documentation.
Results from a Lighthouse audit in Chrome DevTools, showing a perfect score (100) on Accessibility

Example Goal: A Perfect Score in axe DevTools (in Chrome)

axe is an accessibility testing toolkit from Deque (accessibility consultancy). The axe Chrome Extension and axe for Android App are both free. There are also are various commercial versions available with additional features, as explained on the axe home page.
Axe DevTools report showing 0 issues along with a Congratulations! message

Example Goal: A Perfect Score in the Accessibility Report (in Canvas)

All Canvas courses at the UW include an accessibility tool called Ally, which – among other features – generates an accessibility report with a score for the entire course. The report provides various options for getting started with fixing the problems it identifies. For more information about Ally, see our help page on Using Ally in Canvas Courses.
The Accessibility Report in Canvas, showing a perfect score (100%) for DO-IT Summer Study, along with a pie chart showing a breakdown of the course's 329 files types

Example Goal: 100% of Videos Captioned, as Reported by the YouTube Caption Auditor

YouTube Caption Auditor (YTCA) is a free, open-source tool developed by ATS that helps YouTube channel owners to prioritize their video captioning efforts.  For the tool itself, see YTCA on GitHub. If you are responsible for a UW-affiliated YouTube channel and would like access to the UW’s hosted YTCA instance,  contact Terrill, tft@uw.edu.
YTCA Summary Report showing a YouTube channel with 100% of its 120 videos captioned

How Accurate Are Accessibility Checkers?

Automated checkers can only check a subset of accessibility issues. Estimates vary widely of the actual percentage of issues that can be checked automatically. “Passing the checker” doesn’t guarantee that a website, digital document, or online course is accessible. However, it’s a good place to start. Fixing all the issues identified by accessibility checkers will make your digital resources more accessible, even if not necessarily fully accessible.

Also, automated checkers vary widely in the rules they use. If you check your website using four different tools, you will likely get overlapping, but different, results. Similarly, if you check your PDFs using the built-in accessibility checker in Adobe Acrobat, you will likely get different results than the results reported by Ally (the accessibility checker that’s available in Canvas courses at the UW).

These discrepancies don’t mean automated checkers are inaccurate. Each checker provides feedback based on its unique ruleset. The more accessibility checkers you use, the more complete a picture you will have of the accessibility of your digital resources.

Why “Zero Errors”?

According to data collected from the U.S. Department of Education Office for Civil Rights OCR Recent Resolution Search, at least 247 postsecondary education institutions have resolved disability discrimination complaints related to accessibility of their websites and/or online courses.  An analysis of a sample of the OCR resolution agreement letters found that in 100% of the complaints, automated web accessibility checkers were either used as evidence by the person filing the complaint or by OCR to verify the complaint. This underscores the need to work toward eliminating automatically measurable accessibility errors as part of our risk management strategy.

I’ll be sharing more findings from my OCR resolution research at multiple venues in May, including the Web Council meeting on May 6, the Liaisons meeting on May 10, and during my opening remarks on Global Accessibility Awareness Day on May 20.  See the “Zero Errors” Activities section at the top of this post for a complete list of related events.

Let us Know How You Did

If you succeed in reducing your errors (or in captioning your videos), we’d love to know about it, even if you don’t attain a perfect score. Please share your experience in an email to me (Terrill, tft@uw.edu), optionally including one or more screen shots.  We recommend capturing screen shots of your scores before and after you fix your accessibility errors.

Accessible Tech in 2020-21: “The Glass is Overflowing”

The year 2020 brought unprecedented challenges to the world, country, and our university. At the University of Washington, as classes, programs, services, meetings, trainings, and major events moved online, this change was accompanied by a dramatic increase in demand for the services provided by the IT Accessibility Team.

One of the major events we got involved with was the UW’s first-ever online commencement ceremony, which occurred on June 13. In a meeting leading up to that ceremony, Sara Griggs, directory of Office of Ceremonies, said “Many people right now see the glass as being half empty. I see it as overflowing!”

Since that meeting, I have continued to find inspiration in the notion of an overflowing glass, and have expressed my gratitude to Sara for her inspiration. I hope others are equally inspired by reading this.

Artist's rendering of a glass half full (or half empty)
Glass Half Full, by S Nova, licensed under CC BY-SA 3.0

Looking Back at 2020

In addition to working with Office of Ceremonies, we collaborated with a wide variety of units in 2020, including UW Medicine (working extensively to ensure COVID-related communications are accessible), Procurement Services and the Office of the Chief Information Security Officer (on updates to accessibility-related procurement procedures), service owners and managers of roughly 30 vendor products as well as the vendors themselves, the network of over 150 IT Accessibility Liaisons, and hundreds of individuals and departments who approached us seeking help with accessibility.

Key events from 2020 are included on our IT Accessibility Progress page. Here are a few highlights:

IT Accessibility Challenge

The IT Accessibility Challenge launched in May, and from May through October participants were taught, supported, and encouraged to take any of up to 20 simple actions to improve their IT accessibility.  The initial campaign has ended, but the Challenge lives on, and anyone can Take the IT Accessibility Challenge at any time. It’s great way to get started with accessibility.

UW Celebration of Accessibility

The UW Celebration of Accessibility was an online event that took place on October 21 and featured lightning round talks from a wide variety of stakeholders from across the university who are engaged in accessibility-related work, including the Office of the ADA Coordinator, Disability Services Office, Disability Studies program, CREATE, the D Center, UW-IT Accessible Technology Services, and several IT Accessibility Challenge participants who reported out on what they accomplished and lessons learned. A recording of the event is available, along with links to slides and resources, on the UW Celebration of Accessibility web page.

Capacity Building Awards

Each year the IT Accessibility Task Force gives out Capacity Building Awards to individuals or groups at the UW who have actively demonstrated their commitment to promoting the accessible design of IT and universal design of instruction both onsite and online. This year’s award recipients were announced at the UW Celebration of Accessibility and are profiled below.

Integrated Social Sciences

Faculty and staff in the Integrated Social Sciences unit in the College of Arts and Sciences reported significant efforts as part of the IT Accessibility Challenge 2020, engaging many members in their unit in improving the accessibility of their core courses. They also organized an accessibility training for the campus-wide Online Advising Group; worked proactively to ensure their  department’s virtual graduation event was accessible; and actively promoted accessibility best practices among the organizers of decentralized graduation events throughout the university.

College of Education

The College of Education made significant proactive efforts to train faculty in the accessible/universal design of online courses as they quickly converted on-site courses to online formats. Instructors were regularly offered web-based professional development that covered topics that included tips for making their courses accessible and how to use accessibility checkers, including those used in the creation and remediating of documents and presentation slides as well as the Ally tool which is integrated within UW’s Canvas learning management system.

Looking Ahead to 2021

As we launch the new year, we do so with an overflowing cup. The tremendous growth in interest in IT accessibility has us imagining all sorts of ways that we can support the UW community as it works to ensure its digital content is accessible. Specific goals and activities are documented in our IT Accessibility Plan. Below are a few highlights.

Accessible Technology Webinar Series

At 3:00pm on the last Thursday of each month, we will host a webinar on a popular topic related to IT Accessibility. The first six months have already been scheduled:

  • January 28: 20 Tips for Teaching an Accessible Course 
  • February 25: Video Accessibility 
  • March 25: Web Accessibility
  • April 29:  Testing with Screen Readers
  • May 27: Document Accessibility
  • June 24: Alternatives to PDF 

For additional details about the webinar series, as well as our other events and activities, visit our IT Accessibility Events page.

New Website Coming Soon

We’re actively working to improve the organization of the current website so it’s easier to find the information you’re looking for. Stay tuned for an update early in 2021.

Zero Errors Campaign Coming Soon

The UW has a wide variety of accessibility checkers available for checking websites, public documents, Canvas course content, and videos. Automated accessibility checkers have some inherent limits (they can’t check everything), but they’re great tools for learning about accessibility and for finding problems you might have overlooked. In 2021, we’ll be launching a Zero Errors campaign, providing training, support, and inspiration to the UW community as we all work together to reduce or eliminate the accessibility errors identified by accessibility checkers. Stay tuned for an update.

New Focus on Audio Description

The UW has made a lot of progress in recent years in adding captions to videos, which is essential for people who depend on text rather than sound to access audio content. However, video can also present an accessibility barrier to people who are unable to see. If video content is presented visually and is not accessible by listening to the audio, the video may require audio description. This is required by accessibility standards but is often overlooked. There is additional information on our Accessible Videos web page.  Also, there’s an excellent example on the UW News website: Their recently-published year-ending video, titled 2020 in Video, includes a link immediately beneath the video player to an audio described version. Try this:

  1. Watch the original video with your eyes closed.  What do you learn about the UW in 2020?
  2. If you have eyesight, watch the original video again with your eyes open. What do you learn about the UW in 2020 that you missed in Step 1?
  3. Follow the link to the audio-described version, and watch that with your eyes closed. Now what do you learn?

In 2021 we’ll be focusing more on this important issue, and offering trainings, support, and other opportunities for helping video owners to get started with adding audio description to their videos.

Happy New Year everyone!  All of us on the IT Accessibility Team are looking forward to helping you with your digital accessibility needs in 2021.

Fall 2020 Liaisons Meeting: Exploring Recent Changes in IT Accessibility Procurement Procedures

Over the Summer, UW Procurement Services, in collaboration with UW-IT Accessible Technology Services and the Chief Information Services Office, published updates to their policies and procedures, including updates related to accessibility of IT.

These changes are reflected on our Procuring Accessible IT web page, which explains, summarizes, and quotes from Procurement Services’ Procedure 7.2.15.

The following are the most significant changes related to IT accessibility:

  • Bidders and vendors are now required to demonstrate conformance to the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. This is a version update from WCAG 2.0, the previous required standard.
  • In order to document their level of conformance with WCAG 2.1, bidders and vendors are asked to provide a Voluntary Product Accessibility Template (VPAT), version 2.3 or higher. Procedure 7.2.15 includes additional guidance and instructions related to VPATs. Previously, a VPAT was identified as one of several means of documenting accessibility, but the decision was made to standardize on VPATs since they’re an industry standard.
  • An Accessibility Rider is now available that can be inserted into agreements and contracts for procurement of IT. It’s one of several riders listed on Procurement Services’ Terms and Conditions website.

Since these changes were implemented, we’ve been asked a number of excellent questions by people at the UW making purchasing decisions. For example:

  • If a vendor fails to provide a VPAT or refuses to agree to the terms of the IT Accessibility Rider, can we still purchase the product?
  • If a vendor insists on revising the IT Accessibility Rider before they’ll agree to its terms and conditions, how much latitude do we have in negotiating with them on accessibility requirements?
  • How do we know whether the accessibility claims provided in a vendor’s VPAT are accurate?

On Thursday, November 5, from 1:00 to 4:00pm, the UW’s IT Accessibility Liaisons network will have their fall meeting, and IT Accessibility in Procurement will be the topic. The agenda will be organized into three one-hour blocks, with each hour focusing on one of the three steps in the procurement process:

  1. Soliciting accessibility information.
  2. Validating accessibility information received.
  3. Including accessibility assurances in contracts.

If you’re interesting in attending the meeting but are not yet a member of the IT Accessibility Liaisons network, see the IT Accessibility Liaisons web page for additional details, including a sign-up form.

  • Date: Thursday, November 5, 2020
  • Time: 1:00pm – 2:30pm
  • Place: Zoom (UW NetID required)
  • Meeting ID: 950 8623 6188

The University of Washington is committed to providing access and reasonable accommodation in its services, programs, and activities. Accommodation requests related to a disability should be made by 5:00pm on Monday November 2 to Terrill Thompson, tft@uw.edu.

Fall colors at the UW Arboretum

Coming Soon: UW Celebration of Accessibility!

Cooling temperatures, rainy days, and the start of another academic quarter remind us that fall has arrived. It’s hard to believe six months have passed since we launched the IT Accessibility Challenge 2020 back in May. The Challenge is a university-wide campaign encouraging members of the UW community to take one or more simple actions to help make websites, online courses, digital documents, and videos more accessible to individuals with disabilities. Dozens of individuals, and four departments, took the Challenge and have been working over the last six months to improve the accessibility of their technology resources.

October marks the formal end of the six-month Challenge, and participants will be honored on October 21 in a UW Celebration of Accessibility, hosted online from 1:00 to 2:30pm. October is also National Disability Employment Awareness Month and Washington State Disability History Month so there’s plenty to celebrate.  The event will feature lightning round talks from a wide variety of stakeholders from across the university who are engaged in accessibility-related work, including the Office of the ADA Coordinator, Disability Services Office, Disability Studies program, CREATE, the D Center, UW-IT Accessible Technology Services, and several IT Accessibility Challenge participants who will be reporting out on their experiences, including what they accomplished and lessons learned. The program will also feature two Capacity Building Awards, awarded by the university’s IT Accessibility Task Force in recognition for particularly outstanding efforts to improve accessibility.

This event is designed to celebrate all that we have accomplished so far at the UW in ensuring our university is accessible and welcoming to individuals with disabilities, and to share our vision and next steps as we continue to work together to improve. Please spread the word, and we hope to see you there!

  • Date:  Wednesday, October 21, 2020
  • Time:  1:00pm – 2:30pm
  • Place: Zoom (UW NetID required)
  • The event will include live captioning and ASL interpreting.

The UW and Society: IT Accessibility After 30 Years of ADA

On July 26, 1990, President George H.W. Bush signed the Americans with Disabilities Act (ADA). In doing so, he said “I now lift my pen to sign this Americans with Disabilities Act and say: Let the shameful wall of exclusion finally come tumbling down.”

Thirty years later, a lot has happened to make American society, including the University of Washington, more accessible. For example, there are curb cuts, ramps, accessible entrances into buildings, braille signage, accessible crosswalks, and accessible parking spaces. And systems are in place to provide accommodations for students, employees, and visitors with disabilities. However, despite all these gains, there are still shortcomings in all these areas.

Accessibility of information technology is similar. When the ADA was passed in July 1990, the World Wide Web was an idea posed by Tim Berners-Lee, but it hadn’t been implemented yet; and computer technology was many years from becoming the ubiquitous tool and resource that it is today. Technology has grown exponentially in the last 30 years, and the accessibility community has worked hard to keep pace with that evolution and ensure new innovative technologies could be used by everyone. At the UW and throughout society, we have made progress making IT accessible, including websites, digital documents, videos, hardware, and software. It is technically possible to make nearly all of these technologies accessible today by following standards and best practices. However, many of the technologies in common use today are not accessible, and as a higher education community, we still have a lot of work to do to ensure our IT resources provide benefits, rather than barriers, to students, employees, and visitors who use them.

Anyone at the UW who distributes a document in Word, PDF, or Google Docs; uploads a video; creates a website; or has a role in making an IT purchasing decision; has the responsibility of ensuring that IT resource is accessible to everyone. UW-IT Accessible Technology Services provides this website, and a variety of activities and events designed to support the UW community in this effort.

Over the next week, and throughout the summer, there will be opportunities at the UW to celebrate the positive changes made possible by the ADA, and to consider next steps—as individuals, departments, and as a university community—for continuing to improve accessibility.

  • Monday, July 27, 11am – 1pm: The Washington State ADA 30th anniversary celebration will include presentations by Governor Inslee and Lt. Governor Habib, as well as disability advocates and community leaders. It will also include historical video footage, an interactive panel discussion, and musical entertainment. The event will stream live on TVW.
  • Thursday, July 30, 10am – Noon: Tech Talks, sponsored by UW Tech Connect, will feature a talk by Sheryl Burgstahler, Hadi Rangin, and myself titled ADA Anniversary: 30 Years Of Breaking Down Barriers in IT Accessibility. This session will explore how assistive technology and technology accessibility have evolved over the last 30 years, plus barriers that still exist and strategies for addressing them as we move into the future. For additional information, including a Zoom link, see this event on the Seattle Campus Calendar.
  • Now through October: Take the IT Accessibility Challenge 2020! Do your part to help realize the vision of the ADA by completing any of 20 simple actions to make websites, Canvas courses, online documents, and videos more accessible.
President George H.W. Bush signs the ADA
President George H.W. Bush signs the ADA on the South Lawn of the White House. Sharing the moment as he signs the Act are (standing left to right): Rev. Harold Wilkie of Clairmont, California; Sandra Parrino, National Council on Disability; (seated left to right): Evan Kemp, Chairman, Equal Opportunity Commission; and Justin Dart, Presidential Commission on Employment of People with Disabilities.

Global Accessibility Awareness Day and a UW-wide Challenge

This week, on Thursday May 21, the entire world will be celebrating Global Accessibility Awareness Day (GAAD). This day was established nine years ago to engage people around the world in talking, thinking, and learning about digital access and inclusion. At the University of Washington, we have an annual tradition of hosting lectures, trainings, workshops, and tours of the Access Technology Center, as well as other events on this day.

GAAD 2020 is no exception, but it’s unique. Given our current situation, teaching and working from home due to a global pandemic, all GAAD events will be offered remotely via Zoom. Nevertheless, we have a full day planned, from 9:00am to 4:00pm, with six talks and trainings on various aspects of digital accessibility. All events are open to everyone in the UW Community (a UW NetID is required for admission). All sessions will include live captioning and American Sign Language interpreting. The full agenda is available on our Global Accessibility Awareness Day 2020 web page.

Another thing that’s unique about GAAD 2020 is that its timing coincides with the IT Accessibility Challenge 2020, a university-wide campaign that just launched, encouraging members of the UW community to take one or more simple actions to help make websites, online courses, digital documents, and videos more accessible to individuals with disabilities. There are 20 simple actions to choose from, and they can all be easily performed from home.

The photo below captures the spirit of both GAAD and the IT Accessibility Challenge, people working together (in this case, students) with a poster hanging in the background that reads:

  • Have fun
  • Take chances
  • Open mind to others’ ideas
  • Encourage each other

Please Take the Challenge! Then, attend some or all of the GAAD trainings to help get started with your Challenge tasks. I hope to see everyone at one or more GAAD events on Thursday!

Four students gathered around a computer

Considering Accessibility when Teaching Online

On March 6, the University of Washington (UW) announced that it would no longer be meeting in person due to the threat posed by COVID-19. For the remainder of winter quarter, classes and/or exams would be conducted remotely. The UW was the first public university in the United States to take this action, but since then, colleges and universities throughout the country have moved to an online delivery model, and the UW has extended its remote learning to include all of Spring quarter.

As higher education institutions, including the UW, prepare to provide students with a fully remote educational experience, it is critical that they take the steps necessary to ensure all students have equal access, including students with disabilities.

On March 17, the Office for Civil Rights (OCR) at the U.S. Department of Education released a video message reminding educational institutions of their obligations under civil rights law to avoid discriminating against students with disabilities during this nationwide movement to online instruction. The full video is provided below.

As Kenneth L. Marcus, Assistant Secretary for Civil Rights, says at 1:15, “Online learning is a powerful tool for educational institutions, as long as it is accessible for everyone”.

If you’re a faculty member, instructor, teaching assistant, web designer or developer, administrator, or other stakeholder involved in some capacity in delivering UW content or services online, please take steps to ensure your online content is accessible. The Accessible Technology home page has been updated with a variety of resources that can help. If you need help, please contact UW-IT Accessible Technology Services via help@uw.edu with specific questions. Also, please consider attending an upcoming training or event or joining our growing community of IT Accessibility Liaisons.