New federal requirements under ADA Title II mandated that all digital content at public higher education institutions meet WCAG 2.1 accessibility standards. Beyond compliance, there was a recognized gap in faculty and staff awareness of both digital accessibility practices and existing accommodation procedures. The need was identified and championed by the Office for Civil Rights and Title IX Education and Compliance, making this a high-stakes, institution-wide initiative.
The primary audience was all higher education faculty and staff, a broad and mixed-knowledge group. The training was designed assuming little to no prior accessibility knowledge, while remaining relevant to those with more experience. Because the audience included people taking the training independently across different devices, browsers, and assistive technologies, designing for diverse access needs was not just a consideration but a core requirement. Learners ranged from classroom faculty managing student accommodations to supervisors navigating employee accommodation processes, each with distinct roles and responsibilities.
The project followed an ADDIE framework, moving through each phase deliberately. During the analysis phase, our team of three IDs met separately with each SME group to gather input on what content was essential, taking detailed notes and organizing them into a shared Google Doc outline. We then brought all SMEs together in a single meeting to consolidate, prioritize, and cut content, a process that went through four rounds of revision before a final version was sent to legal for review and approval.
Once the content was finalized, the team moved into development using Adobe Captivate, a tool none of us had prior experience with. Rather than diving straight into building, I used the ramp-up period strategically. So while the team completed tutorials, I tested Captivate's interactive widgets with a screen reader and keyboard navigation to identify which components were accessibility friendly and which had limitations that couldn't be customized. This upfront vetting shaped the entire build and meant that very few slides required a full redesign after user testing.
ADDIE provided the overall process structure, while Universal Design for Learning (UDL) guided the design philosophy throughout. Because the training was about accessibility, it was especially important that the course itself model accessible design, not just describe it. UDL principles showed up in decisions around structure, navigation, and multimodal content so that learners across a wide range of abilities, devices, and contexts could engage effectively.
The team faced several compounding challenges. Adobe Captivate was a brand-new tool for all three IDs, chosen for budget reasons. It came with a steep learning curve and significant limitations. The platform offered limited customization options, and after testing Captivate's interactive widgets for accessibility early in the project, it became clear that many were not compatible with screen readers or keyboard navigation, with no built-in way to fix them. This narrowed our already limited design options further. On top of that, Captivate proved unstable across the team's devices, with the software eventually crashing for two of the three IDs, requiring us to adapt our entire collaboration workflow mid-project.
Each challenge was met with a practical workaround. Early in the project, I documented which Captivate widgets passed accessibility testing and created a working list the team used throughout the build, so we never wasted time on components we knew wouldn't work. When Captivate became unreliable for my teammates, the team shifted to a screen-share model over Microsoft Teams, with one person driving while the others advised, which actually gave everyone visibility into the build process. As the most technical member of the team and the only one whose Captivate remained functional, I took on the majority of the building and editing work. When Captivate's built-in keyboard focus indicator failed to meet WCAG contrast and visibility standards and the platform offered no way to customize it, I located the HTML file inside the SCORM package and wrote CSS code directly to bring it into compliance, a solution that required going well outside the tool's intended workflow.
Our ID team met every other week during the planning and content development phases, increasing to one to two times per week once active building began. Over time the team developed organic roles: one ID handled scheduling and project organization, one served as the lead communicator and primary stakeholder contact, and I functioned as the technical lead and primary builder, though all three of us contributed across areas as needed. SME groups were engaged in separate meetings during the analysis phase, then brought together as a full group to consolidate and prioritize content. Four rounds of revision followed before legal review. When significant disagreements arose that the team couldn't resolve internally, they were escalated to the Office for Civil Rights, the department that commissioned the training, for a final decision, keeping the project moving without stalling on contested content.
The most significant change for a second iteration would be the authoring tool. Adobe Captivate is no longer being actively updated, and its limited customization options created real constraints around accessibility. Moving to a more flexible platform like Articulate would open up more accessible design options and a smoother collaborative workflow. On the content side, some sections of the training are denser than they could be, though much of that text was legally reviewed and approved language that fell outside the design team's control. A future version might explore ways to present that required content in a more digestible format without altering the legal wording itself.
This was my first experience seeing a full course design process from start to finish, and it was formative. Working alongside two experienced instructional designers who served as mentors gave me a grounded understanding of how a project like this actually moves, who needs to be involved at each stage, and how to bring a large and varied group of stakeholders to shared decisions. I came away with a much clearer sense of how to work with SMEs effectively and when to bring them into the process. I also learned to build more generous timelines around post-testing revisions, having felt the pressure of a tight window after usability testing on this project. Technically, this project pushed me further than I expected, from learning a new authoring tool under real constraints to writing CSS inside a SCORM package to solve an accessibility problem the tool couldn't handle on its own. It reinforced that my accessibility expertise is not just a specialty skill but a core part of how I approach every design decision.
A PDF export of the course slides is available below.
.pdf)