Advancing Accessibility Training Toolkit

Advancing Accessibility Training Toolkit (ADA Title II)

Created by Nicole L’Etoile, CEO and Founder, L’Etoile Education

Introduction

The Advancing Accessibility Training Toolkit is a guide designed to help public sector teams meet the new digital accessibility requirements under ADA Title II. 

Created specifically for procurement professionals, training developers, instructional designers, and their leadership, this toolkit breaks down what WCAG 2.1 Level AA compliance and how to integrate it into real-world workflows. Whether you're developing online courses, managing an LMS, or procuring digital content and platforms.

This resource provides a clear, phased roadmap to help organizations audit, plan, and implement accessibility best practices in alignment with the Department of Justice’s updated Title II regulations. 

For teams seeking a more comprehensive and personalized approach, including an audit, training, planning, and support, L’Etoile Education is available to work directly with you to tailor solutions that fit your needs and move you confidently toward compliance.

ADA Title II, enacted in 1990, requires state and local governments to ensure that people with disabilities have equal access to programs, services, and activities. While it didn’t name websites or mobile apps back then, courts and the Department of Justice have long interpreted “effective communication” to include digital formats as they became essential to accessing services.

The 2024 final rule just makes it explicit: digital content must meet WCAG 2.1 Level AA to be considered accessible.

Key Impacts

• Broad Applicability: The rule applies to all services, programs, and activities offered by state and local governments online and through mobile apps. This includes a wide range of entities such as state executive agencies, courts, legislatures, towns, cities, counties, school districts, universities, community colleges, water districts, special purpose districts, regional transit authorities, and AMTRAK. Any agency or department of state governments must comply.
  
  
• Technical Standard for Digital Accessibility: State governments are now legally required to ensure their websites, mobile apps, and digital documents (like PDFs, Word documents, spreadsheets, and presentation files) conform to WCAG 2.1, Levels A and AA. This means they must implement specific guidelines related to perceivable, operable, understandable, and robust content.
  
  
• Compliance Deadlines: State governments must meet these requirements within specific timeframes based on their population size.
  
  • State entities with a total population of 50,000 or more have two years from the date of publication (by April 24, 2026) to comply.
  • State entities with a total population of less than 50,000 have three years from the date of publication (by April 26, 2027) to comply.
  • The population of a state government entity is generally based on the overall state population according to the U.S. Census Bureau.
    
• Third-Party Content Responsibility: State governments are responsible for the accessibility of all web and mobile experiences they provide or make available, including content from third-party vendors and agencies. This means that if a state government contracts with a third party for a mobile app or web service, that app or service must also conform to WCAG 2.1 A and AA. State governments need to tighten their procurement requirements to ensure all purchased products and services meet these standards.
  
  
• Exceptions and Limitations: While the rule mandates WCAG 2.1 AA compliance, there are limited exceptions for certain types of content. These include specific conditions for archived web content, preexisting conventional electronic documents, content posted by unaffiliated third parties, individualized password-protected documents, and preexisting social media posts. 

Exceptions

• Archived web content: Web content that meets all four of the following conditions does not need to meet WCAG 2.1 Level AA:
  
  • The content was created before the date the state or local government must comply with this rule, or reproduces paper documents or the contents of other physical media (audiotapes, film negatives, and CD-ROMs for example) that were created before the government must comply with this rule.
  • The content is kept only for reference, research, or recordkeeping.
  • The content is kept in a special area for archived content.
  • The content has not been changed since it was archived.
    
• Preexisting conventional electronic documents: Electronic files such as PDFs, word documents, or spreadsheets created before the compliance date are generally exempt from WCAG 2.1 Level AA, with the following conditions:
  
  • The documents are word processing, presentation, PDF, or spreadsheet files.
  • They were available on the state or local government’s website or mobile app before the date the state or local government must comply with this rule.
  • However, this exception does not apply to documents that are currently being used to apply for, access, or participate in a state or local government’s services, programs, or activities; these must comply.
    
