Applying Universal Design for Learning to LibGuides

Center accessibility in your LibGuides

Posted on June 17, 2024 in Blog Posts

A librarian applying Universal Design for Learning (UDL) to make her LibGuides accessible

An important way that academic and research librarians interface with patrons is through LibGuides. Hence, it is crucial that LibGuides are accessible to all patrons. Two librarians at New York University, Lauren Kehoe and Iris Bierlein, were part of an overhaul of NYU’s LibGuide system. In this process, they turned to Universal Design for Learning (UDL) framework to make their revisions as effective as possible for all users. Their chapter, “LibGuides and Universal Design for Learning: A Case Study for Improving the Accessibility of Research Guides,” published first in Universal Design for Learning in Academic Libraries: Theory into Practice and republished here under a CC BY-NC-SA license, offer valuable insights for all librarians undertaking accessibility work.

LibGuides and Universal Design for Learning: A Case Study for Improving the Accessibility of Research Guides

by Lauren Kehoe and Iris Bierlein

Introduction

Hello! We are delighted you have found our chapter and are interested in how we made our library’s research guides more accessible using a Universal Design for Learning (UDL) framework. In the following pages, we will share our journey as we prioritized, planned, and implemented a content and design overhaul of New York University (NYU) Libraries’ entire LibGuides system with the primary aim of making the content more accessible to all, especially learners with disabilities. UDL is a framework that can “improve and optimize teaching and learning for all people” with “guidelines [that] offer a set of concrete suggestions that can be applied to any discipline or domain to ensure that all learners can access and participate in meaningful, challenging learning opportunities.”^[i] While the framework is meant to be applied across all levels of ability, it does offer a greater opportunity for learning environments to be optimized for learners with disabilities. The goal of UDL is to “change the design of the environment rather than to change the learner. When environments are intentionally designed to reduce barriers, all learners can engage in rigorous, meaningful learning.”^[ii] With a reduction in barriers to learning, students with disabilities have a greater chance of succeeding in their pursuit of learning.

To give you some numbers about this project, it has taken about three years to get 693 guides—thousands of pages—created by 193 people to meet a set of fourteen milestones. The chapter authors identified these milestones, based on UDL principles, for content creators to implement in order to make their LibGuides more accessible. To accomplish this, we provided training and support that was grounded in UDL principles, web accessibility, and LibGuides accessibility throughout the duration of the project and we provided follow-up and ongoing maintenance support to ensure that the guides remain accessible.

In the following pages, we will share project details and resources that can be adapted for your particular needs. We hope you build on our experience and prioritize accessibility and incorporate UDL principles into your LibGuides system and web work. With a solid foundation of accessibility principles and UDL, this work can have a serious positive impact on learners and content creators alike. Before we get into the details of exactly how we planned and coordinated the project, we do have a few foundational observations to share. Here’s generally what we’ve learned through this process:

The UDL framework served us for our web design work just as much as it did for designing our training program. Design your project and training to meet your stakeholders where they are.
Skills learned from leading and participating in a project like this can be applied in other areas of library work: public services, licensing and acquisitions, teaching, and digital content creation. Better accessibility can be applied throughout the work we do in the libraries as well as outside the library field.
Accessibility was and is our priority, but that doesn’t mean it’s easy or that you’ll even get it right all the time. It requires a fundamental commitment to learning new skills and applying those skills intentionally and consistently.
People are at different stages of their accessibility learning journey, and there’ll be a variety of willingness to do this work within an organization. Building empathy and providing support is key to successful behavior and change management.
Avoid future technical debt.^[iii] Fixing accessibility issues (a.k.a. remediating) can be difficult and costly. Invest in learning about and applying web accessibility best practices to new content as soon as possible to stop accruing accessibility technical debt down the road.

NYU Libraries is a well-resourced organization, but the resources, especially employee time, are not unlimited. The team managing our project essentially consisted of two people (your authors). Competing projects, needs, and priorities had to be navigated and some additional resources leveraged from the university (namely, the Office of Digital Accessibility) and the NYU Libraries’ Senior Leadership Team (LSLT), who helped us secure support and buy-in to undertake what would be a multi-year project. Even with limited resources, we believe and encourage you to seek out support and champions of accessibility from a variety of stakeholder groups within your organization. With this chapter, we aim to provide you with a template for accomplishing this work within your own organization and making it your own.

We would like to close the introduction with some salient words from our colleagues at Deque, leaders in web accessibility: “Accessibility benefits learners of all abilities, it encourages good coding practices, it can help boost your search engine optimization (SEO), and it provides an unprecedented level of independence to people with disabilities.”^[iv]

🌟 Subscribe to the LibTech Insights newsletter for weekly roundups and bonus content, including:

LibGuides Accessibility Remediation Project

In this section, we outline the context and foundation for this program as well as a timeline for implementation. We explore how the UDL framework informed our LibGuides remediation project, including the development of training programs and support for project stakeholders. We also touch on other accessibility frameworks that we found helpful. Finally, we provide resources for how the project was implemented at NYU Libraries and hope that these resources will support you in undertaking a similar project.

Overview and Context

All users, regardless of their cognitive, motor, vision, or auditory abilities, should have equal access to engage and interact with the web. The web became available to the general public in the early to mid-1990s after the two main pieces of US legislation designed to prevent disability-based discrimination, the Rehabilitation Act of 1973 and the Americans with Disabilities Act (ADA) of 1990.^[v] The existing laws didn’t explicitly account for a new ecosystem of electronic information, so digital accessibility wasn’t well codified as the web took off and became the vital resource it is today. Organizations, such as the World Wide Web Consortium (W3C) and the Web Accessibility Initiative (WAI), recognized the need for accessibility guidelines early on, but the unspecific legislation and lack of enforcement^[vi] resulted in digital accessibility historically being sidelined as voluntary rather than required.^[vii] It wasn’t until 1998 that the Rehabilitation Act was amended to require organizations receiving federal subsidies, including higher education institutions, to receiving federal subsidies provide equal access to electronic information (e.g., websites) for all users.

Even with these legal changes, accessibility can easily get deprioritized in favor of other requirements. Higher education institutions are often contending with sprawling web environments running on disparate platforms with distributed ownership. This type of organizational model makes compliance oversight challenging. Dealing with older systems and vendor products adds to that complexity. Unfortunately, it often seems to take external pressures to elevate accessibility from a “nice to have” to “must.”

In 2016, a disability justice activist began a campaign reporting colleges and universities to the US Department of Education Office of Civil Rights (DoEOCR) for violations^[viii] related to the ADA and the Rehabilitation Act. What resulted was a wave of complaints and lawsuits filed by private citizens and at least one law firm against higher education organizations.^[ix] Private businesses also began to get named, such as the suit against Domino’s restaurant in 2019,^[x] which went as far as the Supreme Court.

