Contents

1. Introduction
2. Policy Requirements
3. Websites
4. Purchasing & Procurement
5. Multimedia Accessibility and Course Videos
6. Documents & Internal Communication Tools
7. Social Media
8. Temporary Exceptions
9. Available Assistance
10. Policy and Procedures Terms and Phrases

I. Introduction

On April 11, 2023, Harvard University announced an updated Digital Accessibility Policy, that sets forth accessibility expectations to all new digital content created and used internally at the University, as well as technology systems, platforms, and applications bought or built by the University, starting June 1, 2023. The Policy calls for the University to publish “Digital Accessibility Implementation Procedures” (the “Procedures”) to provide interpretation and guidance; identify resources, support, and infrastructure relating to digital accessibility; and explain how members of the University community can meet the Policy’s requirements.

The Procedures were developed by the University Accessibility Committee’s Digital Accessibility Working Group (DAWG) and formally adopted by the Accessibility Steering Committee (ASC). The DAWG and ASC will update the Procedures regularly to reflect new technological and structural developments at the University and feedback received from the University community.

II. Policy Requirements

The Policy applies (1) to “University Content”, which it defines to mean “any information or communication accessed or displayed in a digital format or medium, as text, image, audio, or video,” that is “created, posted, distributed or published for University Business.” and (2) to “University Information Technology”: i.e., information technology that is “purchased, developed, deployed, or used for University Business and, in the case of web-based applications and websites, is hosted on a Harvard-owned or -controlled domain.” The Policy in turn defines “University Business” to include “activities carried out under the auspices of Harvard University,” except for “activities organized or conducted by students or student organizations.” These Procedures give further definition to “University Information Technology,” “University Content,” and “University Business,” with supporting examples.

The Policy’s requirements of University Information Technology and University Digital Content are as follows:

1. Starting on June 1, 2023, “Harvard users using University IT to post, distribute, or publish University Content should aim to make such content conform to the Standards, to the extent technically feasible.”
2. “Instances of University Information Technology newly purchased, licensed, or internally developed after June 1, 2023 are expected to conform to the Standards to the fullest extent possible at the point of rollout or implementation.”
3. “The Accessibility Steering Committee will establish and recommend to Senior Leadership a prioritization plan for improving the accessibility of existing University Information Technology, including websites and web-based applications, and the existing University Content hosted, published, or communicated on those platforms. Priority will be given to University IT platforms that provide the most essential functions to, and are most broadly and regularly used by, Harvard faculty, staff, and students. In the case of public-facing websites, priority will be given to sites that are among the most highly trafficked and to those that contain core institutional information.”

The “Standards” in the Policy are the Web Content Accessibility Guidelines, version 2.1, Level AA Conformance (“WCAG 2.1 AA”). These Procedures elaborate key concepts, including “created or produced at Harvard” and “substantial revisions or redesign,” in the Policy and Procedures Terms and Phrases section below.

The Digital Accessibility Policy also covers non-Harvard created platforms, products, and services used for University Business including:

• Work done by vendors that develop, host, manage, or provide products and services.
• Platforms with online components, such as websites, mobile applications, or software-as-a-service (SaaS) platforms.
• Products or systems intended for use or access by Harvard students, alumni, faculty, staff, applicants, prospective students, and/or members of the general public.

III. Websites

A. Identifying a Site Owner for a University Website

A Site Owner is the designated role or individual responsible for a University Website. Site Owners are responsible for the accessibility of their sites and must hold content creators, developers and other necessary parties accountable for ensuring the site’s accessibility. Site Owners are determined by the applicable unit's Dean, Vice President, Chair and/or Director. Site Owners may not have the technical knowledge or expertise needed to ensure that their “owned” websites conform to the Policy. While a Site Owner is an individual person, these Procedures recommend that Site Owners be assigned based on their roles, as individuals tend to change roles at the University over time.

1. Examples of Site Owners:

