Accessible presentations in livestreams: slides as text, not pixels

Why a presentation is only accessible when it sits beside the video — not inside it

A presentation can reach an audience in two ways: inside the video or beside the video. On screen the two look almost the same. For anyone who cannot see well, it is the whole difference.

If the slide sits inside the video, it is a picture. Its type cannot be selected, cannot be enlarged cleanly, cannot be read aloud. A screen reader finds nothing there.

If the slide sits beside it, it is real text. It has its own place, its own size and its own full-screen view. A screen reader reads it out.

At a glance (as of September 2026):

  • The difference: slides burned into the video are out of reach for screen readers, magnification, search and translation. Extracted slides are real text beside the video.
  • What SlideSync does at upload: every page is rendered at 300 dpi and delivered through a responsive image set in six steps up to 1920 px wide. The text is read out of the file — with no text recognition — and placed as structured alternative text in the HTML, right where the slide image sits.
  • What it takes: upload an accessible PDF, not a PPTX. Headings, lists and paragraphs are taken from the PDF’s tag tree — a PowerPoint file does not carry that structure across.
  • The legal position since 28 June 2025: consumer-facing events fall under the German BFSG, internal events under § 164 SGB IX, public-sector events under BGG and BITV 2.0. All three point at the same technical yardstick: WCAG 2.1 AA via EN 301 549.
  • The limit: tables, images and charts from a presentation are currently not carried across as accessible text. Information encoded graphically needs an alternative in the deck — on any platform.
A slide inside the video picture compared with a slide beside the video On the left the presentation runs inside the video window and is only a blurred area of picture there; its text is part of the video frame and cannot be reached by a screen reader. On the right the same video sits next to the presentation, which is shown as its own element with real lines of text that can be read aloud, enlarged and searched. Inside the video One picture. The screen reader finds nothing. Side by side Real text. Read aloud, enlarged, searched. A slide inside the video picture compared with a slide beside the video At the top the presentation runs inside the video window and is only a blurred area of picture there; its text is part of the video frame and cannot be reached by a screen reader. Below, the same video sits next to the presentation, which is shown as its own element with real lines of text that can be read aloud, enlarged and searched. Inside the video One picture. The screen reader finds nothing. Side by side Real text. Read aloud, enlarged, searched.
The graphic follows the same principle: its labels are real text, not an image.

This page shows how that separation comes about, which rules apply in Germany, and where the limits are.

Two ways to get a presentation into a webcast

An accessible presentation in a livestream is a presentation whose content stays perceivable independently of the video picture. That is the whole difference, and it comes down to one question: does the slide’s text exist as text — or only as an image?

Burned into the video signal. The deck is shown on the presenter’s screen, mixed into the picture by the production, and encoded together with it. From then on the slide’s text is image information. It cannot be selected, searched, translated or read aloud. When a viewer magnifies it, they magnify compressed video: the type gets larger and softer at the same time.

Extracted and delivered as its own layer. The deck is uploaded before the event. The platform opens the file and takes it apart: each page into its own image, the text into real text, the structure into web markup. On the viewer’s screen, video and slide sit side by side, each in its own area, each at its own size.

What happens at upload

We describe the path through SlideSync here, because that is the behaviour we can stand behind. Four things happen when a deck is uploaded:

  • Every page becomes an image. The file is rasterised at 300 dpi and stored as a master 3840 px wide. It is delivered through a responsive image set in six steps up to 1920 px — the display picks the step that matches the screen.
  • The text comes from the file, not from the picture. No text recognition takes place. The characters are those of the original document, including umlauts, special characters and figures. A screen reader therefore reads what the document says, not what a recognition engine guessed.
  • The structure survives as far as the source file carries it: headings stay headings, lists stay lists, paragraphs stay paragraphs. The resulting structured text sits in the HTML exactly where the slide image is displayed, which keeps orientation intelligible. Each page also gets a title automatically, taken from its first line of text.
  • Every slide change is logged, with a timestamp. Live, the screen reader announces the change. In the recording, every moment of the talk therefore carries the slide that was on screen at the time — and the sequence can be corrected afterwards.