• Content posted by a third party: Content posted by third parties that are not under any contract, lease, or arrangement with public entities is exempt from WCAG 2.1 Level AA.
  
  • However, if third-party apps or web content are used to provide public services (e.g., a third-party payment processor for tuition payments), they must comply with ADA standards.
  • This exception generally applies to things like comments posted by the public on a government social media account or online message board.
    
• Individualized, password-protected documents: Private, secure electronic documents for individual use are excluded from Title II regulations if they meet all three of these criteria:
  
  • The documents are word processing, presentation, PDF, or spreadsheet files.
  • The documents are about a specific person, property, or account.
  • The documents are password-protected or otherwise secured.
  • This exception does not apply to general notices or information posted on a password-protected site.
    
• Preexisting social media posts: Social media content posted by public entities before the ADA compliance rules became applicable does not require adherence to accessibility guidelines. Posts made after the compliance deadline must conform to WCAG 2.1 Level AA.

It is important to note that even when these exceptions apply, state and local governments still have a general obligation under the ADA to provide individuals with disabilities with effective communication, reasonable modifications, and an equal opportunity to participate in or benefit from their services, programs, and activities.

This means that if a person with a disability requests access to content that falls under an exception, the public entity would likely still need to provide the content in an accessible format upon request.

Enforcement: The new rule does not introduce new enforcement mechanisms. The DOJ can use existing enforcement actions, such as filing lawsuits, administrative actions, or entering into settlement agreements, to ensure compliance.

Need for Action: State governments need to take proactive steps to achieve and maintain compliance. This includes:

• Learning about the rule's requirements in detail.
• Determining their specific compliance deadline.
• Identifying which personnel will have a role in compliance.
• Training staff on digital accessibility best practices and WCAG 2.1 requirements.
• Identifying all existing web content and mobile apps.
• Understanding the rule's exceptions.
• Determining which content and apps need to comply with WCAG 2.1.
• Evaluating the accessibility of their digital content and identifying necessary fixes, using both automated and manual testing, including feedback from people with disabilities.
• Prioritizing which content to remediate first, focusing on frequently accessed or essential content.
• Reviewing and updating contracts with vendors to ensure accessibility requirements are met.
• Creating and implementing digital accessibility policies.
• Establishing mechanisms for individuals to report accessibility barriers and for the state government to respond effectively.

In summary, WCAG 2.1 Level AA requirements under the updated ADA Title II rule compel state governments to ensure that their online services and digital content are accessible to individuals with disabilities by adhering to specific technical standards.

This necessitates a comprehensive effort involving policy changes, staff training, accessibility evaluations, content remediation, and careful consideration of third-party vendor relationships, all within defined compliance timelines. Failure to meet these requirements can lead to legal repercussions and, more importantly, hinder equal access to essential government services for people with disabilities.

Navigating the ADA Title II in E-Learning and Online Course Design

The new ADA Title II rules released by the U.S. The Department of Justice in April 2024 might seem daunting, but for those of us working in online course design, authoring tools, and LMSs, it’s a huge opportunity to create learning experiences that are inclusive for all. 

Understanding the New ADA Title II Rules for Online Learning

When online learning platforms or courses are inaccessible, learners with disabilities are excluded from education and professional development opportunities. Title II of the ADA now explicitly requires that all digital content, including online courses, e-Learning modules, and training materials, provided by or for state and local governments, meet WCAG 2.1 AA standards. This includes:

• Courses in a Learning Management System.
• Interactive content created with authoring tools like Storyline, RISE, or H5P.
• Videos, documents, assessments, mobile learning apps, and microlearning modules.

Accessibility Roadmap

Start by setting clear goals. Define what WCAG 2.1-2.2 AA conformance looks like for your LMS and course content. Prioritize areas that will have the most impact, such as public-facing content, high-use learning modules, or mandatory training.