• Three different laboratories each have their own website. Organizationally, the labs report up to a Department. The Department reports up to a Division. The Division reports into a School. The applicable School's Dean, Vice President, Chair and/or Director is responsible for holding an appointed individual on behalf of the Division and Department accountable for the accessibility of the lab websites. Appointed individuals may be the Director of Communications, a specified Associate Dean, or the PI of the lab, as the School deems appropriate.
• An interfaculty initiative (IFI) creates a site to promote its annual event. Organizationally, the IFI reports up to The Office of the Provost. The Provost is responsible for holding the IFI accountable for the accessibility of the IFI website. The appointed Site Owner may be the Director of the Initiative or a designated Associate Provost but should not be ”the Office of the Provost.”

B. Reporting and Responding to Accessibility Issues

The Policy expects University Websites to indicate their commitment to accessibility by including a link to the Harvard Digital Accessibility Policy from each web page. (This can be accomplished most effectively by including the link in a footer or other web element that replicates across all pages of the site.) The "Report a Web Accessibility Concern" form is linked from the Policy page, providing the primary means for users to submit requests or express concern about a particular University Website.

The Digital Accessibility Services (DAS) team within Harvard University Information Technology (HUIT) will triage requests submitted via this form and route them to the relevant Site Owner and Digital Accessibility Liaison (DAL) for follow-up. Site Owners who learn of a user accessibility issue through other channels also should submit the issue using the “Report a Web Accessibility Concern” form so that all such concerns can be cataloged centrally. Site Owners should ensure that prompt efforts are undertaken to address any reported barriers to access. If Site Owners are unable to address the issue promptly, the Site Owner and the DAL should contact University Disability Resources to discuss options for an accommodation.

C. Site Remediation

Under the Policy, the Accessibility Steering Committee may require a Site Owner to establish a plan to improve some or all non-conforming portions of an existing University Website. This may include websites and their content that would not otherwise be required to conform, such as a site created or revised prior to December 1, 2019 or access-restricted content created prior to June 1, 2023. In prioritizing websites for remediation, the ASC will consider several factors, including:

• How essential the website or its content is to University functions (i.e., is it functional or informational?);
• Whether the Site Owner is already planning a redesign;
• Target audience (i.e., is the website directed to internal or external users?); and
• Size of audience.

1. Remediation Process

The ASC will refer identified sites to DAS for further evaluation. The DAS team will in turn contact each applicable Site Owner and DAL to provide information about their site and identify resources available to support remediation. DAS may assist Site Owners in prioritizing what to improve and how to approach the work, such as through incremental updates made by existing staff, through contracted work, and/or through platform migration. Site Owners must provide an evaluation report to the ASC enumerating efforts and periodically demonstrating progress.

D. Evaluating a University Website for Accessibility

Automated testing tools speed up the process of evaluation and allow for regular monitoring. However, human evaluation is also essential to assessing a website’s accessibility, because no single tool can determine to what extent a site conforms to the Standards.

1. Automatic scanning

The use of automatic testing tools is recommended as a first step to scan and assess the broad level of accessibility for a University Website.

2. Manual testing

Assistive technology, keyboard-only testing, and content review should be used as part of manual testing. The University’s Digital Accessibility Services provides guidance and training on how to test with a screen reader and keyboard and how to report and remediate issues.

3. Expert review

An experienced professional can perform a deeper evaluation, which typically results in a detailed listing of issues and specific recommendations for improvements. DAS can assist with identifying reputable third-party service providers to conduct an expert review as needed.

IV. Purchasing & Procurement

If you are contracting with a vendor, tool, or service outside Harvard for a technology product, the agreement is subject to the Digital Accessibility Policy. Purchasing approvers are responsible for the procurement of accessible products, via the process outlined below.

Establishing accessibility expectations early with vendors helps ensure that accessibility will be included and prioritized going forward. You can start with this list of accessibility questions for vendors.

A. Accessibility Rider