Educational institutions were now facing very difficult and expensive remediation projects because they had not—and sometimes still don’t—consistently prioritize accessibility as a requirement for their digital products. A key lesson for organizations to learn—it’s much more difficult and expensive to remediate accessibility issues than it is to prevent them in the first place.

Committing to Digital Accessibility at the University and Libraries

In 2017, NYU was cited by the US DoEOCR for a lack of accessibility of its major websites.^[xi] In negotiating a settlement, NYU conducted a high-level audit of its major websites, including the Libraries’, to assess the scope of the accessibility issues and the work required to remedy them. From that audit, the Department of Education (DoE) and NYU agreed to a corrective action plan with a phased schedule for remediation whereby the university complies with Web Content Accessibility Guidelines (WCAG) 2.0 AA standards.

Coordinated by NYU IT’s Office of Digital Accessibility, work on the compliance roadmap started in 2017 for university units, including the Libraries. The members of Libraries’ User Experience (UX) and Web Services departments were identified as project leads charged with operationalizing the remediation work at our unit level. Introductory digital accessibility training covering Cascading Style Sheets (CSS), accessibility auditing, and remediation expectations were provided to our team members through the Office of Digital Accessibility.

Becoming Accessibility Champions: Project Management and Building a Culture of Accessibility

Audits of the Libraries’ web environment helped determine in which phase of NYU’s roadmap each digital product and platform would be remediated. Phase I addressed the Libraries’’ website (library.nyu.edu)—an in-house product with high visibility and a small number of content creators/managers. NYU’s Phase II focused on vendor products, including Springshare’s LibGuides, a content management system (CMS).

In Phase I, the project management and actual remediation of the Libraries’ website fell almost exclusively to UX and the developers in Web Services. Our departments are close-knit and tech-savvy, yet on our first accessibility project, we encountered steep learning curves and had to deprioritize other work due to the time-intensive nature of digital content and user interface design remediation. We did a lot of learning on the job—from technical skills to the specific ins and outs of managing accessibility remediation projects. Our enthusiasm for the work and successful timely completion of the project gained us trust and credibility with university and Libraries leadership as accessibility champions.

Drawing on our Phase I experience we expected the LibGuides project—involving a vendor product with much more content and many content creators at different levels of digital comfort and enthusiasm—would be significantly more complex and high touch. Training, remediating, and operationalizing ongoing accessibility best practices for LibGuides, in the roughly eighteen months we had to meet NYU’s deadline, would be a heavy lift for technical teams and content creators. To move the project forward, the Libraries needed to build a culture of accessibility and a sense of shared responsibility. The authors of this chapter were appointed to steward that work and sought active buy-in and support from the LSLT.

Getting “Buy-in” from LibGuides Content Creators

After advocating with LSLT, we understood that for the project to be successful, we had to make it clear to the content creators that the project would need their buy-in, too. Department managers were asked to share with their teams that this was a priority for the organization and that making the content accessible was everyone’s responsibility. We set clear expectations and deadlines for the work with content creators but also provided multiple opportunities for support and training along the way. Our approach to creating a culture of accessibility centered around building empathy across the Libraries for this project’s importance.

One of the most effective means for building empathy involved inviting staff and experts from NYU’s Office of Digital Accessibility and the Moses Center for Student Accessibility to present to the Libraries on how individuals with disabilities may have difficulty interacting with inaccessible web content. They provided an overview of how assistive technologies, like speech-to-text software, interact with web content for someone who has a visual or cognitive disability. A great example of this is how alternative text for an image would be read aloud for someone who could not see the image. They demonstrated other functions, such as navigating through a page using only a keyboard, to demonstrate how someone with a mobility disability might move through and interact with a web page without using a mouse.

Bringing in a skilled campus partner went a long way to generate buy-in and ensure that content creators understood the need to do this work. If your campus does not have accessibility offices, there are plenty of resources available to demonstrate assistive technology and how it functions with accessible and inaccessible content.

LibGuides Accessibility and Remediation at the System Level

Our LibGuides remediation project plan took a two-phased approach: system-wide improvements and then author-generated content. The UX and Web Services teams are product owners of LibGuides and have system administrator access, unlike most of our content creators. Based on the state of the LibGuides environment at the time, starting with the system improvements made sense. We could apply our teams’ technical skills and provide content creators with an optimized and more consistent platform experience in which to do their accessibility work. If we didn’t tidy up our own house as product owners then how could we expect content creators to do their part with any enthusiasm or trust?

A close collaboration with developers and clear shared priorities was vital to the system improvements. From our experience remediating the Libraries’ Libraries’ website, we learned that prioritizing CSS and templatizing accessibility changes are a good way to optimize developer time and expertise. We wanted to reduce the amount of LibGuides content creator-generated custom HTML, CSS, and JavaScript that was in the system. The personalization and flexibility of LibGuides as a product make it appealing to content creators; however, this allows for lots of nooks and crannies in the system where custom, and possibly inaccessible, code can lurk. Each organization will have to consider their developer and accessibility remediation resources, along with the needs of their LibGuides content creators’ needs, to determine how much or how little personal customization to allow.

Partnering with Developers

We were fortunate that our very user-oriented, and by extension accessibility-oriented, Web Services team of developers, with whom we’d already done accessibility work, collaborated with us on the system improvements. We know not everyone is going to have web developers as a resource and that not all developers and designers have had accessibility training. We strongly recommend that everyone working on your project, but especially on the technical and code side of your system, participates in accessibility training. If you’re the project lead, you may need to do some convincing, but creating accessible code is a marketable skill, applicable to other projects, and helps avoid the expensive remediation work down the road.

Look & Feel: External CSS, Custom Colors, and Locking Design

Rather than placing custom CSS in the Custom JS/CSS Code box in LibGuides > Admin > Look & Feel, as we had previously been doing, we used this feature to point to external style sheets managed by Web Services. Limiting the number of code contributors reduces the risk of inaccessible design sneaking back into the system. The external style sheets were optimized for accessibility with fonts, color contrast, etc. UX/Web Services teams gained better oversight of this technical feature and allowed us to better align the look/feel of our LibGuides with our other web environments. Providing consistent experiences across web platforms can help reduce the cognitive load for users and improve brand identity.

