Learning experience designers exist in a dynamic ecosystem that demands innovation and, subsequently, constant upskilling. Our three-person group from LILE’s Learning Experience Design team—Catherine Lee-Cates, Hannah Rogers, and Maria Kunath—seized an opportunity to innovate by upskilling our team’s accessibility practices via the redesign of a Divinity school project.
Innovation is a powerful process of re-envisioning an established thing, but it needs an objective or it burns out. Think about it like the intersection of thrifting and craft. You can’t maximize the potential of a fabulous second-hand glue gun without applying it to a project. En route to your final DIY product, you’ll probably realize you need to upskill, the subproject of learning new skills needed to reach the goal.
In early 2024, our team was tasked with moving Rediscovering the Heart of Methodism (RHM)—a five-course legacy project between Duke Divinity School and LILE—from its original WordPress site to Coursera, one of the world’s largest online learning platforms. But it quickly became clear that the course workbooks—a key component of the original courses—were not accessible to screen readers. Accessibility involves the practice of designing learning experiences that meet the needs of the widest group of learners possible. Accessible documents need to be able to be read by a screen reader, a tool that makes digital materials accessible for individuals with vision impairment.
Why prioritize accessibility? Learning experience design as a discipline centers on the value of students’ successful achievement of course learning outcomes. Accessibility options in learning design—such as being able to use screen readers— are key to student success. They reduce barriers to learning by giving students the ability to customize learning experiences based on their personal needs. Digital accessibility is measured against the Web Content Accessibility Guidelines (WCAG). As we scoped the RHM project timeline, we realized that Coursera’s built in accessibility features would make most of the course accessible, but the course did not meet WCAG standards.
Notably, the workbooks would need to be restructured to become screen reader accessible before they would meet WCAG standards. Tag structure was missing from the original versions of the RHM workbooks built in Google Docs. Tag structure is the hierarchical foundation of a PDF that allows screen readers to navigate a page’s read order, essentially allowing it to read aloud all components of a page in the same order a sighted reader would instinctively read a page. Furthermore, we needed to redesign how we were allowing learners to answer questions in the workbook. In the original, there were lines to write beneath each question, but this design signaled that the workbook could only be used if it was printed. Therefore, we decided to add a fillable form beneath each question, so the documents could be used digitally or online. We needed an efficient process to convert all five workbooks to accessible documents within the project timeline. Part of our project timeline became dedicated to the process of upskilling our accessibility knowledge and practice.
Joel Crawford-Smith, a senior web accessibility admin at Duke, helped us create a new process. This more efficient method of building accessible documents started in Microsoft Word, where accessible headings and alt text would be applied, before the document would be exported to Adobe Acrobat. Next, the designer would organize the tag structure in Adobe Acrobat. The final product would be accessible to screen readers. In one of our first email conversations, Crawford-Smith wrote, “I like to say it takes a human to test for a human.” There’s a plethora of automated accessibility tools entering the ed tech market. These tools scale accessibility practices, but they still need to be checked by experts trained in accessibility. Practicing accessibility puts the designer in a relationship with the user. Accessibility isn’t a disembodied practice, but a tangible approach to caring for the learners who use online courses.
The iterative nature of this project—moving five courses to Coursera over the course of five months—gave us the opportunity to upskill one third of the LXD team in accessibility within the bounds of the project timeline. The first accessible workbook took about one month to design and develop. However, by the fifth workbook, our team was able to design an accessible document in Word, export it to Adobe, and QA it in under a week. We learned that upskilling takes time, but when planned with the help of experts, it is a win-win way to center care for learners in the practice of learning design.
Creating your own accessible, interactive PDF
Whether you’re looking to create a one-page handout or a full workbook like our team did, you’ll want to follow the same steps to upskill and ensure your PDF is accessible.
First, you’ll need to make sure you have the correct tools. You’ll need access to both Microsoft Word (if you’re Duke affiliated, you can install Microsoft 365 from OIT) and Adobe Acrobat (if you’re Duke affiliated, you can learn more about how to get access to Adobe). You’ll use Word to create the document and lay a foundation for a final accessible PDF. You’ll want to make sure everything in Word is finalized how you want before creating a PDF version of the document. Then, you’ll use Adobe Acrobat to add the interactive elements and check for accessibility. This portion of the blog will go over the big-picture steps of how to create an accessible PDF, but we’ll be linking out to great resources that already exist that you’ll want to review.
Creating Accessible Documents in Word
A key principle of our team’s design philosophy is to design for accessibility from the start. As accessibility experts have noted time and again, it’s much easier to center accessibility than to remediate documents that violate Web Content Accessibility Guidelines (WCAG) after they’ve been released. In the case of creating an interactive PDF, ensuring that you’re following accessibility guidelines in Word is how we start to do this.
If you don’t have experience with accessible design in Word, we recommend that you first read through the Word documentation collected on the Duke Web Accessibility website. If you’re part of the Duke community, you can also schedule or attend a training session on document accessibility — this is a skill everyone should learn to develop more inclusive working practices. In general, when you’re designing your document in Word, you should:
- Use the styles pane to format your document into clear sections. Learning about headings for accessibility is a translatable skill across software. Using the styles panel in Word will translate your organization to PDF tags in Adobe.
- Think about where you’ll want users of your PDF to be able to type or insert images into the final document. Be sure to denote this space in some way. Our team used the shapes tool to create rectangles an appropriate size to learner answers.
- If you’re using bullets, tables, or features to format content, make sure you’re checking the WCAG guidelines.
- Are you using images? Be sure to not only add alt text, but that you’re writing strong alt text.
- Check your accessibility work multiple times, especially once you’re ready to save as a PDF. You can use the “Check Accessibility” tool in Word’s Review tab.
This list is not all-inclusive; you should review Word documentation on accessibility, preferably multiple times. If you are unfamiliar with this process, it will take you longer the first time.
Once you’ve done a final quality assurance check to verify that you’ve created an accessible document in Word, save it as a PDF. You’ll want to be sure that everything is finalized before moving on to the next step, as you’ll only be able to make edits in Word — not Adobe — to keep your accessibility tags functioning properly.
Checking Accessibility and Adding Interactivity in Adobe Acrobat.
Open your newly created PDF in Adobe Acrobat. Be sure to have the Adobe Acrobat “Create and Verify Accessible PDFs” documentation handy. As a precaution, be sure to check the accessibility of your PDF first. There are a few steps to this process:
- Use the automated check for accessibility tool and review and resolve any flags.
- Manually check the color contrast. Learn more about color contrast. (If you used the Accessibility Review feature in Word, this should have previously been verified.)
- Manually check the accessibility tags and reading order in the Accessibility Tags panel to ensure everything tagged correctly. There may be blank <p> (paragraph) tags you’ll need to remove. (This process uses HTML terminology, but you do not need to know HTML to do this.)
- Be sure to save any changes if you make them in Adobe. There may be times where you’ll need to go back to Word to fix an error before resaving your PDF.
Once you are confident your PDF is accessible, it’s time to add the interactive elements. If you are unfamiliar with this process, we recommend reading Adobe’s documentation on creating forms and watching this short video on how to add form fields. You can use the Prepare a Form tool in Adobe; if you have auto-detection turned on, Adobe will likely find and automatically create form fields, such as text fields, where you made space for them in Word.
Importantly, as you create form fields, you’ll want to learn about adding tooltips — the place where you put descriptions of what a user is using that field for. For example, if you want to collect a user’s full name, the tool tip might be “Write full name.” Learn more about the importance of tooltips. If you are creating an accessible workbook like we did, and you’re asking learners to answer questions, the advice we received from Crawford-Smith was to restate the question in the tooltip.
Once you’ve created, edited, and organized by reading order all form fields tags, you should be ready to do a final accessibility check in Adobe (we did the automated check and re-checked using the accessibility tags). Once everything is verified, you can save your PDF.
Using a Screen Reader
While using an accessibility design process and checking PDFs in Adobe are great steps, if possible, we recommend also verifying the accessibility of your PDFs using a screen reader. If you use a Mac like us, you’ll use the built-in screen reader Voiceover. This video on using Voiceover can help you learn how to use it if you’re a beginner. For Microsoft and other operating systems, there are other screen readers such as JAWs, NVDA, and Orca.
Screen reader testing is a good quality assurance step to help you be more confident that your work will truly be accessible to users who need tags, alt text, etc.
Once you have verified accessibility with a screen reader, you are ready to release your PDF to your users. Remember, that while there are important accessibility best practices we can learn and follow, accessibility is a continual process as we learn more about what helps our users, so it’s possible someone may reach out to you with questions or requests for revisions.
Conclusion
“What if we did things differently?” Asking this question is always a journey. Our team’s RHM project was about upskilling our accessibility knowledge, but we learned a lot about the need to embrace the learning curve as we expanded our instructional design practice. We widened the array of possibilities of how learners would interact with this course series. In doing so, we expanded the possibility of who our learners could be, making this content available to people of all abilities.
Are you interested in learning more about accessibility?:
