Live Captions for University Lectures 2026: Multilingual Setup

Universities have two specific live-caption needs that most off-the-shelf meeting transcription tools don't address well: accessibility for deaf and hard-of-hearing students (often a legal requirement, not a nice-to-have), and language access for international student cohorts where the lecturer speaks one language and the audience reads in several.

The lecture-capture systems that universities already run — Panopto, Echo360, Zoom for Education, Microsoft Stream — solve part of the problem: they auto-caption the recording for the post-lecture replay. What they don't solve well is real-time multilingual display during the lecture, where a Mandarin-speaking student in the back row reads captions on their phone in simplified Chinese while the English-speaking accessibility student reads English captions on theirs, and the deaf student gets a real-time transcript with proper line breaks.

This guide covers what universities actually need from a live-caption tool, how the setup works on lecture-day, and where each of the realistic options fits — including Subanana (which I run), Wordly, and the lecture-platform-native captioning that's already in your stack.

What universities actually need

Three requirements come up consistently across the universities I've talked to:

Real-time captions visible to attendees during the lecture, in multiple languages simultaneously. Not just for the recording. Students who need captions for accessibility or language reasons need them while the lecture is happening, not 24 hours later.
Audio source flexibility. Some lectures are in person with a lapel mic and a PA system. Some are hybrid (lecturer in person, remote students on Zoom). Some are pure online. The captioning tool has to take audio input from whichever source the lecture is actually using.
No "install our app" friction for students. Asking 200 undergraduates to install a Wordly app or sign into a SaaS account before each lecture is a non-starter. Browser-based caption display via a link or QR code is the only realistic distribution model for a large class.

Add-ons that depend on the university:

