Bildbeschreibung: Ein Konferenzraum mit einer projizierten Folie und einem Laptop, auf dem die Lesereihenfolgen-Gliederung des Decks zu sehen ist — das visuelle Merkmal barrierefreier Präsentationsproduktion.

Lesezeit: 12 Minuten

Foliendecks sind nach wie vor das am häufigsten geteilte Lernmaterial im modernen Berufsleben — Vorlesungsunterlagen, Vorstandsberichte, Schulungsmodule, Konferenzvorträge, unternehmensweite Meetings. Sie sind auch fast ausnahmslos das am wenigsten barrierefreie Material in derselben Pipeline. Ein Vortrag, den Screenreader nicht navigieren können, ein Deck, dessen Diagrammwerte nur als Pixel existieren, ein eingebetteter Videoclip ohne Untertitel, eine „Klick zum Weiterblättern“-Interaktion, die die Tastatur ignoriert: Jedes davon ist die Norm, und jedes davon schließt dieselbe Gruppe von Menschen still vom selben Inhalt aus, den das übrige Publikum erhält. Die gute Nachricht ist, dass dies 2026 kein Forschungsproblem mehr ist. Es ist ein Produktionsworkflow-Problem mit drei guten Antworten und einem Entscheidungsbaum, der zwischen ihnen wählt.

Dieser Primer behandelt die drei Werkzeugfamilien, die Präsentierende tatsächlich auf ihrem Desktop haben — Microsoft PowerPoint, Apple Keynote und Google Slides — sowie die zunehmend ernstzunehmende web-first-Alternative (Reveal.js, Slidev, Marp), die von Lehrenden und Konferenzveranstaltern verstärkt bevorzugt wird. Es ist kein abstrakter Funktionsvergleich, sondern ein Produktionsleitfaden: welche Schritte in welchem Werkzeug in welcher Reihenfolge ausgeführt werden, um ein Deck auszuliefern, das eine blinde Studierende mit NVDA verfolgen kann, eine seheingeschränkte Kollegin bei 400 % Zoom lesen kann, eine gehörlose Teilnehmende mit eingebetteten Untertiteln mitlesen kann und eine tastaturabhängige Person navigieren kann, ohne jemals eine Maus zu berühren. Den breiteren Normenhintergrund bieten unser Primer zu WCAG 2.2-Adoptionsraten und der European Accessibility Act (EAA) — beide gelten inzwischen für pädagogische und kommerzielle, online vertriebene Folieninhalte.

Was ein barrierefreies Deck braucht

Vor den werkzeugspezifischen Workflows zunächst die Grundlage. Ein barrierefreies Foliendeck hat sechs gleichzeitig funktionierende Eigenschaften, und keine davon ist optional. Die erste ist ein eindeutiger, beschreibender Titel auf jeder Folie — das ist es, womit Screenreader-Nutzende von Folie zu Folie navigieren und worauf Gliederungsbereich-Nutzende zurückgreifen, um die gesuchte Folie zu finden. Mit „Folie 4“ oder „Ohne Titel“ betitelte Folien sind nicht navigierbar. Die zweite ist eine korrekte Lesereihenfolge. Folien, die durch Ablegen von Formen auf einer Leinwand ohne Verwendung der Platzhalter erstellt wurden, haben eine Lesereihenfolge, die der Einfügereihenfolge der Formen entspricht, nicht der visuellen Reihenfolge — das bedeutet, ein Screenreader liest eine Folie rückwärts, Seitenleiste zuerst, Fußzeile vor der Überschrift oder in welcher Reihenfolge der Produktionsprozess die Formen eingefügt hat. Die dritte sind Textalternativen für jedes nicht-dekorative Bild, Diagramm und Schaubild, formuliert in einer Sprache, die den Punkt vermittelt, den das Bild macht, nicht nur seine oberflächliche Beschreibung.

Die vierte ist ausreichender Farbkontrast — Text auf Folienhintergründen gemäß WCAG 2.2 AA (4,5:1 für Fließtext, 3:1 für großen Text und bedeutungstragende Grafiken), geprüft gegen die tatsächlichen Hintergrundpixel, nicht gegen den Folienmaster. Die fünfte ist Tastaturnavigierbarkeit — jedes interaktive Element, das Präsentierende erwarten, dass das Publikum es später nutzt (eingebettete Umfrage-Links, verzweigte Navigation, eingebettete Formulare), muss mit Tab, Eingabe, Leertaste und Escape allein erreichbar und bedienbar sein. Und die sechste ist die Medienbehandlung — jedes eingebettete Video hat entweder offene Untertitel, die in die Datei eingebrannt sind, oder eine Untertitelspur, die der Player einschalten kann; jeder eingebettete Audioclip hat ein Transkript, das von derselben Folie aus erreichbar ist; jede Animation, die nicht unbedingt notwendig ist, respektiert die Einstellung des Nutzenden zur Bewegungsreduktion auf Betriebssystemebene.