An Accessibility Rider should be considered for all technology contracts. By signing the Rider, a vendor commits to delivering a product that conforms to Harvard’s accessibility standards. Having a signed Rider will make it much easier to address accessibility issues promptly if they should arise after the product is in use. Download the Accessibility Rider (Word document, HarvardKey required) from the Office of General Counsel (OGC) website.

B. Accessibility Roadmaps and Temporary Exceptions

If the vendor is unwilling to commit to the requirements described in the Accessibility Rider, the University should work with the vendor to extract other assurances and commitments toward eventual compliance with Harvard’s accessibility requirements. A common and appropriate fallback position from the Rider is an “accessibility roadmap” that identifies accessibility issues to be addressed and establishes the timeline for the vendor to address them. Periodic check-ins with the vendor should also be scheduled to measure progress against accessibility goals. Contact DAS (digitalaccessibility@harvard.edu) for help developing an accessibility roadmap.

If needed, you may request a temporary procurement exception. A temporary exception ensures that purchasers and their approvers understand accessibility limitations and how they might work around them as required. They are signed by leaders approved by the Accessibility Steering Committee (ASC). Such designated signers take on responsibility for monitoring progress on the status of temporary exceptions and reporting periodically to the ASC.

C. Saving the agreement

Save any key accessibility documentation along with the contract. If you’re documenting the contract in Harvard’s Buy-to-Pay (B2P) system, contact the Contract Manager for document uploading. Learn more about how to document accessibility in B2P.

D. Renewing a contract

When renewing a contract, the Accessibility Rider should be reintroduced, whether or not it was signed previously. Accessibility documentation should also be reviewed for renewal, including:

• Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR)
• Past Roadmaps/Temporary Exception Forms, and
• Other vendor documentation.

V. Multimedia Accessibility

All videos posted to University Websites and platforms must include synchronized, accurate, closed captions and should aim to include descriptive audio where applicable. Audio files, such as podcasts, that are posted to University Websites and platforms should be accompanied by accurate transcripts.

A. Captions

Captions convert audio dialogue and sounds into text that appears on a video, synchronized with audio. High-quality captions include highly accurate transcription, proper punctuation, speaker identification, and the identification of meaningful sounds other than speech.

Captioning must have an accuracy rate equal to or greater than that offered by a third-party vendor captioning service such as 3Play Media or Rev, and in a manner consistent with industry standards regarding synchronicity, completeness, and placement.

B. Transcripts

High-quality transcripts include accurate transcription, proper punctuation, speaker identification, and the identification of meaningful sounds other than speech.

Audio segments and podcasts posted on University Websites and covered by the Policy must be accompanied by a full transcript. These transcripts either must be available on the same page as the audio player or linked directly from the description text.

C. Descriptive Audio

If a video includes content that is only presented visually, such as on-screen text, graphics, or actions that are not obvious from the audio, this visual information would need to be described in order to be accessible to people who are unable to see it. By planning ahead, a video producer can script and create content that includes descriptions of meaningful visual elements and actions in many cases.

If it’s not possible to describe visual information within the script or audio, then there may be situations where it is appropriate to provide more extensive audio description as a further enhancement to accessibility. Additionally, providing meaningful content from a video (i.e., code snippets, math equations, graphs, tables, image details) presented in accessible formats alongside multimedia to be explored at their own pace should likewise enhance accessibility and overall experience.

D. Live video captions

Harvard events that are live-streamed through third-party platforms are not generally subject to the Policy. However, events streamed on a third-party platform but embedded within a University Website would be subject to the Policy.

The University live-streams a wide range of content ranging from massive events such as Commencement to small activities within labs or departments. For live-streaming that is covered by the Policy:

• University-wide events (such as Commencement, ceremonies for special honorands, and presidential installations) for which video and/or audio are live-streamed over the Internet must be live-captioned to industry standards.
• For School-wide events or other larger events that are advertised and expected to generate substantial audiences, and for which video and/or audio are live-streamed over the Internet, the University strongly urges that industry-standard live captioning be provided as a matter of course.
• For smaller events for which video and/or audio are live-streamed over the Internet, the University recommends in all cases that the hosting department offer in advance the opportunity for individuals with disabilities to request an accommodation. See the University’s captioning resource page for further instructions on how to obtain live captioning or Communication Access Realtime Translation (CART) services for a particular event.

