Accessible Faculty Development Programming
Those who work in faculty development, educational development, academic development, and instructional design support in higher education are always looking for ways to have more instructors, adjuncts, and graduate teaching assistants attend programming. We are also always reflecting and collecting data on what programming these groups need to support their pedagogy. Usually, reflections on low attendance for programming suggest maybe it was the wrong topic, or maybe it was at the wrong time, or maybe everyone is just too tired to benefit from this kind of programming right now. For this third post in the series, I will suggest that accessibility is a main framework that should be taken into consideration when planning faculty development programming. In fact, accessibility barriers may be leading to low attendance rates. I will provide four accessibility considerations to take into account as you finalize your winter or summer programming offerings.
Have the program modality reflect the program content and topic Not every topic is well suited to an online webinar, just like not every topic is well suited to an in-person workshop. Reflect on the outcomes you would like for the particular programming, and see what modality would best suit this outcome and be the most inclusive to your participants. This decision will also be dependent on demographics and how many participants you expect to attend. If you have the capacity, you can also offer the same programming in multiple modalities or as hybrid delivery to support as many participants as possible.
Provide programming resources and supports that meet participants where they are All programming usually has some sort of resource. Accessible programming provides these resources ahead of time or at the start of the workshop or webinar. Having the slide deck or the handout at the beginning of the programming will allow participants to annotate, to reflect, and to read ahead to see what to expect. All of these things can help participants in an inclusive way. Here are other aspects that accessible programming includes to meet participants where they are:
Provide captions for webinars or recorded content.
Provide an outline with time estimates so participants will know how long to expect for each section of the workshop or webinar.
Describe any visuals or graphs that you have on a slide. This helps those who may be blind or low vision, but this also helps some participants process the information.
If the programming is in-person, please use a microphone (yes, I know you think you know how to project your voice, but please do use the microphone!)
If the programming is in-person, audit the space to make sure it is accessible for wheelchairs and other supports (Is there elevator access to the room? Is there a ramp to the podium if someone is giving a keynote?).
Listen to needs and wants using a ground-up approach Those who work in faculty development know that our work is often one of balancing competing priorities. In order to make your programming more accessible, listen to the folks who you hope will take part in the programming. A ground-up approach to program delivery is one that will necessarily be more accessible than a top-down approach. If your programming is not being well received by participants, reflect on who is informing programming decisions and see if you are meeting the participants where they are.
Promote tools that are accessible Finally, if your programming supports Ed Tech or instructional tools, make sure that the Ed Tech or tool that your programming is supporting has been vetted for accessibility. Modelling is important. You would not want to advise instructors to use a tool that is actually only accessible to a certain demographic of student. Look for a VPAT (voluntary product accessibility template) and see how the tool meets, or doesn’t meet, WCAG 2.1 success criteria. Remember that WCAG criteria doesn’t always ensure access for all; it is only a place to start the conversation. If you don’t have the expertise to read a VPAT, reach out to your technology supports on campus. I am sure they would be happy to help, because ultimately it will mean less support tickets for them in the long run when students and instructors realize a tool won’t work for their use case.
As a bonus tip, I would suggest reaching out to the community on Twitter to help support more accessible programming. Twitter is a great space for educators who care about access, much more than you will find at conferences or professional organizations, because the financial cost and barrier to participate on Twitter is relatively low. There are of course technological and other socio-cultural barriers that can prevent Twitter from being a truly inclusive space. However, those who are on Twitter are happy to provide accessibility tips and resources. Following hashtags such at #a11y or #UDL or #DisInHigherEd can provide both insight about both pedagogical and structural considerations for your programming, as well as links to resources and tools to help make your programming more inclusive. You can share your approaches to making your faculty programming more accessible as well--it will ultimately make the community and classrooms more inclusive.
In this series, Ann Gagne offers practical advice for how to best support faculty in making their course materials and pedagogy accessible to learners.
Ann Gagné is an Educational Developer with a focus on Universal Design for Learning at the University of Toronto-Mississauga and a sessional instructor at George Brown College. She is passionate about inclusive and ethical pedagogical strategies and works with instructors to ensure pedagogical and curricular accessibility.