Jedes der drei Desktop-Werkzeuge liefert eine Teilmenge dieser sechs Eigenschaften. Keines liefert alle sechs automatisch. Die Wahl des richtigen Werkzeugs setzt voraus zu verstehen, was bei jedem manuell erledigt werden muss.

PowerPoint-Workflow

PowerPoint verfügt über die ausgereiftesten Barrierefreiheits-Werkzeuge aller Präsentations-Apps auf dem Markt — und das, seit der Microsoft-365-Releasezyklus damit begann, die Barrierefreiheitsprüfung in das Menüband zu integrieren. Ausgangspunkt ist die Prüfung selbst, die unter Windows über die Registerkarte „Überprüfen“ oder auf macOS über das Menü „Extras“ geöffnet wird. Sie zeigt eine kontextbezogene Live-Liste von Problemen — Folien ohne Titel, Bilder ohne Alternativtext, Textkombinationen mit niedrigem Kontrast, Tabellen ohne Überschriften, Hyperlinks, deren sichtbarer Text die URL dupliziert — und ein Klick auf ein Problem springt den Cursor zum betroffenen Element. Die Prüfung läuft in aktuellen Builds standardmäßig bei jedem Speichern, was der nützlichste Standard ist, den Microsoft in diesem Produkt eingeführt hat. Sie sollte nur deaktiviert werden, nachdem man verstanden hat, welche Warnungen bewusst ignoriert werden.

Folientitel werden über die Gliederungsansicht (Ansicht, Gliederung) und über den Titel-Platzhalter des Folienmasters verwaltet. Der Platzhalter statt eines freischwebenden Textfelds zu verwenden, verleiht dem Titel seine semantische Rolle — sowohl die Barrierefreiheitsprüfung als auch nachgelagerte Screenreader erkennen titulierte Folien anhand der Identität des Platzhalters, nicht anhand des sichtbaren Textes. Wenn die Titel eines Decks aus gestalterischen Gründen mit freischwebenden Textfeldern gesetzt sind, kann das Design beibehalten werden, indem ein unsichtbarer Platzhalter-Titel hinzugefügt wird, der den Platzhalter außerhalb der Leinwand verschiebt (Auswahlbereich, Position auf negative Koordinaten setzen) — der Titel existiert weiterhin im Barrierefreiheitsbaum und wird für die Screenreader-Navigation berücksichtigt, auch wenn das Publikum ihn nie sieht. Die Microsoft-Dokumentation beschreibt dies als „Folientitel außerhalb der Folie“-Muster; die Prüfung akzeptiert es.

Lesereihenfolge ist die zweite Säule. Den Auswahlbereich öffnen (Start, Anordnen, Auswahlbereich unter Windows; Anordnen-Menü auf macOS) und die Liste der Formen von unten nach oben lesen — das ist die Reihenfolge, in der ein Screenreader sie antrifft. Formen im Bereich durch Ziehen neu anordnen. PowerPoint 2024 hat einen dedizierten Lesereihenfolge-Bereich hinzugefügt, der die Reihenfolge numerisch über jeder Form auf der Folie visualisiert und eine Neuanordnung per Drag-and-drop direkt auf der Leinwand ermöglicht; wenn das Microsoft-365-Build aktuell genug ist, um diesen Bereich anzuzeigen, sollte dieser verwendet werden.

Alternativtext für Bilder wird durch Rechtsklick auf das Bild, Auswahl von „Alternativtext bearbeiten“ und Eingabe von ein bis zwei editorischen Sätzen gesetzt — dem Sinn des Bildes, nicht seinem Pixelinhalt. Der automatisch generierte Alternativtext von PowerPoint ist opt-in und als solcher im Bereich gekennzeichnet; er ist ein Ausgangspunkt, kein fertiges Produkt, und die Prüfung warnt, wenn eine Folie mit dem einzigen Alternativtext „Automatisch generierte Beschreibung“ ausgeliefert wird. Für in PowerPoint erstellte Diagramme sollte der Alternativtext das Argument des Diagramms in einem Satz zusammenfassen und zwei bis drei Spitzenwerte nennen — „Balkendiagramm zeigt Konferenzteilnahme 2026 um 18 % gegenüber 2025 gestiegen, angeführt von den Regionen EMEA und APAC“ ist besser als „Balkendiagramm.“ Für datenintensive Folien empfiehlt es sich, die zugrunde liegenden Daten als eine zwar verborgene, aber erreichbare Tabelle in den Sprechernotizen oder als verknüpfte Tabelle im Anhang bereitzustellen, damit Screenreader-Nutzende die Zahlen zusätzlich zur Kernaussage des Diagramms lesen können.

Eingebettetes Video ist die mit Abstand häufigste Compliance-Verletzung in PowerPoint-Decks. Der Workflow Einfügen → Video → Untertitel einfügen akzeptiert WebVTT-Dateien (.vtt) und bindet sie an den eingebetteten Clip; nach dem Anhängen werden die Untertitel im eingebauten Player von PowerPoint dargestellt und reisen mit der Datei mit, wenn das Deck geteilt, per E-Mail gesendet oder hochgeladen wird. Wenn das Quellvideo eingebrannte offene Untertitel hat, meldet die Prüfung die Datei dennoch als unzureichend — eine minimale VTT-Datei sollte trotzdem hinzugefügt werden, da nachgelagerte Werkzeuge diese Datei lesen. Hyperlinks sollten sichtbaren Text haben, der das Ziel beschreibt („Den EAA-Durchsetzungsbericht 2026 lesen“), nicht die nackte URL.

PowerPoints Exportpipeline bewahrt die meisten Barrierefreiheits-Metadaten beim PDF-Export — vorausgesetzt, Datei → Exportieren → PDF/XPS erstellen (Windows) oder Datei → Speichern unter → PDF mit der Option „Optimal für elektronische Verteilung und Barrierefreiheit“ (macOS) wird verwendet. Export über „Als PDF drucken“ entfernt die Tags und erzeugt ein nicht barrierefreies Flat-PDF; dies ist die häufigste stille Fehlfunktion im gesamten Workflow.

Keynote-Workflow

Keynote wird mit wesentlich weniger Barrierefreiheits-Werkzeugen als PowerPoint ausgeliefert, und diese Lücke hat sich seit dem Releasezyklus 13.x nicht wesentlich geschlossen. Es gibt kein Äquivalent zur Barrierefreiheitsprüfung — Keynote führt kein folienseitiges Audit durch, zeigt keinen Lesereihenfolge-Bereich pro Folie und warnt nicht, wenn eine Folie keinen Titel hat. Die Folien selbst haben eine stärkere VoiceOver-Integration als PowerPoint vor einem Jahrzehnt, aber der Produktionsworkflow für ein barrierefreies Deck aus Keynote ist bei jedem Schritt manueller.

Folientitel werden über den Titel-Platzhalter im Folienmaster oder als reguläres Textfeld, das im gesamten Deck konsistent verwendet wird, hinzugefügt. Keynotes Gliederungsansicht (Ansicht, Gliederung) liest den Titel-Platzhalter aus, weshalb das Erstellen von Decks gegen den Master anstatt auf leeren Folien der wichtigste Hebelpunkt ist. Die Lesereihenfolge wird über den Arrange-Inspektor verwaltet — die Vor-/Zurück-Steuerelemente im Stapelmodell von Keynote dienen gleichzeitig als Lesereihenfolge-Steuerelemente, wobei weiter zurückversetzte Formen zuerst gelesen werden. Es gibt keinen dedizierten Lesereihenfolge-Bereich; man muss ein mentales Modell des Stapels pflegen oder komplexe Folien von einer bekanntermaßen korrekten Basis aufbauen.

Bild-Alternativtext in Keynote wird über das Feld „Beschreibung“ auf der Registerkarte „Bild“ des Format-Inspektors festgelegt — dasselbe editorische Alternativtext-Format wie in PowerPoint. Für Diagramm-Alternativtext gilt derselbe Mechanismus. Keynote warnt nicht vor fehlendem Alternativtext. Die einzige Möglichkeit, die Alternativtext-Abdeckung eines Decks in Keynote zu überprüfen, besteht darin, jede Folie manuell durchzugehen oder in das PowerPoint-Format (.pptx) zu exportieren und die Barrierefreiheitsprüfung von Microsoft gegen den Export auszuführen — ein Workflow, den mehrere große Universitäten als Gatekeeping-Schritt für Keynote-Vorlesungsdecks übernommen haben.