In all cases where video of a live event is later posted to a Harvard website, such videos must be captioned as required by the Policy.

E. Course Video Content

Multimedia used as part of University courses should be made as accessible as possible. Efforts should be made to follow best practices to ensure that some level of captioning is available both live and in recordings, and that the audio source is of a high quality.

1. Course content that must have professional media alternatives

Multimedia content must have professional-level captions or transcripts (at least equal to the accuracy of a quality, third-party provider) if a student or instructor makes an accommodation request, which should be communicated through a Local Student Disability Coordinator (LDC).

2. Course content that should be prioritized for professional media alternatives

Multimedia content should be prioritized for professional-level captions or transcripts (at least equal to the accuracy of a quality third-party provider) when:

• The same audio or video files are used repeatedly in courses over time,
• Video / lectures are the primary source of learning (i.e., in a “flipped classroom” setting), or
• Courses with over 100 students (beginning no later than the start of the 2024-25 academic year)

Over time, the Policy expectation for course video content may expand to require more use cases to have professional-level captions and transcripts. Efforts should be made now to improve multimedia accessibility generally and to prioritize content that will have the greatest impact.

Note: Notwithstanding the Policy or these Procedures, in cases where a student is unable to access multimedia (or other) course content because of disabilities, a School will be required to provide Standards-conforming content or provide information that is accessible by alternate means. Schools and instructors can anticipate and avoid last-minute adjustments to provide course content if they undertake in advance to provide Standards-conforming content, regardless of whether an enrolled student has identified a disability.

3. Best practices for all courses

For live classroom lectures and presentations, auto-generated captions should be enabled where available. When preserving recordings of lectures and presentations, captions should remain with the file recording.

Speakers should apply the following best practices to maintain a high quality of audio for improved accessibility in their recordings:

• Use a well-placed microphone when available.
• Introduce yourself before speaking (especially when multiple speakers are present).
• Describe meaningful graphics and visual content.
• Announce slide titles and/or slide numbers.
• Repeat audience questions prior to answering.

4. Third-party multimedia content

Harvard instructors may share multimedia from other authors or from sources that originate outside of Harvard. This may include streaming video and course reserves. Instructors should make a good-faith effort to ensure that all multimedia shared in Harvard classes, regardless of their origins, includes captions, transcripts, and/or descriptive audio. In cases where the content as found elsewhere does not include these accessibility assets, DAS or LDCs may be available to consult with instructors about ways to provide them.

VI. Documents & Internal Communication Tools

Documents that are created and shared at Harvard, whether posted on a public-facing website or communicated internally, should aim to meet accessibility guidelines. Document creators and editors can use built-in tools such as Microsoft’s Accessibility Checker, the Grackle Accessibility Checker in Google Workspace, and the Adobe Accessibility Checker that flag issues and suggest solutions. The Digital Accessibility Services (DAS) team has guidance on accessible documents and offers training on creating accessible Word documents, presentations, and PDFs.

Documents that need professional accessibility remediation can alternatively be sent to third-party document remediation vendors, especially those with which Harvard has preferred contractual agreements.

When communicating internally at Harvard, use University-provided tools and platforms such as Microsoft 365, Slack, and Teams, etc. When sharing information, follow accessible communication best practices such as describing images, writing clear link text, and using emoji mindfully.

VII. Social Media

Social media accounts at Harvard should strive to ensure the content they share is accessible to all audiences, within the limitations of the platforms themselves. When sharing content, follow Harvard’s accessibility best practices for social media (HarvardKey required), including adding image descriptions, captions, and color contrast when posting.

VIII. Temporary Exceptions

A. Temporary Website Exception