To ensure long-term success, allocate the necessary budget and resources: assign responsible staff, set aside time, and plan for ongoing training. Break the work into achievable sprints that include remediation, retesting, and reporting.

Finally, include an Accessibility Statement prominently in your course or LMS footer, with clear contact information for users to report any barriers they encounter.

Follow This 6-Phase Roadmap

Phase 1: Needs Assessment: Audit Your Online Learning Content

• Audit current digital learning materials for WCAG 2.1-2.2 AA compliance.
• Audit all digital course components:
• Videos and multimedia (captions, transcripts, audio descriptions)
• Quizzes and assessments (keyboard accessible? screen reader friendly?)
• Slide decks and downloadable resources (use accessible PDF templates)
• LMS navigation (tab order, contrast, alt text, semantic headings)
• SCORM (Articulate Storyline, RISE, iSpring, etc)
• Embedded tools and third-party plugins ( H5P, simulations, external links)
• Example Project Timelines (2 and 3 years). 

Phase 2: Training: Train Your Course Designers and Developers

Train trainers on implementing WCAG success criteria and testing methods. 

Training should cover:

• Accessible design practices (heading structures, color use, alt text, closed captions).
• Accessibility checkers built into tools.
• QA checklists for LMS and SCORM packages.
• Creating accessible PDFs, Word Docs, and PowerPoints.

Offer:

• Initial full day training with ongoing and embedded support.
• Hands-on practice using accessibility tools.
• Updates when standards or tools change.
• Examples that show the real impact on learners.

Assign Responsibilities (RACI)

• Designers: Build accessibility in from the start.
• SMEs: Content clarity and review.
• IT: Platform and tool support.
• Compliance: Tracking and reporting.
• Leadership: Budget and policy.
• Trainers: Testing and support delivery.

Phase 3: Embed Accessibility into Course Design and Development

• In the design phase: Start with accessible templates, wireframes, and color palettes.
• During development: Use WCAG 2.1-2.2 checklists and built-in accessibility features.
• During testing: Include learners with disabilities when piloting content.
•  In QA: Test modules against WCAG before publishing.

Phase 3A: Collaborate with Third-Party Content Vendors

State and local governments are responsible for all content in their learning environment, including what you license or embed. Ensure any third-party features integrated into your digital platforms meet accessibility standards. Third-party content can often be a weak link in your accessibility chain, so ensuring these integrations are fully compliant with WCAG 2.1 AA standards is essential.

• Require accessibility in RFPs, scopes, and contracts.
• Ask for VPATs and accessibility documentation.
• Audit what they provide—don’t assume it’s accessible.
• Push back if vendors don’t meet WCAG 2.1 AA.
• Document everything and identify limitations. 

Phase 4: Pilot New Processes

• Test with a small group.
• Collect feedback on usability and clarity.
• Fix content issues before scaling.

Phase 5: Full Implementation

• Communicate timelines and expectations.
• Launch modules across your audience.

Phase 6: Evaluation

• Use surveys and audits to measure improvement.
• Track resolution of accessibility issues.
• Review and update materials quarterly.

Deep Dive Into Each Phase

The six-phase roadmap outlined above offers a high-level framework for implementing digital accessibility. In the following sections, we’ll take a closer look at each phase, breaking down specific actions, recommended tools, training strategies, and roles to help your team move from planning to full implementation with confidence.

Document Your Compliance Efforts

Keep detailed records of the following:

• All audits (who, what, when, results).
• Training sessions (topics, participants).
• Communications with vendors.
• Fixes made and retesting completed.
• Public accessibility statements and contact logs.

Get Help from Accessibility Experts

If you don’t have in-house accessibility pros you should hire experts to:

• Conduct audits on your LMS, authoring tools, and content.
• Help prioritize fixes and train your team
• Create accessible templates and reusable components
• Review VPATs from vendors and ensure compliance.