The recording is held to the same standard as the live transmission: on demand there are no additional restrictions. The text stays text, months later too.

What that changes for the person watching

Slides inside the video pictureSlides as their own layer
Screen readerreads nothing — the text is a picture, there is no way inreads the slide’s structured text in document order; slide changes are announced
Magnificationenlarges compressed video; type goes soft before it gets big enougha separate still image, rendered at 300 dpi and delivered up to 1920 px wide — it scales independently of the video window
Small screensthe slide is stuck inside the video frame and is as large as that frameits own area, its own size, its own full-screen view
Weak connectionlegibility is tied to video bitrate; fine type is what the encoder sacrifices firstimage and text arrive independently of stream quality
Copy, search, translateimpossible — there is no text to selectreal text from the file: selectable, searchable, machine-translatable
Use without a mouseone video player, nothing morethe slide navigation is fully keyboard-operable
After the eventthe content is only recoverable by re-watchingon demand is equally accessible; every slide change is on record with a timestamp
Images, tables, chartsonly reachable through audio descriptioncurrently not carried across as text either — the alternative belongs in the deck

Which rules apply — and to which event?

Which obligation applies depends on who is in the audience and who is inviting them. This is not a fringe group: at the end of 2025, a good 7.8 million people in Germany were living with a severe disability, 9.4 % of the population (source: Federal Statistical Office, 2025). What follows is not legal advice. It sorts the three cases that occur in practice.

External events for consumers, investors, press and the public fall under the German Accessibility Strengthening Act, the national implementation of the European Accessibility Act. Since 28 June 2025, § 3 BFSG has required companies to make digital services for consumers accessible. Digital events, including attendee registration, are covered. An accessibility statement and a feedback mechanism come on top.

Internal events follow a different rule — town hall meetings, works meetings, training sessions. Here § 164 SGB IX applies first. Employers with 20 or more staff must make reasonable accommodations so that employees with severe disabilities can take part on equal terms. Real-time captions and screen-reader-compatible presentations are named explicitly. The General Equal Treatment Act adds a prohibition on discrimination because of a disability, with damages under § 15.

Public-sector events at federal, state and municipal level are governed by the Disability Equality Act and BITV 2.0. Under § 12a BGG, event websites, streaming portals and their apps must meet EN 301 549. § 12b requires a publicly accessible accessibility statement with a feedback mechanism; responses are due within one month.

All three routes end at the same technical yardstick. For the web part, the European standard EN 301 549 refers to the Web Content Accessibility Guidelines at version 2.1, Level AA. The next revision of the standard is expected to adopt the WCAG 2.2 criteria.

Where do burned-in slides run into trouble?

You do not need the guidelines by heart to follow the logic. Four criteria land exactly on the decision of whether a slide is text or picture:

  • Non-text content needs a text alternative (WCAG 1.1.1). A slide inside a running video frame cannot have one — there is no element to attach it to.
  • Text should be real text, not a picture of text (WCAG 1.4.5, Level AA). A video frame is the strongest possible version of a picture of text.
  • Text must survive 200 % enlargement and reflow (WCAG 1.4.4 and 1.4.10). Burned-in type does not survive it; it just gets blurrier.
  • Visual information that is not in the spoken audio needs audio description (WCAG 1.2.3, and 1.2.5 at Level AA for recordings). This is the expensive consequence: if a figure exists only as a picture, the only compliant route left is to narrate it — for every recording, in every language.

This is where the money is. For body text, headings and lists that effort disappears once the slides exist as text: nobody has to describe what is already readable. For charts and tables it does not — see below.

Where the limits are

No tool makes an event compliant. Conformance depends on your whole process: registration, captions, the invitation, and the accessibility statement that BFSG and BITV 2.0 require in German with a feedback channel. A platform can make the accessible path the default one rather than an expensive retrofit. Nothing more.