In order to request a temporary exception to the Harvard University Digital Accessibility Policy, those responsible for University IT (including websites or web based applications) are required to submit a Policy Exception Request Form (HarvardKey required) to the Accessibility Steering Committee (ASC) for approval.

Exception requests must include a detailed description as to why conformance with the Policy is not technically feasible or would cause undue hardship. Site owners requesting an exception will be required to submit an Equally Effective Alternate Access Plan (EEAAP) detailing how information will be made available to individuals with disabilities until conformance with the Standards is achieved. According to the Policy, “insufficient funds of a particular unit will not be considered a valid reason for an exception except in extraordinary circumstances and as approved by the [ASC].” Exception requests will be reviewed by the ASC within 30 days. Documentation of exception requests and their disposition will be retained by the ASC, which will undertake periodic review of the exceptions process. Examples of content that could be appropriate for a Policy exception, depending on the circumstances and resources available at the time of the request, include (but are not limited to):

• Computational spreadsheets containing program modules or macros that were developed to perform automated analysis or draw data from external or legacy databases.
• Third-party licensed documents from scientific journals or conferences (e.g., where the license agreement does not allow the user to modify the file or where the files are hosted and updated by the journal on its server).
• Scanned written or poor image/text quality historical documents or publications that are in a digital archive and/or Archived historical legacy files.
• Complex dynamic visualizations such as medical diagnostic or research imaging technologies, 3D models, virtual environments, or computer-aided design (CAD) software.
• Complex math, physics, chemistry and other scientific notations.
• A collection of videos without captions on a website.

B. Temporary Procurement Exception

When a vendor is not yet able to provide fully accessible technology, but a roadmap has been established that shows their plan for bringing the technology into compliance, a Temporary Exception for Accessibility form (PDF) can be filed that will grant a one-year exception to the Accessibility Rider. The Temporary Exception Form explains the limitations of the vendor’s accessibility and their commitment to improving, while also allowing the University’s product owner to consider how someone needing an accessible product might still gain equivalent access. It should be retained along with other contract documents for a vendor.

In accordance with the Digital Accessibility Policy, the Temporary Procurement Exception may be signed by leaders approved by the ASC, including the CIO of the School/unit or the Vice President and University CIO. As the scope of the Policy expands across the community, other approvers of Temporary Exception forms may be approved by the ASC. A request for additional Temporary Exception Form approvers must be submitted to the ASC for review in writing via digitalaccessibility@harvard.edu. Such designated signers take on responsibility for monitoring progress on the status of temporary exceptions and reporting periodically to the ASC.

IX. Available Assistance

We all have a role to play in making Harvard’s digital information more accessible. In addition to the recommended manual testing tools and other self-service resources detailed above, the University has established networks of experts available to the community for consultation.

A. Digital Accessibility Services (DAS)

Digital Accessibility Services (DAS), within Harvard University Information Technology, supports the University in creating and sustaining a culture of commitment to accessibility at Harvard. DAS is a team of accessibility professionals that provides training, guidance, and information on accessibility standards and best practices, working directly with Site Owners, Digital Accessibility Liaisons, and their technical partners to advise or augment their efforts towards adopting the Standards. The DAS team hosts virtual Office Hours regularly and may be contacted by emailing digitalaccessibility@harvard.edu.

DAS administers enterprise tools and services used at Harvard for monitoring or improving digital accessibility. DAS’ work, guided by ASC’s priorities, includes tracking, supporting, and reporting on remediation efforts across Harvard.

B. Digital Accessibility Liaisons (DAL)

In accordance with the Digital Accessibility Policy, the University has established a network of Digital Accessibility Liaisons (DAL) to coordinate local efforts, facilitate training, and monitor progress. The DALs are appointed by Senior Leadership from within each School and administrative unit to monitor and assist accessibility efforts for their School/unit’s web pages and web applications. DAL are local contacts for digital accessibility and are available to assist their local communities in identifying resources to ensure the accessibility of their School/unit’s web pages and web applications. They work in concert with the DAS team. DAL will be notified by DAS when an accessibility request is received regarding a University Website or application overseen by a Site Owner in their School/unit. DAS oversees accessibility issue reporting, and they may assist Site Owners and DAL in preparing appropriate responses or action plans if necessary.

