This post outlines how organizers can quickly put together a virtual conference that offloads responsibility for individual sessions to the presenters (with guidelines and support for accessibility), and allows for fallback to less data intensive platforms if bandwidth does not support video in the moment.
A future post will provide recommendations for which of the many services have the best accessibility features and support.
Organizer provides presenters with a link to a Google doc (or other collaborative word processing file or web page builder). This document may have placeholders and outlines for presentation order, subheadings, etc. Or some other rule for presenters to follow when entering their data.
In their designated area of the document, Presenters provide:
- presentation title,
- author names,
- contact info,
- ACCESSIBLE paper draft, presentation slides, or poster files,
- link to video conference (zoom, meet, Skype) or text chat room (slack, discord, signal), Twitter handles and hash tags, etc.
Organizers designate which presenters are meant to be online in their meeting spaces at which times (specified in above document).
Organizers announce the beginning and end of timed sessions on social media and/or via email blast, and may host “plenary” or “keynote” sessions via chosen platform.
Presenters may provide recordings of their sessions for an event archive.
- Can (and should) provide accurate captions and/or transcript
- Easy to archive
- Artifact for personal website Can be used for content sharing among teaching peers
- May require learning new tools
- Takes prep time
- Q&A handled separately
There are many differences between various video call platforms that will influence which one is most suitable for you. The purpose of this post is not to cover the various features of each.
I will say that Google Meet’s real time captions are decent, such that Deaf and Hard of Hearing friends of mine prefer these autocaptions over other autocaptioning such as Skype’s. Zoom has support for integrating CART services, which is superior to autocaptioning. But these services are separate. It is your duty as an organizer to provide accessible virtual events, even if you do not know which of your participants need access services.
I would also like to encourage everyone to get I to the habit of paying attention to the chat windows that most video conferencing services provide. This is a place where people with various access needs may turn to communicate if they are having difficulty participating other ways. It is also a place where people with poor connections can participate.
Zoom has a “raise hand” feature. If you are using a service that doesn’t, the chat window can be a place to indicate that you have something to say if you are having trouble interjection verbally.
It is good practice to assign a moderator whose job it is to monitor the chat and announce content that appears there. This helps support multimodal communication across participants.
- Presentation style is similar to in person
- Can share desktop to show participants what you are talking about
- Requires good connection
- Experience will be different based on connection quality
- Timezones may make participation difficult
This method can be good for Q&A of prerecorded presentations, as a fallback if bandwidth for video conferencing is failing, and as a space to continue conversations after the event is over.
Services like Slack and Discord have become popular, and do have nice features for organization into “channels” which would make good spaces for special interest groups, strands, and individual sessions to meet. However, accessibility of these services is inconsistent.
Facebook groups, Twitter hash tags and threads, and group texts via signal, what’s app, or group me, may be better options to ensure access for people who use screen readers.
“old fashioned” message boards may be the best option. Google groups allows for the quick creation of a message board with subgroups, but it is not easy to view on mobile. There are many apps for forum integration on mobile, but many tend to be android or iOS only, and not both.
- Low data requirements
- Fragmented (there are so many options)
- Inconsistent accessibility (fancier usually means less compatible with screen readers)
I will keep this space updated with other guides and resources.