Reduce Legal Risk and Stay Ahead

Proactive compliance reduces exposure and shows good faith.

• Regularly review your LMS, plugins, and courses
•  Include accessibility in all project timelines and QA
• Address user complaints fast—don’t let issues linger
• Consult legal counsel if you’re unsure of your responsibilities

Communicate and Educate

Show your stakeholders and learners that accessibility matters to you.

• Publish an Accessibility Statement in your LMS
• Provide contact info for reporting barriers
• Run awareness campaigns for instructors and course developers
• Include learners with disabilities in testing and feedback loops

Conclusion: Start Now

Start with an audit. Build your roadmap. Train your team. And stay honest about what’s working and what’s not.

Who is Responsible? 

Accessibility is a shared responsibility. Anyone involved in creating, managing, buying, or maintaining digital content plays a role; including developers, designers, content creators, project managers, and educators. Building inclusive digital environments takes collective awareness, action, and commitment from every stakeholder.

Everyone involved in the creation, management, procurement and maintenance of digital content holds responsibility for ensuring accessibility. This includes web developers, designers, content creators, project managers, and educators. It is a collaborative effort that requires awareness and commitment from all stakeholders to make digital environments inclusive.

• Use the RACI Matrix to define roles for Designers, SMEs, IT, Leadership, Compliance, and Trainers.
• Shift Workflows for Instructional Designers, Teams, and Organizations. Each section provies resources to create or use, actions to take, and templates to adopt.

Accessibility Gap Audit Tools and Checklists

Track formats, WCAG Success Criteria met/missed, issue descriptions, and recommendations. Accessibility Checklist General Template for course reviews.

Accessibility Statement

We are committed to making this e-Learning module accessible to all learners. This course has been developed in alignment with WCAG 2.1 Level AA standards to support a wide range of access needs and ensure compliance with Title II of the Americans with Disabilities Act (ADA).

Your experience matters. If you encounter any barriers or have suggestions for improving accessibility, we encourage you to share your feedback. You may contact us through the method that works best for you:

•  Email: [accessibility@yourogranization.org]
•  Phone: 1-800-123-4567 (Mon–Fri, 9:00 AM–5:00 PM ET)
•  Text: 1-800-123-4568 (standard message rates may apply)

Prefer to submit feedback anonymously?  You can do so using our anonymous accessibility feedback form:  Anonymous Feedback Form Template

We welcome your input as we continue to improve the accessibility and inclusivity of our learning experiences.

Evaluate and Audit for Accessibility

Ensuring digital content is accessible requires a multi-method approach. Automated tools help flag common issues, manual checks provide essential human judgment, and user testing offers real-world insights from people with disabilities. Together, these strategies create a robust foundation for accessibility evaluation and continuous improvement.

Automated Checks

Automated accessibility tools are valuable for quickly identifying widespread issues such as missing alt text, improper heading structure, or color contrast problems. However, these tools have limitations and cannot replace human evaluation. 

Manual Review

Manual checks are a critical complement to automated tools. They rely on human observation to assess elements that automation often misses, such as:

• Logical heading structure
• Meaningful link text
• Sufficient color contrast
• Usability of keyboard navigation
• Accessible forms and tables

WC3 Test and Evaluate Method 

There are evaluation tools that help with evaluation. The WC3 Method is a good starting point. Review this method and tools to help you get started. 

Engaging Users with Disabilities

Involving individuals with disabilities in your testing process is essential for inclusive design. Real user feedback reveals practical challenges and usability gaps that tools and manual reviews might overlook.

Evaluating Vendors for Support

Understanding the VPAT and ACR

A Voluntary Product Accessibility Template (VPAT) is a standardized document that vendors use to report how their product or service conforms to accessibility standards, most notably the Web Content Accessibility Guidelines (WCAG) 2.1. When completed, this document is known as an Accessibility Conformance Report (ACR). Evaluating these documents is essential to making informed, compliant procurement decisions.