C. University Disability Resources (UDR)

The University Disability Resources (UDR) office within Central Administration serves as a University-wide resource on disability-related information, procedures, and services for the Harvard community, digital and otherwise. DAS collaborates closely with UDR, considering the many dimensions of accessibility to make Harvard a more inclusive and welcoming campus to persons with disabilities.

D. Training and Support

To assist the Harvard community in meeting the responsibilities described here — spearheaded by DAS but offered by many local teams across campus — training and support resources are readily available to those responsible for creating or maintaining University IT (including websites) and University Content. The training and support includes information about Harvard’s Digital Accessibility Policy, along with guidance on how to create accessible web content and documents, how to make websites and web-based applications accessible, how to perform manual checks and use automated tools for evaluation, and how to get help.

E. Available support for vendor procurement

Purchasing approvers are responsible for accessibility by ensuring that contracts with vendors or suppliers seeking to develop or provide University IT or University Content hold those vendors and suppliers accountable to the Standards. The Office of Strategic Procurement, the HUIT Vendor Management Office, the procurement managers reporting to the several Schools’ Chief Information Officers, and other website or web application product owners shall assure that contracts address accessibility in accordance with the Digital Accessibility Policy. DAS provides guidance, procurement training, and resources about Harvard’s procurement process, the Accessibility Rider, and how to engage with vendors to ensure they deliver an accessible product.

X. Policy and Procedures Terms and Phrases

A. University Information Technology

“University Information Technology” or “University IT” is Information Technology purchased, developed, deployed, or used for University Business and, in the case of web-based applications and websites, is hosted on a Harvard-owned or -controlled domain.

“Information Technology” includes software; server-based, personal computer, mobile device, and web-based applications and websites; website hosting and design services; development, hosting, maintenance, and archiving services; cloud-based applications and information processing or storage services; digital hardware interfaces; and digital database configurations and interfaces.

1. Examples of University IT:

• Website integration software and plugins, such as calendar tools, maps, social media embeds, and media players
• Social media scheduling and planning tools
• Email campaign design platforms
• Whiteboarding and collaborative design tools
• Data visualization or design tools
• Video platforms

B. University Content

“University Content” is Digital Content created, posted, distributed, or published for University Business.

“Digital Content” consists of any information or communication accessed or displayed in a digital format or medium, as text, image, audio, or video.

1. Examples of University Content:

• Text, multimedia, and other content posted on public-facing and access-restricted University websites
• Documents shared internally via email or posted on University websites
• Images, video, or other content posted on social media platforms
• Course materials posted and shared on Learning Management Systems such as Canvas

C. University Business

“University Business” includes activities carried out by Harvard faculty and staff in furtherance of Harvard University’s mission of teaching and research but does not include activities organized or conducted by students or student organizations.

1. Examples of What Is and Is Not University Business:

• A Harvard professor who posts content online that describes a recently completed research project is engaged in “University Business.”
• A Harvard graduate student working as a research assistant in a laboratory posts content on a website that relates to her work; this is considered “University Business.” The same graduate student’s online efforts to organize a kayaking trip are not “University Business.”
• Harvard engages a vendor to produce videos that document events on campus. The vendor uploads those videos to a Harvard website. Although the vendor is not a Harvard employee, the videos do relate to “University Business.”
• A Harvard employee with HarvardKey access creates a website on a Harvard web platform for colleagues who are interested in rock climbing and related meetups. The website is not related to “University Business.”

“Senior Leadership” includes the University’s President, Provost, Executive Vice President, and Vice Presidents; the Deans of the several Schools, their Department Chairs, and the Directors of University and School Centers or their designees.

---

Last updated: June 1, 2023