In Look & Feel > Header / Footer / Tabs / Boxes, we reviewed tab and box colors for contrast, pointed to external custom headers and footers code, and included alt text for any images. In our custom footer is an “Accessibility” link to NYU’s Office of Digital Accessibility form so users can report any specific access issues. This is required in the footer for all NYU websites, LibGuides included. Springshare has a “Report a problem” link (under System Settings > General > System Information > Support Address) in all footers, which we also utilize and point to a feedback form managed by our UX team to route issues as needed. If you don’t have capacity to fully customize the footer, customizing the “Report a problem” experience so the link destination is inclusive of accessibility needs may be a good option for your learners. It’s our experience that both forms are used infrequently but are worth having.

We also selected Design Setting: Lock all guides with this design and override any individual guide design settings. We opted to offer fewer choices at the guide level but a better accessibility structure for our content creators to work within and better consistency for guide users. The centralized CSS also makes it easier for us to deploy any future accessibility improvements across our whole environment.

Page Layouts: Custom Templates

LibGuides has default out-of-the-box templates, but system administrators can utilize the Look & Feel > Page Layout feature to create custom design templates for the following types of pages: guides, homepage, search, subject pages, profiles, and databases A-Z landing page. One caveat: if you’re going to use custom templates, make sure that the folks who will work on them have digital accessibility training appropriate for developers and designers.

We chose to create custom templates to give our developers a clean slate to work on accessibility (like custom skip links and focus indicators) and branding updates. In combination with locking the design settings, custom templates centralized the development work and made it more efficient to apply accessibility updates consistently. System administrators can push changes out to every guide that uses that template rather than manually updating every custom guide. Reducing the number of places where you have to manage accessibility is vital for sustainability, especially if access to technical support is limited or you’re on a small team.

Working with the Vendor and Reporting Issues Beyond Your Control

In a vendor platform, you will inevitably find there are limits to remediation, and your ability to build out new accessible features. Vendors’ accessibility requirements may differ from yours, or be non-existent, so no matter the product, expect to advocate on behalf of your front-end and back-end users. Springshare has made some efforts toward accessibility, but our team tends to maintain a healthy skepticism of the marketing around accessibility (often only relevant for out-of-the-box features), and we review the Voluntary Product Accessibility Template (VPAT) and test any features ourselves.