Key Areas to Examine in a VPAT/ACR

Completeness

• Ensure the VPAT addresses all relevant WCAG 2.1 Level A and AA criteria.
• Look for section coverage across applicable platforms (web, mobile, documents).
• Check for missing sections, vague summaries, or lack of scope definition.

Clarity and Specificity

• Support claims should be clearly explained with examples or test methods.
• Be cautious of generic language like “Supports” with no explanation.
• Look for real evidence of testing: tools used, date of evaluation, version of product tested.

Conformance Levels

• Common response options include: "Supports," "Partially Supports," "Does Not Support," and "Not Applicable."
• A product that lists numerous "Partially Supports" or "Does Not Support" entries without a remediation plan may not meet essential accessibility needs.
• Watch for overuse of "Not Applicable," which can indicate a lack of proper review.

Vendor’s Accessibility Commitment

• Does the vendor provide a roadmap or timeline for fixing gaps?
• Is there evidence of accessibility being embedded in their development lifecycle?
• Does the vendor offer training, documentation, or customer support related to accessible use?

Indicators of Weak ACRs

• Outdated reports or reports not aligned with the current product version.
• Absence of user testing involving individuals with disabilities.
• No mention of third-party evaluation or independent review.
• Contradictory support claims (e.g., claiming strong support for keyboard navigation while failing focus visibility).

Questions to Ask Vendors During Procurement

• Can you walk us through specific accessibility improvements made in recent product versions?
• Have you conducted usability testing with individuals with disabilities? What were the results?
• How do you handle requests for accommodations or support for users with assistive technology?
• Are you willing to remediate known accessibility barriers on a timeline?

Tips for Non-Technical Reviewers

• Focus on narrative clarity, not just checkboxes.
• Use plain language summaries of WCAG standards as reference points.
• Document red flags and follow up with vendors for clarification.
• Consider how each accessibility limitation would affect actual users—especially students, parents, and educators.

Documentation Tools

• Create an internal VPAT/ACR review template for consistency across reviews.
• Use automated tools alongside VPATs to verify claims.
• Maintain a central record of ACR reviews, vendor commitments, and accessibility concerns for audits or future renewals.

Selecting the Right Accessibility Partners

Here’s a set of essential questions to help you vet accessibility partners. 

Key Questions to Ask Accessibility Consultants:

• Have you created self-paced or instructor-led content for public-sector clients?
• Do you have examples or case studies of LMS-based courses built for compliance?
• What challenges have you faced when aligning e-Learning modules with accessibility standards, and how were they solved?
• How do you embed WCAG standards into course content and LMS structure?
• What tools do you use for accessibility testing in e-Learning content?
• Can you walk us through an example of remediating a course?
• Who on your team is trained in accessible instructional design?
• Are you (or team members)-certified or otherwise credentialed in accessibility?
• How do you stay updated with evolving best practices in online course accessibility?
• Do you audit the LMS, embedded tools, and authored SCORM/xAPI content?
• How do you report findings and suggest fixes for inaccessible learning content?
• Can you share an example of a completed audit for an LMS or self-paced course?
• How do you decide what to fix first in a course or learning platform?
• What’s your workflow for remediation and retesting?
• How do you ensure updates stay compliant over time?
• Do you test LMS navigation and SCORM/xAPI content across browsers and devices?
• How do you include people with disabilities in usability testing?
• What kind of test reports do you deliver (screenshots, fix instructions, etc.)?
• How do you support clients in maintaining accessibility across course updates?
• Do you offer ongoing check-ins, monitoring, or audit services?
• Who is responsible for long-term maintenance: you, us, or both?
• What training formats do you offer (workshops, self-paced, train-the-trainer)?
• How do you teach teams to create accessible content?

WCAG 2.2 Quick Reference Guide

To support your team in designing and evaluating accessible digital content, we’ve included a WCAG 2.2 Quick Reference Guide.