Afbeeldingsbeschrijving: Een vergaderzaal met een geprojecteerde dia en een laptop waarop de leesvolgordestructuur van de presentatie te zien is — het visuele kenmerk van toegankelijke presentatieproductie.
Leestijd: 12 minuten
Diavoorstellingen blijven het meest gedeelde educatieve artefact in het moderne professionele leven — collegeaantekeningen, bestuursberichten, trainingsmodules, conferentielezingen, interne bedrijfspresentaties. Ze zijn ook, zonder uitzondering, het minst toegankelijke artefact in dezelfde pijplijn. Een lezing die schermlezers niet kunnen navigeren, een presentatie waarvan de grafiekwaarden alleen als pixels bestaan, een videoclip zonder ondertiteling, een “klik om door te gaan”-interactie die het toetsenbord negeert: elk van deze is gangbaar, en elk sluit stilzwijgend dezelfde groep mensen uit van dezelfde inhoud die de rest van het publiek ontvangt. Het goede nieuws is dat dit in 2026 geen onderzoeksprobleem meer is. Het is een productie-workflowprobleem met drie goede antwoorden en één beslisboom die ertussen kiest.
Deze primer behandelt de drie families van tools die een werkende presentator daadwerkelijk op zijn bureau heeft — Microsoft PowerPoint, Apple Keynote en Google Slides — plus het steeds serieuzer wordende web-first alternatief (Reveal.js, Slidev, Marp) dat docenten en conferentieorganisatoren zijn gaan verkiezen. Het is geen abstracte vergelijking van functies. Het is een productiegids: welke stappen men neemt, in welke volgorde, in welke tool, om een presentatie te leveren die een blinde student kan volgen met NVDA, een slechtziende collega op 400% zoom kan lezen, een dove deelnemer kan meelezen met ingebedde ondertiteling, en een toetsenbordgebruiker kan navigeren zonder ooit een muis aan te raken. Voor de bredere standaardencontext, zie de primer over WCAG 2.2-adoptie en de Europese Toegankelijkheidsakte, die nu beide van toepassing zijn op educatieve en commerciële diainhoud die online wordt verspreid.
Wat een toegankelijke presentatie nodig heeft
Voordat de tool-specifieke workflows aan bod komen, een basislijn. Een toegankelijke diavoorstelling heeft zes dingen die tegelijk werken, en geen van hen is optioneel. Het eerste is een unieke, beschrijvende titel op elke dia — dit is wat een schermlezersgebruiker gebruikt om van dia naar dia te navigeren, en waar een gebruiker van het overzichtspaneel op vertrouwt om de gewenste dia te vinden. Dia’s getiteld “Dia 4” of “Naamloos” zijn niet navigeerbaar. Het tweede is een correcte leesvolgorde. Dia’s die zijn opgebouwd door vormen op een canvas te slepen zonder de placeholders te gebruiken, zullen een leesvolgorde hebben die overeenkomt met de volgorde waarin vormen zijn ingevoegd, niet de visuele volgorde — wat betekent dat een schermlezer een dia achterstevoren kan lezen, zijbalk eerst, voettekst vóór koptekst, of in welke volgorde het productieproces toevallig heeft geproduceerd. Het derde zijn tekstalternatieven voor elke niet-decoratieve afbeelding, grafiek en diagram, geschreven in taal die de boodschap van de afbeelding overbrengt, niet alleen de oppervlaktebeschrijving.
Het vierde is voldoende kleurcontrast — tekst op diaachtergronden op de WCAG 2.2 AA-drempel (4,5:1 voor bodytekst, 3:1 voor grote tekst en betekenisvolle graphics), gecontroleerd op de werkelijke achtergrondpixels en niet op het dia-master. Het vijfde is toetsenbordnavigeerbaarheid — elk interactief element dat een presentator verwacht dat een publiek later zal gebruiken (ingesloten poll-links, vertakkende navigatie, ingesloten formulieren) moet bereikbaar en bedienbaar zijn met Tab, Enter, Spatie en Esc alleen. En het zesde is mediabeheer — elk ingesloten video bevat ofwel open ondertiteling ingebrand in het bestand of een gesloten ondertiteltrack die de speler kan inschakelen; elke ingesloten audioclip heeft een transcript dat bereikbaar is vanaf dezelfde dia; elke animatie die niet strikt noodzakelijk is, respecteert de reduced-motion-voorkeur van de gebruiker op OS-niveau.
Elk van de drie desktoptools levert een subset van deze zes. Geen van hen levert alle zes automatisch. De juiste tool kiezen betekent begrijpen wat men handmatig moet doen in elk.
PowerPoint-workflow
PowerPoint heeft de meest volwassen toegankelijkheids-tooling van alle presentatie-apps op de markt, en dat is zo geweest since de Microsoft 365-releasecyclus de Toegankelijkheidscontrole in het lint begon op te nemen. Het startpunt is de controle zelf, geopend via het tabblad Controleren in Windows of het menu Extra op macOS. Het geeft een live, contextuele lijst van problemen — dia’s zonder titels, afbeeldingen zonder alternatieve tekst, combinaties met laag contrast, tabellen zonder koppen, hyperlinks waarvan de zichtbare tekst de URL dupliceert — en klikken op een probleem springt de cursor naar het overtredende element. De controle wordt standaard bij elke opslaan uitgevoerd in huidige versies, wat de nuttigste standaardinstelling is die Microsoft in dit product heeft geleverd. Schakel het alleen uit nadat men begrijpt welke waarschuwingen men bewust negeert.
Diatitels worden beheerd via de Overzichtsweergave (Weergave, Overzicht) en via de Titel-placeholder van het dia-master. Het gebruik van de placeholder in plaats van een vrij zwevend tekstvak is wat de titel zijn semantische rol geeft — zowel de Toegankelijkheidscontrole als downstream schermlezers identificeren getitelde dia’s via de identiteit van de placeholder, niet via de zichtbare tekst. Als de titels van de presentatie zijn gezet met vrij zwevende tekstvakken om ontwerpredenen, kan men het ontwerp behouden maar een onzichtbare placeholder-titel toevoegen door de placeholder buiten het canvas te verplaatsen (Selectiedeelvenster, positie op negatieve coördinaten zetten) — de titel bestaat nog steeds in de toegankelijkheidsstructuur en telt voor schermlezersnavigatie, ook al ziet het publiek hem nooit. De Microsoft-documentatie beschrijft dit als het “off-slide title”-patroon; de controle accepteert het.
Leesvolgorde is de tweede pijler. Open het Selectiedeelvenster (Start, Rangschikken, Selectiedeelvenster in Windows; menu Rangschikken op macOS) en lees de lijst met vormen van onder naar boven — dat is de volgorde waarin een schermlezer ze zal tegenkomen. Sleep vormen binnen het deelvenster om te herordenen. PowerPoint 2024 heeft een toegewijd leesvolgordedeelvenster toegevoegd dat de volgorde numeriek visualiseert over elke vorm op de dia en herordenen via slepen-en-neerzetten direct op het canvas mogelijk maakt; als de Microsoft 365-versie recent genoeg is om dat deelvenster te tonen, gebruik dat dan.
Alternatieve tekst voor afbeeldingen wordt ingesteld door met de rechtermuisknop op de afbeelding te klikken, Alternatieve tekst bewerken te kiezen en één tot twee zinnen redactionele alt te schrijven — de boodschap van de afbeelding, niet de pixelinhoud. De automatisch gegenereerde alternatieve tekst van PowerPoint is opt-in en als zodanig gelabeld in het deelvenster; het is een startpunt, geen afgewerkt product, en de controle zal waarschuwen als een dia wordt geleverd waarbij de enige alternatieve tekst “Beschrijving automatisch gegenereerd” is. Voor grafieken gebouwd in PowerPoint moet de alternatieve tekst het argument van de grafiek in één zin samenvatten en de twee of drie belangrijkste waarden noemen — “Staafdiagram dat aantoont dat de conferentiedeelname in 2026 met 18% is gestegen ten opzichte van 2025, aangestuurd door EMEA en APAC” is beter dan “Staafdiagram.” Voor gegevensintensieve dia’s, lever de onderliggende gegevens als een verborgen maar bereikbare tabel in de sprekersaantekeningen, of als een gelinkt spreadsheet in de bijlage, zodat een schermlezersgebruiker ook de getallen kan lezen naast de strekking van de grafiek.
Ingesloten video is de meest voorkomende nalevingsfout in PowerPoint-presentaties. De workflow Invoegen, Video, Ondertitels invoegen accepteert WebVTT-bestanden (.vtt) en koppelt ze aan de ingesloten clip; eenmaal bijgevoegd, worden de ondertitels weergegeven in de ingebouwde speler van PowerPoint en reizen mee met het bestand wanneer de presentatie wordt gedeeld, gemaild of geüpload. Als de bronvideo ingebrandde open ondertiteling heeft, markeert de controle het bestand nog steeds als een ondertiteltrack nodig hebbend — voeg toch een minimale VTT toe, want het bestand is wat downstream tooling zal lezen. Hyperlinks moeten zichtbare tekst hebben die de bestemming beschrijft (“Lees het EAA-handhavingsrapport 2026”), niet de kale URL.
De exportpijplijn van PowerPoint behoudt het grootste deel van de toegankelijkheidsmetadata bij export naar PDF — mits Bestand, Exporteren, PDF/XPS maken (Windows) of Bestand, Opslaan als, PDF met de optie Beste voor elektronische distributie en toegankelijkheid geselecteerd (macOS) wordt gebruikt. Exporteren via Afdrukken naar PDF verwijdert de tags en produceert een ontoegankelijke platte PDF; dit is de meest voorkomende stille fout in de gehele workflow.
Keynote-workflow
Keynote wordt geleverd met aanzienlijk minder toegankelijkheids-tooling dan PowerPoint, en die kloof is niet wezenlijk gesloten since de 13.x-releasecyclus. Er is geen equivalent van de Toegankelijkheidscontrole — Keynote voert geen dia-voor-dia-audit uit, geeft geen leesvolgordedeelvenster per dia, en waarschuwt de gebruiker niet wanneer een dia geen titel heeft. De dia’s zelf hebben een sterkere VoiceOver-integratie dan PowerPoint een decennium geleden had, maar de productie-workflow voor het produceren van een toegankelijke presentatie uit Keynote is op elke stap handmatiger.
Diatitels worden toegevoegd via de Titel-placeholder in het dia-master of als een regulier tekstvak dat consistent door de presentatie heen wordt gebruikt. De overzichtsweergave van Keynote (Weergave, Overzicht) leest vanuit de Titel-placeholder, dus presentaties opbouwen op basis van het master in plaats van vanuit lege dia’s is het grootste hefboompunt. Leesvolgorde wordt beheerd via de Rangschikken-inspector — de Achtergrond/Voorgrond-besturingselementen in het stapelmodel van Keynote verdubbelen als de leesvolgordebesturingselementen, waarbij verder naar achteren geplaatste vormen als eerste worden gelezen. Er is geen toegewijd leesvolgordedeelvenster; men moet een mentaal model van de stapel bijhouden, of complexe dia’s opbouwen vanuit een bekende correcte basis.
Afbeeldingsalternatieve tekst in Keynote wordt ingesteld via het veld Beschrijving in het tabblad Afbeelding van de Opmaak-inspector — schrijf dezelfde redactionele alt als in PowerPoint. Grafieksalternatieve tekst gebruikt hetzelfde mechanisme. Keynote waarschuwt niet voor ontbrekende alternatieve tekst. De enige manier om de alt-tekstdekking van een presentatie in Keynote te verifiëren, is elke dia handmatig te doorlopen, of te exporteren naar PowerPoint-formaat (.pptx) en de Toegankelijkheidscontrole van Microsoft op de export uit te voeren — een workflow die verschillende grote universiteiten hebben overgenomen als hun poortwachtersstap voor collegepresentaties gebouwd in Keynote.
Ingesloten video in Keynote ondersteunt geen afzonderlijke ondertiteltrack. Als de bronvideo geen ingebrandde open ondertiteling bevat, moet men de video opnieuw coderen met ondertiteling ingebrand voordat deze in Keynote wordt ingevoegd, of de insluiting vervangen door een verwijzing naar een ondertitelde video gehost op een ondertitelingsbewust platform (YouTube, Vimeo, de mediaserver van de instelling). Keynote zal stilzwijgend niet-ondertitelde video opnemen in een geëxporteerde PDF; de controle die niet bestaat, kan daarvoor niet waarschuwen.
Waar Keynote zijn plaats verdient, is bij ontwerpintensieve presentaties voor keynote-lezingen eerder dan voor distributie. De typografie, opmaak- en animatiekwaliteit zijn nog steeds de beste in de desktoppresentatiemarkt — wanneer de presentatie in wezen een rekwisiet is voor het podium en de inhoud in een apart verspreid paper, transcript of webpagina leeft, produceert Keynote een sterkere live-ervaring en verschuift de toegankelijkheidsverantwoordelijkheid naar het begeleidende document. Als de presentatie zelf het te leveren artefact is, is PowerPoint de betere keuze.
Google Slides-workflow
Google Slides is aanzienlijk verbeterd since de toegankelijkheidsopfrisbeurt van 2024, waarbij een toegankelijkheidsmenu per dia werd toegevoegd, suggesties voor alternatieve tekst aangedreven door Gemini-klasse afbeeldingsmodellen, en een contrastcontrolelayer bereikbaar via Extra, Toegankelijkheid. De opfrisbeurt van 2024 voegde ook leesvolgordebesturingselementen toe aan het menu Rangschikken — voor het eerst in de productgeschiedenis kunnen Slides-auteurs een expliciete leesvolgorde instellen in plaats van te vertrouwen op de volgorde van vormcreatie. De adoptie van deze functies binnen grote enterprise-tenants is sneller verlopen dan Microsoft aanvankelijk verwachtte, mede omdat Slides-presentaties al overwegend in de cloud worden gehost en onmiddellijk profiteren van de server-side controle.
De mechanismen zijn vertrouwd voor iemand die komt van PowerPoint. Titels worden beheerd via de Titel-placeholder van de masterindeling. Alternatieve tekst wordt ingesteld via Opmaakopties, Alternatieve tekst, met dezelfde redactionele regel van één tot twee zinnen. Leesvolgorde gebruikt het menu Rangschikken, Volgorde, met het nieuwe leesvolgordedeelvenster van 2024 zichtbaar via Extra, Toegankelijkheid, Leesvolgorde. Video-insluiting vanuit Google Drive of YouTube respecteert welke ondertiteltrack de bron ook heeft, en een dia met een niet-ondertitelde video geeft een waarschuwing in het toegankelijkheidsdeelvenster.
Waar Slides nog achterblijft op PowerPoint is in grafiekaccessibiliteit (de automatisch gegenereerde grafieksalternatieve tekst is korter en minder contextbewust), in complexe master-overerving (diep aangepaste masterindelingen produceren moeilijker te debuggen leesvolgordbomen), en in offline workflows (de toegankelijkheidscontrole vereist dat het document online is, wat een probleem is voor gebruikers die in vliegtuigen of beperkte omgevingen werken). Voor een onderneming in 2026 die op Workspace is gestandaardiseerd en presentaties primair als gedeelde Google Slides-links levert in plaats van als gedownloade bestanden, is de Slides-workflow nu wezenlijk vergelijkbaar met PowerPoint. Voor een organisatie die presentaties levert als .pptx-bijlagen of als geëxporteerde PDF’s, heeft PowerPoint nog steeds de voorsprong.
Web-first presentaties: Reveal.js, Slidev, Marp
De meest interessante ontwikkeling in presentatietoegankelijkheid in 2025 en 2026 heeft plaatsgevonden buiten de drie grote desktopapps. Een cluster van web-first presentatieframeworks — Reveal.js (het langbestaande JavaScript-framework), Slidev (een op Vue gebaseerd tool gericht op ontwikkelaars), en Marp (een Markdown-first generator die compileert naar HTML, PDF of PPTX) — produceert diavoorstellingen als HTML-documenten, wat betekent dat de toegankelijkheidseigenschappen van HTML worden geërfd in plaats van nagebootst. De semantische structuur is echt, niet gesynthetiseerd; de toetsenbordnavigatie is die van de browser, niet van de dia-app; en de schermlezeruitvoer is wat NVDA, JAWS of VoiceOver zou produceren voor elke goed gebouwde webpagina.
De implicaties zijn praktisch. Een Reveal.js-presentatie geserveerd vanuit een URL is standaard navigeerbaar met pijltoetsen, Tab, Enter, Spatie en dezelfde browserkortingen die een ziende gebruiker al kent. Elke dia is een section-element met een kop — H1 voor de presentatie, H2 voor elke diatitel — zodat een schermlezersgebruiker van kop naar kop kan springen zoals op elke webpagina. Afbeeldingen dragen alt-attributen geschreven in de Markdown- of HTML-bron. Grafieken weergegeven met Chart.js, D3 of een SVG-bibliotheek dragen welke ARIA-rollen en live-regioankondigingen de grafiekbibliotheek ook blootstelt; voor toegankelijke grafiekbibliotheken zoals Highcharts Accessibility of amCharts omvat dat schermlezersleesbare gegevenstabellen die automatisch naast de visuele grafiek worden gegenereerd.
Slidevs ontwikkelaarsgericht publiek heeft een ongewoon sterke set toegankelijkheidsstandaarden geproduceerd: kopsemantieken geërf van Markdown, alternatieve tekst vereist op het bronniveau (de compiler waarschuwt bij kale afbeeldingstags), en een toetsenbordnavigatielaag die werkt zonder configuratie. Marps sterkte ligt in plain-Markdown-presentaties gecompileerd naar HTML of PDF — dezelfde bron produceert zowel een schermlezersnavigeerbare webpresentatie als een getagde PDF, zonder een tweede schrijfpas. Reveal.js bevindt zich er tussenin: het meest flexibel, het grootste plug-in-ecosysteem, de diepste pool van derde-partij toegankelijkheidsplug-ins (Reveal Accessibility, reveal-a11y, het gepubliceerde WCAG-2.2-conformiteitsthema).
De afwegingen zijn reëel. Web-first presentaties vereisen een browser voor presenteren — geen lokaal bestand dubbel klikken, geen e-mail-het-pptx-workflow, geen offline laptopoptie die geen installatie vereist. Ze belonen auteurs die vertrouwd zijn met versiebeheer en continue implementatie; ze straffen auteurs die een grafiek uit Excel naar een dia willen slepen en klaar willen zijn. Voor een enkele lezing die achteraf als URL wordt gedeeld, is dit een duidelijke winst. Voor een kwartaalsbericht dat per e-mail naar een directeur gaat die het op een vlucht zal openen, is dit de verkeerde tool.
Waar web-first presentaties zijn gaan winnen is in terugkerende contexten. Universitaire lezingsreeksen die een heel semester van dia’s publiceren als één navigeerbare website. Conferentieprogramma’s waarbij de presentatie van elke lezing is gelinkt vanuit het programma en op een permanent URL staat. Engineering tech-talks waarbij de bronrepository zelf de versie van record is. In elk van deze contexten overleven de HTML-semantieken — zoekmachines indexeren de diainhoud als tekst, schermlezers doorlopen het als een document, en de onderhoudsverantwoordelijkheid van het toegankelijk blijven over de reeks heen valt aan het framework in plaats van aan elke individuele auteur.
Een beslisboom
De drie families van tools verdienen elk hun plaats in een andere productiecontext. De eenvoudigste versie van de beslissing is een driedeling op basis van waarvoor de presentatie daadwerkelijk wordt gebruikt.
Voor een eenmalige lezing die gemaild, geopend op de laptop van een collega, of geëxporteerd naar een getagde PDF voor distributie moet worden, kies PowerPoint. De Toegankelijkheidscontrole is volwassen, de exportpijplijn behoudt tags, en de publiekszijde-tooling (de PowerPoint-webviewer, de iPad-app, de Office Mobile-lezer) leest getagde PowerPoint allemaal correct. Plan negentig minuten audittijd per uur presentatie; plan de tijd in en gebruik hem.
Voor een terugkerende lezingsreeks, een conferentieprogramma, of elke context waarbij de presentatieverzameling op een URL staat en als corpus wordt doorbladerd, kies een web-first framework. Slidev voor ontwikkelaarsgericht publiek en Markdown-gewende auteurs; Marp voor plain-Markdown-teams die zowel HTML als getagde PDF nodig hebben vanuit dezelfde bron; Reveal.js voor het grootste plug-in-ecosysteem en de meeste ontwerpflexibiliteit. De toegankelijkheidseigenschappen worden geërf van de browser, niet nagebootst, en de onderhoudsverantwoordelijkheid valt aan het framework in plaats van aan elke auteur.
Voor een ontwerpintensieve keynote-lezing waarbij de presentatie als rekwisiet voor het podium dient en de inhoud in een apart gedistribueerd document leeft, kies Keynote, accepteer de dunnere toegankelijkheids-tooling, en stel het auditbudget in op het begeleidende document. Loop elke dia handmatig na voor alternatieve tekst. Exporteer naar .pptx en voer de controle als definitieve stap uit. Lever het begeleidende document (een paper, transcript, weboverzicht) als de canonieke toegankelijke versie.
Voor samenwerkingsgerichte cloud-first organisaties die al leven in Google Workspace, is Google Slides nu een haalbaar PowerPoint-alternatief voor dezelfde gebruikssituaties. De toegankelijkheidsopfrisbeurt van 2024 sloot de meeste historische kloof; de resterende kloven betreffen grafieksalternatieve tekst, complexe masters en offline bewerking. Voor presentaties die als gedeelde links worden geleverd in plaats van als gedownloade bestanden, is de workflow vergelijkbaar met PowerPoint.
Slotgedachten
Het patroon onder elke aanbeveling in deze primer is hetzelfde: de tool stelt de toegankelijkheidsbodem, maar de auteur stelt het plafond. De controle van PowerPoint zal de ontbrekende alternatieve tekst opsporen; hij zal er geen nuttige alternatieve tekst voor schrijven. Het ontbreken van een controle in Keynote zal men er niet van weerhouden een volledig toegankelijke presentatie te maken — het zal men alleen niet vertellen wanneer men heeft gefaald. De web-first frameworks erven de toegankelijkheidseigenschappen van HTML — ze handhaven ze niet. Elke tool in deze gids zal men laten een presentatie leveren die een deel van het publiek uitsluit. De toolkeuze verandert welke fouten makkelijk te maken zijn, niet welke fouten mogelijk zijn.
Als men een nieuwe toegankelijkheidsworkflow introduceert in een team dat er geen heeft, begin dan met de tool die het team al gebruikt, schakel de controle in, en audit één bestaande presentatie daarop als kalibratieoefening. Schakel pas over naar een andere tool nadat het team de zes basisvereisten heeft geïnternaliseerd — titels, leesvolgorde, alternatieve tekst, contrast, toetsenbord, media — en vraagt om capaciteiten die de huidige tool niet kan leveren. De kosten van tussentijds van tool wisselen zijn hoog; de kosten van het blijven gebruiken van een tool waarvan de workflow men is ontgroeid, zijn hoger.