During the remediation project, we started a list of vendor-level LibGuides accessibility issues. We then submitted issues and new feature requests to Springshare customer support, making sure to include any details about why it was an inaccessible/bad experience for learners. You don’t have to be the product owner or system administrator to report accessibility issues to Springshare; anyone can submit a ticket via the Ask Springshare page (https://ask.springshare.com/ask). You may want to encourage everyone in your organization to report issues directly to the vendor, but we found it helpful to be looped in so as system administrators we have a record. Documenting and communicating issues and outcomes, internally and with Springshare, is helpful.

LibGuides Content Creator Training

Accessibility Frameworks Guiding the Work

We identified several frameworks to incorporate into the planning, training, and completion of the project to help us build a culture of accessibility.

Universal Design for Learning (UDL)

According to CAST, the UDL guidelines “offer a set of concrete suggestions that can be applied to any discipline or domain to ensure that all learners can access and participate in meaningful, challenging learning opportunities … [and] are a tool used in the implementation of UDL, a framework to improve and optimize teaching and learning for all people.”^[xii] UDL is an educational approach based on the learning sciences with three primary principles (designed for flexibility and anticipating alternative needs):

UDL guideline	Multiple Means of Representation	Multiple Means of Engagement	Multiple Means of Expression
Classroom example	Provide an option to watch a movie or read a book with the same information.	When asking for classroom participation to respond to a question, offer an option that incorporates polling, allows for a written response, or an oral report.	For assignments, provide an option to work alone or with a group.
Web content example	Provide captions and transcripts for video; add alternative text (alt-text) to images; support understanding across languages by using simple text, vocabulary, and icons.	Ask a Librarian librarian (phone, chat, in-person reference) service embedded in all guides, research guides, and tutorials.	Provide self-check options and make sure content works with assistive technologies.

How Can UDL be Applied to Training?

The success of the project relied on comprehensive support and training over the duration of the remediation. We designed our support and training through the UDL framework. We offered multiple means of representing the project and its expectations for deliverables. For example, we offered in-person sessions to introduce the project, created a LibGuide for self-service access to the information, and were willing to meet one-on-one with content creators to further discuss the project. We offered multiple access points for engaging with the materials. In addition to the LibGuide, we created a Google Doc Tool Kit, and during our training, we offered live, synchronous presentations and exercises but also offered recordings of the training with captions and transcriptions. We offered multiple means of expression. We asked content creators to fill out a Google Form for us to track their progress, but we also met one-on-one to discuss progress or accepted email communications to understand progress. Finally, we were flexible with timelines to every extent that we could, which allowed content creators to work at a pace that worked best for them.

Using a UDL approach for the training and support allowed for the project to be successful and provided us with an opportunity to model UDL in reality. It modeled for our colleagues the benefits of incorporating the UDL framework into their own teaching and instruction. Throughout the training and support, we supplemented UDL with additional frameworks, like POUR,^[xiii] WCAG,^[xiv] and NYU’s Top 10 Accessibility Checklist to guide the work. Since UDL is meant to be applied to all learning, and LibGuides are a very specific web content tool, we needed additional support to identify concrete ways of implementing UDL theory.

To make this project successful, we offered training and support to all of the LibGuides content creators to ensure that there was a foundational understanding of accessibility principles and guidelines, especially as they related to developing and creating web content. The training was scaffolded over several semesters to allow for a measured and consistent engagement with the material. We didn’t want to overwhelm everyone with the project, but we also wanted to ensure that there was consistent engagement with the materials. We also wanted to provide this training to build empathy within the organization so that everyone understood why this work needed to be done.

In addition to the training we provided, we encouraged content creators to seek out other opportunities to learn. The training was not all explicitly related to web accessibility but laid a foundation for understanding why the work is necessary through a lens of disability justice and empathy. We encourage each of you to identify partners within your organization who are offering training or support for accessibility or UDL. There are also many resources offered by various accessibility advocacy groups and technology companies that specialize in accessibility work.

In the following section, we describe the modules of digital and web accessibility training we offered and provide links to the resources we used. We welcome you to adopt any or all of this for your own needs to implement in your work remediating your organization’s LibGuides.

LibGuides Content Creator Training for Accessibility

Content creators were required to sign up for and attend training on the POUR framework and the Web Content Accessibility Guidelines so that they had a foundational understanding of web accessibility. This training was the first part of support offered to content creators that introduced the upcoming remediation project. It had a supplemental benefit of furthering the understanding that everyone in the Libraries needs to contribute to accessibility work and that the content they develop on the web has great implications for the way individuals are able to engage with that information.

The resources for this part of the training include a Google Slide deck for LibGuides content creator Training for Accessibility Part I and Remediation Checklist for training. All attendees were provided with a pre-workshop request: download the WAVE extension for Chrome and Firefox and determine which of their existing guides will be publicly available on the website in fall 2020 and beyond. During the training, they used a test guide that was intentionally made very inaccessible to practice the new concepts and skills they were learning.

LibGuides Content Creator-Focused Workshops

In spring 2020, we planned to host a series of “Accessibility Bites” workshops that were micro-workshops for a specific accessibility concept. The workshops were scheduled for one hour early in the week and then followed up by a “drop-in” session for attendees later in the week to practice the concepts and ask any questions they had about the topic or other accessibility work. We were only able to offer two sessions before NYU closed in-person operations in early spring due to the COVID-19 pandemic, but they were recorded during the live session and shared for content creators to view at their convenience. The Bites workshops covered alternative text for images in LibGuides and contextual links. We had planned to offer additional Accessibility Bites on video accessibility, providing an overview of making video content accessible through NYU Stream video editing and hosting service, creating content with captions and transcripts and embedding videos into LibGuides. However, we didn’t offer these in-person workshops due to COVID-19.

With the disruption from the pandemic, our team assessed how to move forward and how to adjust the timeline, and decided to restart the training and support again in June 2020 as the summer semester arrived. The team re-launched it on June 1 and everyone was expected to wrap up their remediation and submit their progress forms by August 31. We launched a communication campaign over email that included the main points of support for this part of the project (we provided a schedule of ongoing drop-ins and training sessions for content editors to use as they worked on their guides), outlined the work that was expected to be completed with target completion dates, and shared links to resources we created to support this project, specifically an Accessibility Remediation LibGuide (https://guides.nyu.edu/a11y-remediation) and a supplemental Remediation Project Tool Kit in Google Docs (https://tinyurl.com/libguide-toolkit).

Accessibility Remediation LibGuide and Schedule of Support Offered Over the Summer Project

To support content creators in the editing of LibGuides for accessibility purposes, we created an Accessibility Remediation LibGuide that included a variety of information to support key accessibility milestones. The milestones were presented in the guide in a specific sequence from simple and most easily accomplishable to more complex and time-consuming. We wanted everyone to feel a sense of accomplishment and build confidence as they moved through the remediation process and reduce the chance of early-onset overwhelm. Generally, milestones were expected to be worked on over the course of one week, but content creators likely worked at their own pace.

The Accessibility Remediation LibGuide used UDL principles to optimize the training experience and delivery of information. It modeled best practices for web accessibility. This was done in order to provide all content creators with an example of what was expected from them in remediating their content. Each page includes best practices, tips, and links to resources (many from Springshare’s Knowledge Base) with further support to meet each milestone.

A screenshot of NYU's a11y remediation overview guide — Accessibility Remediation LibGuide.

In addition to the milestones, the guide included a LibCal widget listing workshops and drop-in hours that we hosted throughout the project. Workshops and drop-ins were offered every week and we generally themed them around the week’s milestone. However, we were flexible in allowing the content creators to raise any questions they had about the accessibility remediation project.

To keep communication open and everyone motivated, we sent an email every two weeks to content creators with links to the specific resources for the milestones, reminders about how to report progress, and shout-outs to our colleagues for their progress.

Accessibility Milestones

1. Creating “Friendly URLs”

Friendly URLs need to be readable, and we chose to use dashes in between each of the words in the URL. An example of the auto-generated URL and then the edited friendly URL from the Accessibility Remediation Guide we created is provided below:

Avoid using URLs that aren’t easily readable, like this: https://nyu.libapps.com/libguides/admin_c.php?g=1043727&p=7573075.
Instead, use this: https://guides.nyu.edu/a11y-remediation/friendly-url.

The UDL guideline 3, comprehension, applies here. LibGuides auto-generates a URL that is difficult to comprehend and remember, so the general guidance is to provide a URL that is relevant to the page’s title and/or content and is human-readable. Applying the UDL guideline 3 ensures that comprehension is maximized.

2. Describing the Guide

Descriptions should be concise, no more than a couple of sentences, and should convey the guide’s purpose and content. An added benefit to guide description is search engine optimization (SEO) and discoverability. An example of a guide description for a first-year student research guide might be:

“An introduction to using library resources and how to get started with your research project.”

UDL guideline 7, recruiting interest, applies here. Applying a description to your guide gives the learner an idea of how the guide might help them with their research. Furthermore, describing a guide employs guideline 3 (comprehension) as well, especially principle 3.1, activate or supply background knowledge, and 3.3, guide information processing and visualization.

3. Consistent Visual Branding

To keep visual branding consistent, we encouraged content creators to reformat copied content from other sources—i.e., other guides, web pages, or documents—as plain text before pasting. Copied content from another source often has underlying HTML tagging that can disrupt the semantic structure of the copied section and/or the guide page. The Rich Text Editor in LibGuides has a tool that also strips formatting (the “T” button that is underlined with a subscript “x”).

Additional suggestions included limiting the use of bold, italics, or applying various colors to text (for contrast), and we asked for content to not be changed from the default HTML settings in the system. UDL principle 4.2, optimize access to tools and assistive technologies, applies here. Any text that was given special font, size, or style settings was flagged to be set back to “Normal” settings within the system. For NYU’s purposes, we had set system defaults for the “Normal” text so that the look and feel of the text was aligned with NYU’s Visual Branding. For reference, we included a link to the university’s guidelines for branding in our guide. The additional UDL checkpoints that apply here include checkpoint 3.2, which identifies the need for highlighting patterns, and checkpoint 7.3, minimizing threats and distractions. With a consistent visual branding, learners can enhance their comprehension of how to use the resource, and distractions are minimized if there is consistency across the learning experience.

4. Using Semantic Heading Levels in Logical Order

LibGuides’ default settings force the H1 level headings for page titles and H2 headings for box titles. Thus, in the Rich Text Editor, the first heading level available to content creators is H3. We asked that creators apply heading levels in logical order (i.e., H3→H4→H5, not H4→H3→H5) and provided a generic example of the heading structure that is best to use. It’s worth noting that there were many requests for content creators to update the size and style of the various heading levels available in the Rich Text Editor. For example, an H3 is very similarly styled to an H4, so we are working to update that in the Cascading Style Sheets (CSS) of our system.

We also asked creators to consider how to use heading level to organize the content into meaningful sections instead of using big blocks of text to describe things. It is easier to scan a page visually and with a screen reader and aids in search engine optimization when headings are used. This was partnered with the suggestion of including more lists (structured: numbered and unstructured: bulleted) in the content—for example, numbered instructions on how to search the catalog for a book or how to put in an Interlibrary Loan request for an article and unstructured list for Subject Headings or features of a Boolean Search, etc. The UDL checkpoints 3.3, guide information processing and visualization, and 4.2, optimize access to tools and assistive technologies, apply here. With semantic structure, the content of the resource is easier to process and allows assistive technology to engage with the information more efficiently.

5. Contextual Links

The LibGuides system provides an opportunity for many links to be added into the system. When a link is added through the Asset→Link option or the Asset→Database option, the asset box provides multiple fields to support making the link accessible, but when adding a link in the Rich Text Editor, it’s important to also apply best practices. The reasons for contextual links include the following:

The display text for a link should let the learner know where the link will take them. Adding a contextual hyperlink (Google Doc) or contextual link (PDF) goes a long way in adding context for where the resource will go.
The text should be informative enough that a learner would still know what the link was even if there was no context around it.
Screen reader users may select to hear a list of all the links on a page.

Guide creators were encouraged to avoid pasting a URL into the text and to avoid using “here” or “click here” which provide no context directly in the link about what it is. Also, as a general rule, we encourage content creators to set rich text links to open in a new page, but there is some discussion in the accessibility community about whether opening in a new page causes too much cognitive load and leads to confusion. For NYU, the practice is to open in a new page for a resource outside of the guide’s content, but you should work with your own organization to determine best practices.

Another accessibility feature that we asked creators to activate was to ensure that any descriptions of link or database assets were set to display beneath the link. LibGuides allows creators to choose a variety of options, including hover over item title or hover over “info” icon, but both of these options cause screen reader complications with accessibility. The UDL checkpoints that apply here include 4.2, optimize access to tools and assistive technology, 6.3, facilitate managing information and resources, and 7.2, optimize relevance, value, and authenticity. Using contextual links allows screen reader users to more naturally engage with the links, and it provides the learner with a more informed context for what is being linked to, which leads to making decisions about the relevance of the information and resource to the learner.

6. Broken Links

When a link doesn’t work, it can cause a learner to doubt the reliability of the information and confuse or frustrate them. It’s important to regularly and consistently (we suggest monthly) check that links within a guide are active and working properly. While the remediation project was going on, we asked content creators to check all their links as they moved through the pages of their guides, especially within rich text boxes.

Links that are not in a rich text box can be checked manually, but content creators can also use the Springhare Link Checker Feature to view links across the LibGuides system. More information on this tool can be found on Springshare’s FAQs. The UDL checkpoints applied here include 7.2, optimize relevance, value, and authenticity, 7.3, minimize threats and distractions, and 9.1 promote expectations and beliefs that optimize motivation. Ensuring that links are working and functioning indicates that the information being delivered is authentic, and if the link is broken, it provides unnecessary distractions to learning. Furthermore, with functioning links, the learner’s expectations for the value of the content are heightened and will motivate them to use the resource.

7. Non-English-Language HTML Tags

NYU is a global organization with campuses all over the world, and many subject guides refer to resources that are not in English. Therefore, we have content in languages other than English within the LibGuides system. Springhare’s default is English, but to make the non-English-language content accessible to screen readers, HTML tags need to be added to content that is not in English. This is done in the source code of the Rich Text Editor, but tags can also be added within assets (i.e., links, databases, books from the catalog), including the title and description fields. We provided some general guidelines, but we also asked content creators to consult us directly if they had specific questions or needs for their guides. The UDL checkpoint that applies most here is 2.4, promote understanding across languages. With appropriate language HTML tags, the opportunity to understand across languages is enhanced.

8. Alternative Text (alt-text) for Images

Alt-text is imperative for screen reader users to understand any meaningful images included in the content. If the image conveys meaning for understanding the information on the page or information within the images, a description of the image is required. We used this opportunity to encourage content creators to genuinely consider the use of images in their content. If it wasn’t pertinent to the content, we suggested that they didn’t include an image. But many images are pertinent, so we provided some guidelines and support for including them and describing them so they are accessible to all. The tips we provided for writing alt-text (which is an art, not a science) include the following:

Try to keep it short (~140 characters) because a learner has to listen to it. Too wordy and it can be overwhelming.
Use punctuation in your alt-text. Make sure to put a period at the end of your sentences. Punctuation helps screen readers pace.
Remove images that are purely decorative and serve no educational or communications purpose. Or add “” into the Alt-Text field (no spaces between the quotation marks) which tells a screen reader to skip the image. Do not use the image file’s title as the alt text or write in “photo of” or “image of” since these phrases are redundant and will cause an accessibility flag in an automated checker.

For task directions or instructions, which often include accompanying screenshots of the directions or instructions, we suggested:

If you have marked-up screenshots in your guides to explain how to use an online service or system, be aware that the text or arrows you add to that image won’t be available to a screen reader.
The best practice is to write out the information or directions in the body text of your guide, not just on an image; that way it’s accessible to everyone. Paste this information before (above) the image so that they encounter the text instructions first.
Having directions in your body text makes writing the alt-text for that image and keeping to the 140 characters much easier.

One highly used feature for adding images in the system takes place when adding book cover images to the Book from the Catalog Asset. Using linked data, covers can be added automatically if available. If they are available, the default for the alt text is set to “Book cover,” but this is not really descriptive and can be repetitive if there are multiple books with images within the guide. Thus, we suggested that creators put nil (empty double quote marks: “”) as their alt text, prompting a screen reader to skip the image. We made this decision because, generally, the information valuable to the reader would be included in the asset’s other description, like title, author, and description. One exception we can think of for this is if the cover conveys valuable information. If so, it should be described using the alt-text field available next to the thumbnail of the image. Content creators often add photos to their profile pages too. The LibGuides system automatically generates the alt-text for this, so it does not need to be updated. It defaults to “Profile photo” alt text. Not very descriptive, but it does not cause an accessibility issue when using the automated checkers.

The main guideline applied here is 1: Perception, but more specifically checkpoints 1.1, offer ways of customizing the display of information, and 1.3, offer alternatives for visual information. Additionally, checkpoint 4.2 can be applied which is access to tools and assistive technology. Adding alternative text (alt-text) gives learners the option of reading a text-based version of visual information and can be interpreted by assistive technology.

9. Alt-text for Infographics

Related to the information above regarding screenshots, infographics often contain an abundance of information that would only be accessible if someone can see the image. Therefore, it’s important to provide an alternative means for accessing that information—i.e., text-based data that represents what is being presented in the infographic. Infographics should have alt-text (in the image’s properties) and long descriptions BEFORE the infographic

Add text alternatives in the same box. Learners benefit from having long descriptions that are in the main content of your guide.
Add a long-format description of the information in the graphic within the guide and make sure to give it a header name that will help learners identify it quickly.
Non-screen reader users can skip over the description if they don’t need it.

The same as the previous milestone, the main guideline applied here is 1: Perception, but more specifically checkpoints 1.1, offer ways of customizing the display of information, and 1.3, offer alternatives for visual information. Additionally, checkpoint 4.2 can be applied, which is access to tools and assistive technology.

10. Tables

There are limitations to the formatting within a rich text box, and there may be times when creators want to use a table to structure their content, but we asked content creators to avoid using tables for styling. This can confuse screen readers and can also affect the responsiveness of the page (i.e., while using a mobile device with a smaller screen). Tables should only be used for displaying data.

Tables should be properly formatted to include headers, which is a feature that can be set in the table’s properties setting. If you have data tables in your guides, they need to be formatted so screen readers can identify them and read them in a way that’s helpful to the learners. Within the properties, you can also add a table caption, which describes the data you are presenting. We suggest that you include both a header and a caption in the table’s properties to make it more accessible. Some additional tips we suggest are:

Check how your tables look if you make the browser window narrower; not all tables are readable if using a smaller screen.
Avoid using images or icons inside tables; words are best. If you have images in a table, the images will need to have alt-text.

Due to the complexity of tables, we also provided a resource link to Web Accessibility in Mind’s (WebAIM) resource for creating accessible tables: https://webaim.org/techniques/tables/. The checkpoints that apply here include 1.1, offer ways of customizing the display of information, 3.3, guide information processing and visualization, 4.1, vary the methods for response and navigation; and 4.2, access to tools and assistive technology. For a table to be interpreted by assistive technology (i.e., a screen reader) format it appropriately to offer a customized display of information. Using a table for data also guides the visual processing of that data.

11. Document Accessibility

We could write many chapters or even many books on document accessibility. It’s complicated and a very important part of making content accessible, but for the purposes of LibGuides, we encouraged content creators to be very selective in adding documents to their guides, including PDFs, CSV files, presentations, or Word documents. Documents should be included only if they’re essential to the delivery of information; unfortunately, many documents, especially PDFs, are often inaccessible.

If the content creator was reusing someone else’s content, we encouraged remediation (which can be time-consuming), and we asked them to, at a minimum, put a note in the document’s description that it might not be fully accessible. At NYU, we offer document remediation services, so learners are provided an option to ask us to convert the material, but not all organizations offer this service. This service is offered through the Libraries’ Accessibility Services and from the Moses Center for Student Accessibility. We encourage you to consult your partners on campus to determine what document accessibility services are provided.

If the document was created by the content creator, we requested that they consult us regarding remediation or constructing it so that it would be accessible. NYU offers a variety of services for creating, converting, and checking document accessibility. Most applications come with accessibility tools, so we consult with Microsoft and Google’s products to create accessible documents. NYU also subscribes to Grackle, a tool for the GSuite of applications, that will check the accessibility of a resource created using Docs, Slides, or Sheets and will provide guidance on how to update the document so that it meets accessibility requirements. We also provided support from the NYU Office of Digital Accessibility in what makes a document accessible for content creators to refer to.

Since the accessibility of documents can be so complicated, we did a lot of one-on-one work with each content creator to go over the nuances of this type of resource to be added into LibGuides. We encourage you to review the resources we provided in the Accessibility Remediation LibGuide more closely for the variety of support out there. Perhaps not surprisingly, due to the complexity of documents and file formats, many UDL checkpoints are applied here, including: 1.1, offer ways of customizing the display of information; 2.3, support decoding of text, mathematical notation, and symbols; 4.2, access to tools and assistive technology; 5.2, use multiple tools for construction and composition; 7.2, optimize relevance, value, and authenticity; and 9.2, facilitate personal coping skills and strategies. By including a variety of textual formats, information displays can be customized and multiple tools are used to construct and compose. If built accessibly, documents and files can optimize value and authenticity, provide an opportunity for decoding text and symbols, and can be used by screen readers. Coping skills and strategies are activated if the learner has to engage with a variety of information.

12. Video Captions

We asked that all videos be added using the Media / Widget tool and not as code added to a rich text box. The two platforms that we use videos from the most are YouTube and NYU’s Stream service, which is media storage and production. Each platform offers an embed code of any media asset that can be copied and pasted into the Media / Widget LibGuides tool. Using the Media / Widget asset allows for the content to be reused across the LibGuides system and is easier to locate and edit.

Both platforms mentioned above allow for auto-generated captions using artificial intelligence, but, unfortunately, they are not perfect and any media you embed will need to be reviewed for accuracy to ensure that the captions and transcript are accurate. If you are selecting YouTube videos, try to select videos that have done some quality control on their captions, and if you are making the videos yourself, ensure that you do the necessary quality control and remediation work.

Once the media is identified and/or created, we asked that the following guidelines be considered:

Be careful not to set the video to autoplay when you embed it.
If you embed videos but captions and transcripts aren’t available from the media widget viewer, also include a link to the video directly and add a description for that link that indicates to the learner that captions, transcripts, audio descriptions, etc. can be found at the link.
If the video you need is absolutely essential but does not offer accessibility features and there is no alternative resource, make it clear in the link text or video description that the video is not accessible.
Reach out to the video owner and ask them to consider adding captions and a transcript. You may find they agree.

Another great accessibility tip for videos is to describe where you got the resource from and how long the run time is. So, for example, if you find a video on YouTube titled “Don’t do this! // How to do captions right! [CC]” and it’s fifteen minutes, eighteen seconds long, label the video title this way: “Don’t do this! // How to do captions right! [CC] (YouTube video; 15 minutes, 18 seconds)” or in the description of the video indicate that it’s from YouTube and has a specific run time. The UDL checkpoints applied here include 1.2, offer alternatives for auditory information; 1.3, offer alternatives to visual information; 2.5, illustrate through multiple media; 3.3, guide information processing and visualization; 5.1, use multiple media for communication; and 7.1, optimize individual choice and autonomy. By providing captions, media is represented in a variety of formats and allows the learner to choose the format that works best for them. Furthermore, including captions is optimal for assistive technology users.

13. Transcripts

You should provide transcripts via an accessible file type (i.e., properly formatted Google Doc, Word document, or plain text file, etc.). Both audio and video resources should have a transcript. For example, YouTube videos and PodCast recordings should include an accessible transcript. We encouraged content creators to identify already accessible resources or to create their own accessible resources. The additional guidance we offered for transcripts includes:

If you can’t add the transcript in the media player hosting the audio or video, add it as a box in the guide or as an accessible document link, with appropriate headings.
Automated transcripts will need checking for accuracy; leave yourself time to do that work.
If you’re linking to audio or video content that doesn’t have a transcript, indicate that in the link.

The same as the previous milestone, the UDL checkpoints applied here include 1.2, offer alternatives for auditory information; 1.3, offer alternatives to visual information; 2.5, illustrate through multiple media; 3.3 guide information processing and visualization; 4.2, optimize access to tools and assistive technology; 5.1, use multiple media for communication; and 7.1, optimize individual choice and autonomy. By providing transcripts, media is represented in a variety of formats and allows the learner to choose the format that works best for them. Furthermore, including a transcript is optimal for assistive technology users.

14. Gallery and Tabbed Boxes

There are some inherent limitations to using these features in the LibGuides system. A lot of content is “hidden” from screen readers and engaging with the gallery features and content within tabs can be challenging. We recommended caution in using this feature and provided the following alternatives.

For tabbed box content, accessibility best practices suggests moving the content out of a tab and into stacked boxes on the same page. We realize this could cause the page to have a lot of scrolling, but content creators could add a “table of contents” with jump links to the boxes; alternatively, in the LibGuide’s overall system settings for “Guide Navigation Layout,” there’s an option to display box headers in the page’s navigation (which we recommended that only side navigation be used for mobile device use). To set this, the box labeled “Show box-level navigation for selected page” should be checked.

For gallery content, we strongly encouraged content creators to not use this feature, but if they did, we asked that they adhere to the following:

Any original content you add to a gallery should be accessible (slide decks, images, documents, etc.)
In the gallery box settings, the slides “automatically play” option should be set to “off.”
Be aware of how embedded content behaves on your page.
- Make sure a user can control all actions of a media player or slide deck using just their keyboard.
- No embedded content like videos or audio should autoplay.

The UDL checkpoints applied here include 4.2, optimize access to tools and assistive technology; 7.1, optimize individual choice and autonomy; and 7.3, minimize threats and distractions. By limiting the use of gallery and tabbed boxes, we minimized distractions, gave the user more control of the content, and provided a more optimal experience for assistive technology users.

Reporting on the Milestones

After moving through the milestones, we asked each content creator to submit a Google Form for each guide they had remediated. (We allowed content creators to submit multiple forms for the same guide or one form for all milestones.) We provided a pre-populated list of all active guides in the system as the first question they had to respond to and then asked which milestones they had completed for the guide. Not every milestone applied to every guide, so we made space in the form for the content creator to indicate if the milestone was not applicable. We set up the form to be matched to a Google Sheet where we were able to track the progress of each guide. We set up auto-notifications within Google so we would be notified each time a form was submitted.

Timeline of Expectations and Deliverables (“Milestones”)

We expected content creators to complete the remediation work by the end of August 2020. For the review process, we used a project management tool called Monday.com to create a “board” to organize which guides had been remediated, which guides had been unpublished, and which guides had been deleted along the way. We used the board throughout the review process within the UX team so that we could collaborate to review the accessibility edits within the individual guides. Any project tracking tool or even a spreadsheet could serve this same purpose, the key being you have a central place for collecting and managing the data.

If we didn’t receive a form indicating that remediation work had been completed for a guide, we unpublished it and communicated that to the guide content creator. If we were notified after August 2020 that a guide was remediated, we added it to our queue for UX review. Content creators successfully remediated the majority of the guides in our system within the timeframe given to them.

Beginning in September 2020, the UX team reviewed the guides one by one using a templatized Google Doc we created with a standardized checklist. The checklist covered accessibility tasks that applied guide-wide and required that we review and document each page of the guide to ensure participants met the milestones. Once we completed the review document for each guide, we shared it with the content creator. If we still required substantial or complicated updates, the UX team met one-on-one with the guide content creator, but if the additional updates were simple, the Google Doc communicated all the necessary information. Occasionally, content creators would respond to comments and ask additional questions for clarification.

Maintaining the Accessibility Gains

Once a specific digital accessibility remediation campaign is done, accessibility work needs to continue to ensure that gains made during the campaign aren’t eroded by a lack of maintenance or oversight for new content. A limiting factor for our shift from accessibility remediation to maintenance mode has been staff time. Accessibility review, auditing, and remediation are very time- and labor-intensive. Our team is quite small, and accessibility is just a part of our portfolio, so we need to distribute the maintenance burden to keep up with new content accessibility. We are developing strategies to leverage automated scanning tools and scoped tasks for student workers. Simplifying workflows and distributing tasks among your team or other interested individuals in your organization can make keeping up with accessibility for new content more sustainable. At the time of writing this chapter, several companies were offering automated accessibility scanning services that can be set up to scan the front end of your web content (i.e., LibGuides) at regular intervals and flag suspected issues for review. These companies have developed proprietary software that uses the WCAG protocols to review content and flag issues based on URL, severity, and area of WCAG. Free browser extensions that can be run as on-off scans are also offered by these same companies. Automated testing, like aXe Monitoring or ARC Toolkit, is very helpful and worth investigating if you have a budget. LibGuides doesn’t have a built-in accessibility checker, so we advise utilizing a third-party automated tool.

While automated testing is great to have in your toolkit, it can’t catch all the accessibility issues that may exist in a webpage, so always try to pair it with manual testing. It may be more realistic that you’re going to be able to scan content after it’s published for accessibility issues. Automated testing and scanning is one part of a healthy accessibility maintenance process; delegating and acting on the work that comes out of the scans is another.

Conclusion

Now that you have learned about how we supported a multi-year accessibility remediation project for LibGuides at New York University and may be considering a similar project for your own organization, we want to offer a few final words in summary. We realize that everyone’s experience in accomplishing a project like this will be a little different, but generally, we think these tips can apply to all.

Set a plan. Make it scalable to your needs, sustainable over time, and scaffolded so that it can be accomplished. This may require a great deal of flexibility, understanding that there will be some exceptions to the plan you set out, so be prepared to respond and allow for multiple ways of accomplishing your goals. Finally, with the plan set, identify markers for accountability. Accessibility is everyone’s responsibility, but organizationally and culturally, what is driving this project, and who is ultimately responsible for assessing its completion? Is it one person, a department, or does the organization as a whole want to take on the commitment of ensuring digital accessibility for its content?

To establish accountability, you will very likely need to get buy-in along the way. As outlined in this chapter, we held each other accountable, established that the UX team would manage this project, and sought out the support of the Libraries Senior Leadership Team and content creators. Without the support of all the stakeholders, this project would not have been possible.

To sustain the support and buy-in of stakeholders, you should offer ample opportunities for training and knowledge-building. We outlined a variety of ways that we offered support based on the guidelines and principles of the UDL framework, but there are many additional resources we relied on for building our skills as an organization. We encourage you to adopt any and all of the training we’ve used and to develop your own curriculum to support an accessibility remediation project.

We think our project was successful because we communicated clearly and consistently with stakeholders throughout the project. The communication came in a variety of ways: email, LibGuides, and drop-in sessions. We encourage you to also communicate clearly and robustly with all individuals involved in the project. The communication strategy offered an opportunity for us to keep everyone motivated and to champion the work being accomplished. Celebrate each other in this work!

Finally, and most importantly, remember that we do this project for people. Although it’s a digital project, the human is central to the experience. The UDL framework is intended to optimize learning for all, and the NYU Libraries’ LibGuides are intended to optimize learning for all learners as well. We always try to center the human experience in the work we do and justify why the project needs to happen. It’s an opportunity to identify and build empathy with and for each other. It is being done to make people’s experiences with digital content more successful and easy. It’s being done for learners with disabilities, but when we design for learners with disabilities, we inevitably make the content better for all.

Footnotes

Available on request.

Endnotes

“Universal Design for Learning Guidelines version 2.2,” CAST, last modified 2018, https://udlguidelines.cast.org.
“Universal Design for Learning Guidelines,” CAST.
Claudio Luís Vera, “The True Cost of Universal Accessibility,” Medium, January 26, 2019, https://uxdesign.cc/the-true-cost-of-universal-accessibility-7e496d678a9f.
“The Beginner’s Guide to Web Accessibility | Deque Systems,” Deque, accessed May 23, 2022, https://www.deque.com/web-accessibility-beginners-guide/.
“Justice Department Issues Web Accessibility Guidance Under the Americans with Disabilities Act,” U.S. Department of Justice, March 18, 2022. https://www.justice.gov/opa/pr/justice-department-issues-web-accessibility-guidance-under-americans-disabilities-act.
“What Is WCAG 2.1? Let’s Understand the History of WCAG First,” Deque, accessed May 23, 2022, https://www.deque.com/blog/what-is-wcag-2-1-history/.
“Advance Notice of Proposed Rulemaking – Accessibility of Web Information and Services of State and Local Government Entities and Public Accommodations,” U.S. Department of Justice, accessed May 23, 2022, https://www.ada.gov/anprm2010/web%20anprm_2010.htm.
Peter Schmidt, “One Activist Has Hundreds of Colleges Under the Gun to Fix Their Websites,” Chronicle of Higher Education (July 6, 2017), https://www.chronicle.com/article/one-activist-has-hundreds-of-colleges-under-the-gun-to-fix-their-websites/.
Peter Schmidt, “A Wave of Disability-Lawsuit Threats Against Colleges May Have Receded,” Chronicle of Higher Education (July 6, 2017), https://www.chronicle.com/article/a-wave-of-disability-lawsuit-threats-against-colleges-may-have-receded/.
Tucker Higgins, “Supreme Court Hands Victory to Blind Man Who Sued Domino’s Over Site Accessibility,” CNBC, October 7, 2019, https://www.cnbc.com/2019/10/07/dominos-supreme-court.html.
Schmidt, “One Activist”; “Web Accessibility Complaints Dismissed After Rules Change by DOE Office of Civil Rights,” Level Access, March 30, 2018, https://www.levelaccess.com/web-accessibility-complaints-dismissed-rules-change-doe-office-civil-rights/.
“Universal Design for Learning Guidelines version 2.2,” CAST.
“Designing for Accessibility with POUR,” AEM Center, accessed August 13, 2022, https://aem.cast.org/create/designing-accessibility-pour.
“Web Content Accessibility Guidelines (WCAG) 2.0,” Initiative (WAI), W3C Web Accessibility, accessed August 13, 2022, https://www.w3.org/TR/WCAG20/.

Bibliography

AEM Center. “Designing for Accessibility with POUR.” Accessed August 13, 2022. https://aem.cast.org/create/designing-accessibility-pour.

CAST. “Universal Design for Learning Guidelines version 2.2.” Last modified 2018. https://udlguidelines.cast.org.

Deque. “The Beginner’s Guide to Web Accessibility | Deque Systems.” Accessed May 23, 2022. https://www.deque.com/web-accessibility-beginners-guide/.

———. “What Is WCAG 2.1? Let’s Understand the History of WCAG First.” Accessed May 23, 2022. https://www.deque.com/blog/what-is-wcag-2-1-history/.

Higgins, Tucker. “Supreme Court Hands Victory to Blind Man Who Sued Domino’s Over Site Accessibility.” CNBC. October 7, 2019. https://www.cnbc.com/2019/10/07/dominos-supreme-court.html.

Initiative (WAI), W3C Web Accessibility. “Web Content Accessibility Guidelines (WCAG) 2 Level AA Conformance.” Web Accessibility Initiative (WAI). Accessed August 13, 2022. https://www.w3.org/WAI/WCAG2AA-Conformance.

———. “Web Content Accessibility Guidelines (WCAG) 2.0.” Accessed August 13, 2022. https://www.w3.org/TR/WCAG20/.

Level Access. “Web Accessibility Complaints Dismissed After Rules Change by DOE Office of Civil Rights.” March 30, 2018. https://www.levelaccess.com/web-accessibility-complaints-dismissed-rules-change-doe-office-civil-rights/.

Schmidt, Peter. “A Wave of Disability-Lawsuit Threats Against Colleges May Have Receded.” Chronicle of Higher Education (July 6, 2017). https://www.chronicle.com/article/a-wave-of-disability-lawsuit-threats-against-colleges-may-have-receded/.

———. “One Activist Has Hundreds of Colleges Under the Gun to Fix Their Websites.” Chronicle of Higher Education (July 6, 2017). https://www.chronicle.com/article/one-activist-has-hundreds-of-colleges-under-the-gun-to-fix-their-websites/.

U.S. Department of Justice. “Advance Notice of Proposed Rulemaking – Accessibility of Web Information and Services of State and Local Government Entities and Public Accommodations.” Accessed May 23, 2022. https://www.ada.gov/anprm2010/web%20anprm_2010.htm.

U.S. Department of Justice. “Justice Department Issues Web Accessibility Guidance Under the Americans with Disabilities Act.” March 18, 2022. https://www.justice.gov/opa/pr/justice-department-issues-web-accessibility-guidance-under-americans-disabilities-act.

Vera, Claudio Luís. “The True Cost of Universal Accessibility.” Medium. January 26, 2019. https://uxdesign.cc/the-true-cost-of-universal-accessibility-7e496d678a9f.

📘 Check out Universal Design for Learning in Academic Libraries: Theory into Practice

🔥 Sign up for LibTech Insights (LTI) new post notifications and updates.

✍️ Interested in contributing to LTI? Send an email to Daniel P. at Choice with your topic idea.