Eingebettetes Video in Keynote unterstützt keine separate Untertitelspur. Wenn das Quellvideo keine eingebrannten offenen Untertitel hat, muss das Video entweder vor dem Einfügen in Keynote mit einkodierten Untertiteln neu gerendert werden oder der Einbettung durch einen verlinkten Verweis auf ein auf einer Untertitel-fähigen Plattform gehostetes Video ersetzt werden (YouTube, Vimeo, der Medienserver der eigenen Institution). Keynote wird nicht untertiteltes Video still in ein exportiertes PDF aufnehmen; die Prüfung, die nicht existiert, kann davor nicht warnen.

Keynote behauptet seinen Platz bei designintensiven Decks für Keynote-Vorträge, die nicht zur Weiterverteilung gedacht sind. Seine Typografie-, Layout- und Animationsqualität ist nach wie vor die beste im Desktop-Präsentationsmarkt — wenn das Deck im Wesentlichen eine Bühnenstütze ist und der inhaltliche Schwerpunkt in einem separat verteilten Aufsatz, Transkript oder einer Webseite liegt, bietet Keynote eine stärkere Live-Erfahrung, und die Barrierefreiheitslast verlagert sich auf das Begleitdokument. Wenn das Deck selbst das Lieferergebnis ist, ist PowerPoint die bessere Wahl.

Google-Slides-Workflow

Google Slides hat sich seit dem Barrierefreiheits-Refresh 2024 deutlich verbessert, der ein Barrierefreiheitsmenü pro Folie, von Gemini-Klasse-Bildmodellen unterstützte Alternativtext-Vorschläge und ein Kontrastprüfungs-Overlay hinzugefügt hat, das über Extras → Barrierefreiheit zugänglich ist. Der Refresh 2024 hat auch Lesereihenfolge-Steuerelemente zum Anordnen-Menü hinzugefügt — zum ersten Mal in der Produktgeschichte können Slides-Autorinnen und -Autoren eine explizite Lesereihenfolge festlegen, anstatt sich auf die Form-Einfügereihenfolge zu verlassen. Die Übernahme dieser Funktionen in großen Enterprise-Tenants verlief schneller als von Microsoft zunächst erwartet, zum Teil weil Slides-Decks bereits überwiegend cloud-gehostet sind und sofort von der serverseitigen Prüfung profitieren.

Die Mechanismen sind jedem vertraut, der von PowerPoint kommt. Titel werden über den Titel-Platzhalter des Master-Layouts verwaltet. Alternativtext wird über Formatoptionen → Alternativtext mit derselben ein-bis-zwei-Satz-Editorionsregel gesetzt. Die Lesereihenfolge nutzt das Menü Anordnen → Reihenfolge, mit dem neuen Lesereihenfolge-Bereich aus 2024, der unter Extras → Barrierefreiheit → Lesereihenfolge sichtbar ist. Das Einbetten von Videos von Google Drive oder YouTube respektiert die Untertitelspur der Quelle, und eine Folie mit einem nicht untertitelten Video löst im Barrierefreiheitsbereich eine Warnung aus.

Wo Slides PowerPoint noch hinterherhinkt, ist bei der Diagramm-Barrierefreiheit (der automatisch generierte Diagramm-Alternativtext ist kürzer und weniger kontextbewusst), bei komplexer Master-Vererbung (tief angepasste Master-Layouts erzeugen schwerer zu debuggende Lesereihenfolge-Strukturen) und bei Offline-Workflows (die Barrierefreiheitsprüfung erfordert eine Online-Verbindung, was ein Problem für Nutzende ist, die im Flugzeug oder in eingeschränkten Umgebungen arbeiten). Für ein Enterprise, das 2026 auf Workspace standardisiert ist und Decks vorwiegend als freigegebene Google-Slides-Links statt als heruntergeladene Dateien ausliefert, ist der Slides-Workflow inzwischen wesentlich mit PowerPoint vergleichbar. Für Organisationen, die Decks als .pptx-Anhänge oder als exportierte PDFs versenden, hat PowerPoint noch die Nase vorn.

Web-first-Decks: Reveal.js, Slidev, Marp