Extraction is only as good as the source file. What gets read is what the document contains. A deck built from real text boxes with proper headings comes out structured. A slide that is only a screenshot has no text layer. It yields empty text and an empty title. Because no text recognition is performed by design, there is no fallback for that. Such slides need a description, on any platform.

Two limits we name explicitly. Tables, images and charts from a presentation are currently not carried across as accessible text. Anyone who puts their key message in a bar chart has to spell it out as well: as alternative text in the deck, as an accompanying table, or in the talk. And it is not 4K. Rendering is at 300 dpi, delivery goes up to 1920 px wide. That is considerably more than a slide inside compressed video, but it is not a 4K still.

How do I prepare a deck that comes through cleanly?

Accessible webcasts start in the deck, not in the control room. Three steps, and the third is the one most often missed:

  1. Check. PowerPoint ships its own checker under Review → Check Accessibility. It finds the basic cases: missing alternative texts, unreadable contrast, content without structure.
  2. Structure. Real title placeholders instead of free-floating text boxes, real lists instead of manual bullets, alternative text on images and charts. That markup is what gets read later.
  3. Export as an accessible PDF — and upload that PDF. This is not a recommendation but a prerequisite: headings, lists and paragraphs are read from the PDF’s tag tree. Upload the PowerPoint file instead and you get text, but no structure.

In practice this means the deck has to be finished before the event, not in the control room. A step-by-step guide with screenshots is in the SlideSync knowledge base.

Audited, not asserted: the BITV audit with blista

Accessibility can be asserted or audited. We had it audited. blista — the German Federal Institute for the Blind in Marburg, the nationwide competence centre for people with blindness and visual impairment — has conducted a comprehensive BITV audit of SlideSync against WCAG 2.2 and EN 301 549 criteria, initially without formal certification. On the basis of that audit report we are removing the barriers it identified.

The BITV test is the German audit procedure for this: roughly 60 to 100 defined test steps, derived from the Accessible Information Technology Ordinance, which in turn implements EN 301 549 for Germany. An external audit says nothing about whether your event is accessible. It says something about how solid the ground is on which you plan it.

Frequently asked questions

Are slides delivered as separate content, or are they inside the video picture?

This is the first question to ask any webcast provider, because every other one depends on it. If the slides are inside the video picture, they are equally out of reach for screen readers, magnification, search and translation. In SlideSync they are uploaded before the event and delivered as their own layer beside the video.

Can a screen reader read the text of a slide?

Yes. The text is read out of the uploaded file and placed as structured alternative text in the HTML, right where the slide image appears. Slide changes are announced as well. This requires a source file with a real text layer — a slide that is only a screenshot yields no text.

Can a viewer enlarge a single slide without it turning blurry?

The slide is a separate still image, rendered at 300 dpi and delivered in six steps up to 1920 px wide. It scales independently of the video window and can be shown large in its own area. It is not a 4K still — but for the legibility of fine type, the difference against a compressed video frame is considerable.

Is slide text still searchable after the event?

Yes. The extracted text stays real text, so it remains selectable, searchable and machine-translatable. On demand is held to the same conditions as live; on top of that, every slide change is on record with a timestamp, so the recording shows the state that matches the talk.

Who pays for the audio description if slides exist only in the video?

The organiser. If information exists solely as a picture, the only compliant route left is to describe it — under WCAG 1.2.3 live and under 1.2.5 for the recording as well, per language. When the slides exist as text, that effort disappears for body text, headings and lists. For charts and tables it remains, because their content is currently not carried across as text.

Accessibility in a livestream does not end at the slides: live captions, live translation and sign-language interpreters belong to the same subject. Our page on accessible livestreams gives an overview of all the building blocks. If you have a specific event coming up — a virtual AGM, a town hall, a press conference — we are glad to look at your deck beforehand.

Try SlideSync!

Let’s talk about your event!

© 2026   All rights reserved