Global Accessibility Awareness Day (GAAD) is a global event which we celebrate annually at the UW with a full day of activities designed to raise awareness and educate the UW community about digital accessibility. On GAAD 2023 (May 18), activities included a full morning of hands-on, hybrid, “Fix Your Accessibility” Workshops and a Digital Accessibility Awards event. Over 100 people registered to participate in these activities. Additional information about the day’s events is available on the UW GAAD 2023 web page, as well as in a blog post by UW President Ana Mari Cauce, Digital accessibility benefits everyone by creating a more inclusive experience for all.
The Digital Accessibility Awards event was the first of its kind at the UW. Awards were distributed to individuals or departmental units who have demonstrated a commitment to digital accessibility over the last year. Awards honored accessibility leaders in three categories:
10 departments received awards for captioning 100% of the videos on their YouTube channels.
2 departments received “IT Accessibility Capacity Building Awards” for outstanding commitment to digital accessibility.
5 individuals received “IT Accessibility Trailblazer Awards” for outstanding individual commitment.
Together, the award recipients feature a broad cross-section of individuals and departments throughout the University: Center for Neurotechnology; Central for Teaching and Learning; Compliance Services; Continuum College; Department of Gender, Women, & Sexuality Studies; Disability Resources for Students, The DO-IT Center; Environmental Health & Safety; Professional & Continuing Education; School of Public Health; University Marketing and Communications; UW Bothell Marketing and Communications; UW Information Technology, UW Libraries, and UW Records Management.
It’s wonderful, and critically important, that so many people throughout the UW community are dedicated to ensuring our digital resources are accessible.
Congratulations to all awards recipients and nominees!
The original URL, uw.edu/accessibility, is now home to the UW’s central accessibility portal, designed to make it easier for anyone looking for accessibility-related resources at the UW to find what they need, beyond just technology-related resources.
The Accessible Technology site still contains its original content and structure, and with the exception of the home page, the original URLs will continue to work for the foreseeable future (they will automatically be redirected to the correct page with the new URL). However, if you link to resources on our website, we encourage you to update those links.
Thank you for visiting our website, and for your interest in and support of digital accessibility!
Tomorrow, May 19, is Global Accessibility Awareness Day (GAAD). GAAD is an annual event designed to engage people around the world in talking, thinking, and learning about digital access and inclusion. Each year, the UW commemorates GAAD by offering a full day of lectures, workshops, and other activities related to digital accessibility. This year is no exception. See our GAAD 2022 page for a list of activities and a link to register.
Uniquely in 2022, we are embracing this opportunity to announce the launch of our freshly redesigned and reorganized Accessible Technology website! The site has been rebuilt in a months-long collaboration between UW-IT Accessible Technology Services and University Marketing and Communications, with input from dozens of people who participated in focus groups and provided feedback along the way. We especially appreciate members of the IT Accessibility Liaisons Network who volunteered their time to review the site in various stages of development. This is your website!
Below is a summary of the highlights of the new website.
A redesigned home page
The home page has been redesigned with many goals:
To feature three sections of the site that are of particular importance: “Get started” with IT accessibility, “Get help,” and review various “Policy” and related pages.
To provide quick entry points into the six sections of the site that have historically been our most popular resources: The IT accessibility checklist and five sections related to the accessibility of specific technologies (websites, documents, videos, online courses, and online meetings).
To bring forward upcoming events in a calendar widget (more details about each event are still available on the Events page).
To bring forward the latest posts on the Accessible Technology blog, which we will be updating regularly.
A reorganized navigation menu
The navigation menu has been simplified. Previously the site had a vertical menu with 16 top-level links. The new site has only five items.
Make Things Accessible: This is an entry point into all of the technical how-to pages.
Policy: This contains the UW policy and guidelines, plus supporting documents including our milestones, plans and a link to our Procurement page.
People: Contact information and descriptions of various groups involved in digital accessibility at the UW.
Get Involved: Links to our Events page and various other opportunities to participate in UW’s digital accessibility efforts.
Get Help: A landing page for quick contact information of accessibility experts within ATS and across our campuses.
Making it easier to report barriers
A sidebar is available on every page throughout the site with the heading “Experiencing inaccessible technology? Please let us know.” This includes multiple ways to report a digital access barrier, plus a link to the more general “Get Help” page.
IT accessibility checklist
The hub of our how-to pages is the IT accessibility checklist. Each item in the checklist includes a link to learn more about that item. For example, the first item in the checklist is “Do headings form an outline of page content?”, followed by a link to a Headings page. Many of the items in the checklist, including Headings, apply to multiple technologies. For example, Headings applies to websites, documents, and online courses. Each page linked from the checklist includes an overview of the issue as it applies to all relevant technologies, then links out to separate techniques pages related to specific technologies (e.g., Headings on websites, Headings in documents, Headings in Canvas).
There are other pathways that might lead to the separate techniques pages, so each of those pages includes a prominent link back to the overview checklist page for that topic.
Only the beginning
We have a long list of new content to add to the site and will continue to update existing content as technologies and accessibility best practices evolve. Meanwhile, please take some time to explore and check out the opportunities presented in the Get involved section of the site. We hope to see you soon at some of our upcoming events!
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.
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:
Microsoft Office Forms
With each survey tool, we created a test survey that included the following form fields:
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.
Another simple text field of “Your email,” with validation where available.
A date field of “Your birthdate,” with validation where available.
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.
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).
We tested each form by attempting to complete it with the 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 a 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
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 responses. 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.
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.
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 doesn’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.
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 *
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.
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.
Example goal: A perfect score in axe DevTools (in Chrome)
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.
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, email@example.com.
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, firstname.lastname@example.org), optionally including one or more screen shots. We recommend capturing screen shots of your scores before and after you fix your accessibility errors.
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,
Director 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.
Looking back at 2020
In addition to working with the 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.
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 a 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:
Watch the original video with your eyes closed. What do you learn about the UW in 2020?
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?
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.
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 the 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 previously 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 the 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 its 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:
Soliciting accessibility information.
Validating accessibility information received.
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.
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, email@example.com.
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!