Die interessanteste Entwicklung bei der Barrierefreiheit von Präsentationen in den Jahren 2025 und 2026 hat außerhalb der drei großen Desktop-Apps stattgefunden. Eine Gruppe von web-first-Präsentations-Frameworks — Reveal.js (das altbewährte JavaScript-Framework), Slidev (ein Vue-basiertes Werkzeug für Entwickelnde) und Marp (ein Markdown-first-Generator, der nach HTML, PDF oder PPTX kompiliert) — erzeugt Foliendecks als HTML-Dokumente, was bedeutet, dass die Barrierefreiheitseigenschaften von HTML vererbt statt emuliert werden. Die semantische Struktur ist real, nicht synthetisiert; die Tastaturnavigation ist die des Browsers, nicht die der Folien-App; und der Screenreader-Output ist das, was NVDA, JAWS oder VoiceOver für jede gut gebaute Webseite produzieren würden.

Die Implikationen sind praktisch. Ein Reveal.js-Deck, das unter einer URL bereitgestellt wird, ist standardmäßig mit Pfeiltasten, Tab, Eingabe, Leertaste und denselben Browser-Shortcuts navigierbar, die sehende Nutzende bereits kennen. Jede Folie ist ein section-Element mit einer Überschrift — H1 für das Deck, H2 für jeden Folientitel —, sodass Screenreader-Nutzende wie auf einer beliebigen Webseite von Überschrift zu Überschrift springen können. Bilder haben alt-Attribute, die in der Markdown- oder HTML-Quelle geschrieben sind. Mit Chart.js, D3 oder einer beliebigen SVG-Bibliothek gerenderte Diagramme tragen die ARIA-Rollen und Live-Region-Ankündigungen, die die Diagrammbibliothek bereitstellt; bei barrierefreien Diagrammbibliotheken wie Highcharts Accessibility oder amCharts umfasst das automatisch neben dem visuellen Diagramm generierte, screenreader-lesbare Datentabellen.

Slidevs entwicklerorientiertes Publikum hat einen ungewöhnlich starken Standard-Barrierefreiheits-Set produziert: aus Markdown geerbte Überschriften-Semantik, auf Quelldateiebene geforderter Alternativtext (der Compiler warnt bei nackten Bild-Tags) und eine Tastaturnavigationsschicht, die ohne Konfiguration funktioniert. Marps Stärke liegt in reinen Markdown-Decks, die nach HTML oder PDF kompiliert werden — dieselbe Quelle erzeugt sowohl ein screenreader-navigierbares Web-Deck als auch ein getaggtes PDF ohne zweiten Autorierungsdurchlauf. Reveal.js liegt dazwischen: das flexibelste, mit dem größten Plugin-Ökosystem, dem tiefsten Pool an Drittanbieter-Barrierefreiheits-Plugins (Reveal Accessibility, reveal-a11y, das veröffentlichte WCAG-2.2-Konformitätsthema).

Die Kompromisse sind real. Web-first-Decks erfordern einen Browser zur Präsentation — kein lokaler Datei-Doppelklick, kein Pptx-per-E-Mail-Workflow, kein Offline-Laptop-Fallback ohne Setup. Sie belohnen Autorinnen und Autoren, die mit Versionskontrolle und Continuous Deployment vertraut sind; sie bestrafen Autorinnen und Autoren, die ein Diagramm aus Excel auf eine Folie ziehen und fertig sein wollen. Für einen einzelnen Vortrag, der danach als URL geteilt wird, ist das ein klarer Vorteil. Für ein quartalsweises Vorstandsupdate, das per E-Mail an eine Vorständin gesendet wird, die es in einem Flugzeug öffnet, ist das das falsche Werkzeug.

Web-first-Decks haben sich dort durchgesetzt, wo sie wiederkehrende Kontexte bedienen. Universitätsvorlesungsreihen, die ein ganzes Semester an Folien als eine einzige navigierbare Website veröffentlichen. Konferenzprogramme, bei denen das Deck jedes Vortrags über den Zeitplan verlinkt ist und unter einer dauerhaften URL steht. Engineering-Tech-Talks, bei denen das Quell-Repository selbst die Versionsreferenz ist. In jedem dieser Kontexte bleibt die HTML-Semantik erhalten — Suchmaschinen indizieren den Folieninhalt als Text, Screenreader durchlaufen ihn als Dokument, und die Wartungslast, über die Reihe hinweg barrierefrei zu bleiben, liegt beim Framework, nicht bei jeder einzelnen Autorin und jedem einzelnen Autor.