Accessibility compliance (Section 508 in the US, EAA in the EU, BS 8878 in the UK) for deaf and hard-of-hearing students.
Integration with existing lecture-capture (Panopto, Echo360) so the live-caption track also lands in the recording.
Multi-language support sized to actual student body — a small lecture might need 1 target language, a large international programme might need 4.
Glossary support for course-specific terminology (lecturer's specialist vocabulary, named entities, technical abbreviations).

Setup shapes that work in practice

There are three setup shapes that come up most often. The right one depends on lecture format (in person / hybrid / online), AV equipment, and IT support availability.

Shape 1: In-person lecture, lapel mic, real-time browser captions

Used when the lecturer is physically in the lecture hall, uses a lapel or handheld mic, and the audience is in the room.

Audio input. Route the mic feed into a laptop running the captioning tool — easiest path is a USB audio interface that taps the AV system's auxiliary output. If the lecture hall AV doesn't have a clean aux out, a backup option is a second lapel mic worn alongside the primary, with its own USB receiver.
Captioning tool runs on the laptop. For Subanana specifically, the laptop opens the live-session view in a browser, the host (typically the AV team) selects the source language and the target translation languages before the lecture, and starts the session.
Audience access. A QR code displayed on the projector (or pre-published in the course LMS) opens the audience caption view in students' phone browsers. Each student picks source / translated / both display.
Post-lecture artefact. Subanana exports the session as SRT after the lecture ends — the AV team can attach the SRT to the Panopto / Echo360 recording for permanent accessibility coverage.

Shape 2: Hybrid lecture, Zoom or Teams for the remote portion

Used when the lecturer is in person but some students join remotely via Zoom / Teams / Meet.

Audio input. The same mic feed that goes into the platform (Zoom / Teams) also feeds the captioning tool. Easiest path: route the laptop's system audio into the captioning tool via a virtual audio cable (BlackHole on Mac, VB-Cable on Windows). The captioning tool listens to whatever the Zoom call is hearing.
Captioning tool runs on a second device. Best practice is a dedicated laptop for captioning so the lecturer's Zoom session isn't competing for system resources.
Audience access. In-room students scan the QR code; remote students get the audience caption link via the Zoom chat or the course LMS.
Post-lecture artefact. Same as Shape 1 — SRT export attached to the lecture recording.

Shape 3: Fully online lecture, browser-only

Used when both lecturer and audience are remote.

Audio input. The lecturer's mic feed goes into both their lecture platform (Zoom / Teams / Meet) and the captioning tool. If the lecturer is doing everything on one machine, virtual audio cable routes the Zoom output back into the captioning tool.
Audience access. Caption link distributed via the course LMS and the Zoom chat. No QR code needed because everyone's already on a screen.
Post-lecture artefact. SRT export attached to the recording.

Tool options compared (documentation-based)

Three realistic options for universities, with different trade-offs:

Option A: Lecture-platform-native captions (Panopto, Echo360, Zoom Live Transcription)

Strength: zero new vendor relationship; already in your stack; auto-attaches to the lecture recording.

Weakness: typically single-language only (English first, with selective support for major languages — Cantonese, Mandarin, and many less-resourced languages either aren't supported or produce captions that need heavy correction). Audience can't pick a target language — what the platform produces is what everyone sees. For multilingual student bodies, this is usually the deal-breaker.

When this fits: English-only lectures with English-only audiences who need accessibility captions, not language translation.

Option B: Wordly

Strength: enterprise-grade live translation built specifically for events; 3,000+ language pairs; deep integrations with Zoom, Teams, Meet, WebEx; managed-service onboarding and live event support; MP3 voice dubbing as an add-on for translated audio output; SSO + configurable data storage at the Enterprise tier.

Weakness: pricing is hour-package + attendee-based with annual 12-month terms, gated to "Contact Sales for a Quote" above small packages. For a university running 50+ lectures per term across multiple departments, you're either committing to a large annual hour package or negotiating an enterprise contract. Smaller-scale validation ("can we trial this on one course before rolling out university-wide?") is harder.

When this fits: large research universities with central AV / accessibility teams, dedicated procurement budgets for enterprise tooling, and event volume that justifies the annual commitment. → Deep dive: Subanana vs Wordly (2026).

Option C: Subanana

Strength: published per-month subscription pricing (no annual hour package); free tier for single-lecture validation; host configures source + target languages per session so departments can self-serve without central procurement; browser audience captions with no app install; per-language STT routing covering Cantonese, Mandarin, and English among 80+ supported languages.

Weakness: no per-platform deep integration with Zoom / Teams / WebEx for the live-caption shape (workflow is audio-input-based via mic or virtual cable); no MP3 voice dubbing of translated text (text captions only); no enterprise SSO or configurable data residency in the published feature set today; smaller language pair breadth than Wordly's 3,000+. Live-session export is SRT-only; if you want DOCX / XLSX / Markdown of the transcript, you'd re-process the recording afterwards via Subanana's file-upload transcription.

When this fits: universities or individual departments running smaller-volume lectures, validating live-caption fit before committing, or specifically needing Cantonese / Mandarin / mixed-language coverage. Departments that can't get budget approval for an annual enterprise contract can self-fund a workspace subscription.

→ Product: Subanana — multilingual live captioning.

Practical workflow: setting up Subanana for a recurring lecture

For a department running a recurring lecture series in one language with students who need captions in 2-3 others, here's the practical workflow:

One-time setup (~30 minutes before first lecture). AV team sets up the audio routing into the captioning laptop (USB interface from AV aux out, or virtual audio cable). Department admin creates a Subanana workspace and pre-configures the source language + target languages.
Pre-lecture (~5 minutes). AV team opens the live session, confirms audio level, generates the QR code, prints it on the lecture slide or projects it on a screen at the start of the class. Pre-publishes the audience caption link in the LMS for remote / late-arriving students.
During lecture. The captioning runs in the background — the lecturer doesn't interact with it. Students who want captions scan the QR or open the LMS link.
Post-lecture. AV team exports the SRT, uploads it to the lecture-capture system (Panopto / Echo360) so the SRT is attached to the recording for permanent accessibility coverage.
Across the term. The configured source + target languages persist — no re-setup per session. If the lecture content changes language mid-term (a guest lecturer in Mandarin during a primarily-English course), the host reconfigures source language on the live-session view before that lecture and switches back afterwards.

Frequently asked questions

Does Subanana integrate with university lecture-capture systems?

Not as a per-platform deep integration — Subanana's live captioning takes audio input from the host's mic, system audio, or a virtual cable. The post-lecture SRT export can be uploaded to Panopto / Echo360 as a caption track for the recorded video, which is the practical integration shape for most universities.

Can Subanana handle accessibility compliance (Section 508, EAA)?

Compliance is determined by what your university's accessibility office requires you to provide for deaf and hard-of-hearing students — typically a real-time caption track during the lecture plus a corrected caption track on the recording. Subanana produces both (live captions during, SRT after); whether that meets your specific compliance framework depends on your university's policy. Subanana doesn't publish formal Section 508 or EAA conformance documentation today, so confirm fit with your accessibility office before relying on it for compliance-critical contexts.

How does language selection work for attendees?

In Subanana's audience caption view, attendees choose to display source / translated / both side-by-side — picking among the languages the host pre-configured for the event. They can't add a language that wasn't pre-configured. If your lecture audience needs a language the host didn't configure, that student would need to use one of the available languages (or the host can reconfigure if the change is anticipated in advance).

What audio quality do you need for good live captions?

A clean lapel mic feed (close to the lecturer's mouth, away from PA speakers) is the single biggest factor in caption accuracy. Room mics on the ceiling typically produce noticeably worse captions because of room reverb and HVAC noise pickup. If captions matter, prioritise lapel or handheld mic setup over relying on the lecture hall's room-mic array.

Can students download the captions for revision?

The post-lecture SRT is exportable by the host. Universities typically attach it to the lecture recording in Panopto / Echo360 — students access it as the recording's caption track, which is searchable for revision purposes. Distributing the raw SRT to students directly is also possible if the lecturer wants to.

How does Subanana's pricing scale for a whole department or university?

Subanana's published pricing is workspace-based — a department-level workspace covers the lecturers running sessions from it. For university-wide rollout, the workspace structure plus volume discussion is the normal path. Per-session hour-package pricing (like Wordly's model) isn't what Subanana sells; if your procurement specifically needs that pricing shape, Wordly is purpose-built for it.

Live Captions for University Lectures (2026): Multilingual Setup & Tool Comparison