Ein Entscheidungsbaum

Jede der drei Werkzeugfamilien behauptet ihren Platz in einem anderen Produktionskontext. Die einfachste Version der Entscheidung ist eine Dreiteilung basierend darauf, wofür das Deck tatsächlich verwendet wird.

Für einen einmaligen Vortrag, der per E-Mail gesendet, auf einem Laptop einer Kollegin geöffnet oder als getaggtes PDF für die Verteilung exportiert werden soll: PowerPoint wählen. Die Barrierefreiheitsprüfung ist ausgereift, die Exportpipeline bewahrt Tags, und die Tooling auf Publikumsseite (der PowerPoint-Web-Viewer, die iPad-App, der Office-Mobile-Reader) liest getaggte PowerPoint-Dateien korrekt. Neunzig Minuten Audit-Zeit pro einstündigem Deck einplanen; die Zeit budgetieren und nutzen.

Für eine wiederkehrende Vorlesungsreihe, ein Konferenzprogramm oder jeden Kontext, in dem die Deck-Sammlung unter einer URL lebt und als Korpus durchsucht wird: ein web-first-Framework wählen. Slidev für entwicklerorientierte Zielgruppen und Markdown-vertraute Autorinnen und Autoren; Marp für reine Markdown-Teams, die aus derselben Quelle sowohl HTML als auch getaggtes PDF benötigen; Reveal.js für das größte Plugin-Ökosystem und die größte Designflexibilität. Die Barrierefreiheitseigenschaften werden vom Browser vererbt, nicht emuliert, und die Wartungslast liegt beim Framework, nicht bei jeder Autorin und jedem Autor.

Für einen designintensiven Keynote-Vortrag, bei dem das Deck als Bühnenstütze fungiert und der inhaltliche Schwerpunkt in einem separat verteilten Dokument liegt: Keynote wählen, das dünnere Barrierefreiheits-Tooling akzeptieren und das Audit-Budget in das Begleitdokument investieren. Jede Folie manuell auf Alternativtext prüfen. Für den abschließenden Durchgang nach .pptx exportieren und die Prüfung ausführen. Das Begleitdokument (ein Aufsatz, ein Transkript, eine Web-Zusammenfassung) als kanonische barrierefreie Version ausliefern.

Für kollaborative, cloud-first-Organisationen, die bereits in Google Workspace arbeiten und Decks vorwiegend als freigegebene Links statt als heruntergeladene Dateien versenden: Google Slides ist inzwischen für dieselben Anwendungsfälle eine praktikable PowerPoint-Alternative. Der Barrierefreiheits-Refresh 2024 hat die historische Lücke weitgehend geschlossen; die verbleibenden Lücken betreffen Diagramm-Alternativtext, komplexe Master und Offline-Bearbeitung.

Abschließende Gedanken

Das Muster hinter jeder Empfehlung in diesem Primer ist dasselbe: Das Werkzeug setzt den Barrierefreiheitsboden, aber die Autorin oder der Autor setzt die Decke. Die PowerPoint-Prüfung erkennt fehlenden Alternativtext; sie schreibt ihn nicht. Keynotes fehlende Prüfung hindert nicht daran, ein vollständig barrierefreies Deck zu erstellen — sie verhindert nur, auf Fehler hingewiesen zu werden. Die web-first-Frameworks erben die Barrierefreiheitseigenschaften von HTML — sie erzwingen sie nicht. Jedes Werkzeug in diesem Leitfaden ermöglicht es, ein Deck auszuliefern, das einen Teil des Publikums ausschließt. Die Werkzeugwahl beeinflusst, welche Fehler leicht gemacht werden können, nicht welche möglich sind.

Wer einen neuen Barrierefreiheits-Workflow in ein Team einführt, das bisher keinen hatte, sollte mit dem bereits genutzten Werkzeug beginnen, dessen Prüfung einschalten und ein bestehendes Deck zur Kalibrierung dagegen auditieren. Zu einem anderen Werkzeug sollte nur gewechselt werden, wenn das Team die sechs Grundanforderungen — Titel, Lesereihenfolge, Alternativtext, Kontrast, Tastatur, Medien — verinnerlicht hat und nach Fähigkeiten fragt, die das aktuelle Werkzeug nicht liefern kann. Die Kosten eines Werkzeugwechsels in der Mitte sind hoch; die Kosten, bei einem Werkzeug zu bleiben, dessen Workflow man entwachsen ist, sind höher.