Ein klares Ziel – und unendliche Möglichkeiten, es zu verfehlen. Warum sich das Thema digitale Barrierefreiheit nicht so anfühlen muss und wie ihr den Stein auch ohne Fachkenntnisse ins Rollen bringt. [Lesezeit: ca. 20 Minuten]
Disclaimer
Was ihr hier bekommt
Dieser Artikel hilft beim Einstieg und begleitet euch bei den ersten Schritten. Ihr könnt verschiedene Überprüfungs-Tools ausprobieren und so den Blick für Problemstellen auf eurer Website schärfen. Es gibt Hinweise für Kultur-Websites und Tipps, mit denen ihr eure Inhalte barrierefreier machen könnt – ganz ohne Programmierkenntnisse.
Eine wichtige Grundlage für diesen Artikel war der Vortrag von Wiebke Müller (Berliner Landesbeauftragte für digitale Barrierefreiheit) und Stephan Heinke (Überwachungsstelle für digitale Barrierefreiheit des Landes Berlin) bei unserer Veranstaltung „Redaktionelle Kniffe für zugänglichere Websites“ im April 2025.
Hier findet ihr die gesamte Aufzeichnung:
Was ihr hier nicht bekommt
Euch erwartet hier keine Darstellung sämtlicher Aspekte barrierefreier Websites. Wenn ihr auf der Suche nach umfangreichen Leitfäden seid, schaut in der Linksammlung am Ende dieses Artikels vorbei.
Ihr werdet auch nicht lernen, eure Website im Alleingang vollständig barrierefrei zu machen. Wenn ihr beispielsweise einen Relaunch plant, solltet ihr von Anfang an mit Barrierefreiheits-Expert:innen zusammenarbeiten, statt im Nachhinein mit automatischen Tools auf Fehlersuche zu gehen. Diese Expert:innen sollten optimalerweise über Alltagserfahrung mit assistiven Technologien wie Vorleseanwendungen (Screenreadern) verfügen.
Hinweis in eigener Sache
Auch wir sind mit unserer Website schon einige Schritte gegangen, um schwerwiegende Probleme zu beseitigen – andere stehen noch aus. In den kommenden Wochen sollen zum Beispiel unsere ALT-Texte kürzer, unsere Farbkontraste optimiert, unsere Teaser glattgezogen und unsere Formularfelder in Ordnung gebracht werden
So funktionieren Barrierefreiheits-Kriterien
Das Ziel
Das Ziel barrierefreier Websites könnte klarer nicht sein: Möglichst viele Menschen sollen gleich gut auf Inhalte und Services zugreifen und diese verstehen und nutzen können – unabhängig von Einschränkungen temporärer (Arm in Gips), permanenter (Blindheit) oder situationsbezogener Natur (laute Baustelle). International anerkannte Kriterienkataloge zergliedern dieses große Ziel in viele kleine Teilziele – sogenannte Zielnormen.
Der bekannteste Kriterienkatalog sind die Web Content Accessibility Guidelines (WCAG) des World Wide Web Consortium (W3C). Auf sie beziehen sich sämtliche in Deutschland gültigen Gesetze und Verordnungen zu digitaler Barrierefreiheit. Auch die EU-Norm hinter dem Barrierefreiheitsstärkungsgesetz (EN 301 549) ist zu großen Teilen an sie angelehnt.
Die Herausforderung
Eines der großen Hemmnisse beim Thema digitale Barrierefreiheit: Es gibt unendlich viele Möglichkeiten, dieses leicht verständliche Ziel zu verfehlen. Wie nah man dem Ziel mit den eigenen Maßnahmen gekommen ist, können zudem in vielen Punkten nur Expert:innen beurteilen.
Beispiel Alternativtexte
Das „Erfolgskriterium 1.1.1 Nicht-Text-Inhalt“ der WCAG 2.1-Richtlinie fordert: „Alle Nicht-Text-Inhalte, die dem Benutzer präsentiert werden, haben eine Textalternative, die einem äquivalenten Zweck dient […].“ Um dieser Aufforderung nachkommen zu können, müssen Website-Betreiber:innen also feststellen, zu welchem Zweck sie ein Bild, eine Grafik oder ein Video überhaupt einsetzen möchten. Erst daraus ergibt sich eine erste Idee, welchen Alternativtext die Medien bekommen sollten. Doch auch dann bleiben Fragen offen:
– Was, wenn man mehrere ähnliche Bilder verwendet, in Galerien beispielsweise?
– Wie geht man bei komplizierten Grafiken vor?
– Welche Fachbegriffe müssen erklärt werden?
– Wie lang sollte ein Alternativtext je nach Zweck sein?
Die richtige Lösung ergibt sich, wie bei vielen Barrierefreiheits-Kriterien, individuell nach Anwendungsfall.
Basiswissen für automatische Tests
Aus unseren Veranstaltungen mit Wiebke Müller (Berliner Landesbeauftragte für digitale Barrierefreiheit) und Stephan Heinke (Überwachungsstelle für digitale Barrierefreiheit des Landes Berlin) wissen wir, dass sich 25 bis 30 Prozent der Anforderungen an digital barrierefreie Websites automatisiert testen lassen.
Dabei gibt es eine Faustregel: Viele Mängel in der technischen Struktur einer Website lassen sich mit automatischen Tools gut aufspüren. Wenn es aber um die Qualität von Texten oder die inhaltliche Logik einer Klickreihenfolge geht, kommt man Fehlern nur mit menschlichem, bestenfalls geschultem Blick auf die Schliche. Auch weiterreichende Maßnahmen zur Erhöhung der Zugänglichkeit – wie die Bereitstellung von Inhalten in Deutscher Gebärdensprache oder in Leichter Sprache – fallen bei der automatischen Testung selbstverständlich raus.
Wir haben die kostenlosen Überprüfungs-Tools Silktide Accessibility Checker und WAVE über einige Kultur-Websites gejagt. Mehr zu den Tools im Abschnitt „Kostenlose Tools für automatische Tests“. Hier findet ihr eine Auswahl der Kriterien, bei denen die automatische Fehlersuche der Programme besonders häufig anschlug. Wo es möglich war, haben wir kulturspezifische Tipps und Hinweise hinzugefügt.
Ausreichende Farbkontraste
Wenn Text- und Hintergrundfarbe sich zu ähnlich sind, kann das (nicht nur) Menschen mit Sehbehinderungen oder Farbfehlsichtigkeit vor Probleme stellen. Farbkontraste sind zuverlässig automatisch testbar.
Alternativtexte
Wenn eure Website viele Bilder und Grafiken einsetzt, verfolgt sie damit ein Ziel. Zum Beispiel, die Pracht eines gefüllten Saals und die lockere Stimmung bei partizipativen Formaten zu zeigen. Oder in einer Infografik die Entwicklung eures Hauses, eurer Sammlung, eurer Aktivitäten zu beleuchten. Wann immer ein Bild eine atmosphärische oder inhaltliche Botschaft trägt, sollte diese sich auch in seinem Alternativtext wiederfinden.
Bei komplexen Grafiken sollte der Alternativ-Text statt einer Zusammenfassung zeigen, wo ausführlichere Infos zur Grafik in Textform zu holen sind. Das kann entweder im Text selbst oder in einem externen Dokument sein. Rein dekorative Grafiken sollten einen leeren Alt-Text (alt= „“) erhalten, damit Screenreader sie überspringen.
Automatische Tools können feststellen, ob alle Nicht-Text-Inhalte einer Website über Alternativtexte verfügen. Einige von ihnen zeigen auch an, ob die Texte eine angemessene Länge haben (12 – 15 Wörter). Ob sie die Botschaft tragen, die das Medium im Kontext vermitteln soll, können die Programme nicht feststellen. Mehr Hinweise und Praxistipps zu Alternativtexten findet ihr in der Linksammlung am Ende des Artikels.
Sonderfall Archive: Wer ein digitales Archiv betreibt, müsste enorme Ressourcen aufwenden, um sämtliche Archivinhalte barrierefrei zugänglich zu machen. Aus diesem Grund sind die Inhalte von Archiven von der Verpflichtung zur Barrierefreiheit ausgenommen. Aber Achtung: Für die Website eines (öffentlich finanzierten) Archivs gelten ansonsten dieselben Regeln, die auch für andere öffentliche Websites gelten.
Überschriften-Hierarchien
Damit Screenreader die Inhalte einer Website sinnentnehmend und in korrekter Reihenfolge vorlesen können, müssen ihre Inhalte auch semantisch korrekt strukturiert sein. In der HTML-Struktur bedeutet das, dass der Titel der Website (Bsp: „Unsere Spielstätten“) das Format H1 hat, die Hauptüberschriften („Spielstätte X“) das Format H2, die Unterüberschriften („Euer Weg zu Spielstätte X“) das Format H3 und so weiter. Dabei sollte keine Überschriftenebene übersprungen werden. Die kleinste Überschriftenebene ist H6.
Automatische Tests können anzeigen, ob die Reihenfolge rein technisch korrekt ist. Für die inhaltliche Logik müsst ihr selbst ran. Wenn euch nicht passt, wie die Überschriften auf eurer Website aussehen, solltet ihr (oder euer IT-Admin) die Gestaltung über das CSS anpassen, womit das Layout zentral bestimmt wird. So bleiben Semantik und Aussehen getrennt.
Tastaturbedienbarkeit
Menschen, die aufgrund motorischer Einschränkungen keine Maus bedienen können oder Menschen mit Sehbehinderungen nutzen häufig die Tasturnavigation, um sich durch Websites zu bewegen. Dafür muss jedes Bedienelement (Menüpunkte, Suchfelder, Buttons, Formularfelder, Checkboxen, …) via Tastatur erreichbar sein.
Automatische Tools zeigen an, welchen Weg der Code der getesteten Website für die Tastaturnavigation vorgezeichnet hat. Ob alle Bedienelemente angesteuert werden können, kann man hiermit grundlegend überprüfen – auch wenn verschiedene assistive Tools unterschiedlich auf die Struktur von Websites reagieren können.
Fokus-Reihenfolge
Jedes Bedienelement muss optisch sowie maschinenlesbar anzeigen, wenn es gerade klickbar angesteuert ist, sich also im Fokus befindet. Dass ein Objekt im Fokus ist, erkennt man zum Beispiel daran, dass sich darum ein Kasten bildet. Die Klickreihenfolge muss dabei logisch sein – und Nutzer:innen möglichst schnell ans gewünschte Ziel führen. Das bedeutet, dass sie sich in eurem Veranstaltungskalender nicht durch den gesamten Mai klicken müssen, um zum Juni zu gelangen. Dieser Punkt lässt sich gemeinsam mit der Tastaturbedienbarkeit überprüfen.
Maschinenlesbare Beschriftung für Formularfelder
Damit Personen mit Sehbehinderung sich in euer Newsletter-Formular eintragen können, muss der Screenreader erkennen können, welche Daten in welches Feld gehören. Dafür müssen die Felder technisch fest mit der abgefragten Angabe (Name, Vorname, Straße, etc.) verknüpft sein.
Eigenschaften verschiedener Website-Bereiche (semantisches HTML)
Mit Screenreadern kann man gezielt zu verschiedenen Bereichen der Website navigieren: Zum Menü, zum Suchfeld oder zum Footer beispielsweise. Damit das klappt, müssen diese Bereiche im Hintergrund mit entsprechenden Labels versehen sein. Automatische Tools zeigen diese Auszeichnungen, das sogenannte „semantische HTML“ an. Sie können auch feststellen, ob die wesentlichen Labels (Menü, Suchfeld, Footer etc.) in der HTML-Struktur der Seite korrekt vergeben sind.
Eigenschaften verschiedener Website-Bereiche (ARIA)
Für eine feinere Untergliederung und Kennzeichnung, beispielsweise von Multiple-Choice-Feldern oder Pflichtfeldern in Formularen, nutzen viele Websites sogenannte ARIA-Attribute. Automatische Tools zeigen auch diese Auszeichnungen an. ARIA-Attribute können eine sinnvolle Brücke zwischen komplexen Webanwendungen und assistiven Tools bilden. Oft werden sie aber genutzt, um Mängel im ursprünglichen Aufbau der Website auszugleichen. Das macht sie in puncto Barrierefreiheit zum zweischneidigen Schwert: Im Übermaß eingesetzt, können sie Websites für Screenreader unübersichtlich machen. Euer IT-Admin sollte sie daher nur nutzen, wenn eine Auszeichnung mittels semantischem HTML nicht möglich ist. In der Linksammlung am Ende des Artikels findet ihr weitere Infos zu ARIA-Attributen und Barrierefreiheit, die ihr auch an euren IT-Admin weitergeben könnt.
Maschinenlesbare Beschriftung für Buttons
Schaltflächen müssen für alle Nutzer:innen verständlich beschriftet sein, egal womit sie die Beschriftung lesen können. Während sehende Nutzer:innen oft aus dem Kontext erschließen können, wohin ein Button führt, sind Nutzer:innen von Screenreadern auf eine eindeutige Beschriftung von Buttons angewiesen. Automatische Tests können erfassen, ob der Button eine Beschriftung hat, nicht aber, ob sie auch inhaltlich eindeutig ist.
Eindeutige Linkbeschriftungen
Screenreader-Nutzer:innen können sich sämtliche Links einer Website in einer Liste anzeigen lassen – die leider oft noch viel aus „hier“ und „weiterlesen“ besteht. Auch für sehende Menschen ist es sinnvoll, aus der Beschriftung eines Links klar herauslesen zu können, wohin er führt. Beispielsweise, wenn sie die Website eines Bürgeramts scannend lesen, weil sie nach einem bestimmten Formular suchen: „Hier geht es zum Formblatt x für Anfrage y (PDF)“ ist auch ohne Kontext verständlich – „klick!“ oder „LINK“ nicht.
Achtung: Wie sinnvoll eure Link-Beschriftungen sind, können automatische Tools nicht feststellen, sie zeigen aber an, wenn Links zu unterschiedlichen Websites die gleiche Beschriftung tragen.
Linkziel im Alternativtext bei verlinkten Bildern
Wenn ihr das Logo einer Förderstelle oder einer Partnerorganisation nutzt, um deren Website zu verlinken, sollte der Alternativtext des Logos das verraten. Er könnte zum Beispiel lauten: „Zur Website der Förderstelle Y“. Automatische Tools erkennen verlinkte Bilddateien ohne Alternativtext.
Semantische Links
Statt einer losen Aneinanderreihung von Zahlen und Buchstaben sollte die URL eines Links möglichst akkurat auf ihren Inhalt verweisen. Bei Blogartikeln ist das meist ohnehin der Fall, da Content-Management-Systeme die URLs oft automatisch aus den Titeln generieren. Drauf achten solltet ihr bei Links, die beispielsweise zum Download von Dokumenten führen oder zu einem Teilbereich eurer Datenschutzerklärung.
Kostenlose Tools für automatische Tests
Es gibt verschiedene Arten kostenloser Tools, die ihr für die automatische Testung eurer Website nutzen könnt.
– Bookmarklets sind Mini-Programme, die ihr als Lesezeichen im Browser speichern und dann auf der zu testenden Seite aufrufen könnt. Jedes Bookmarklet macht jeweils eine verborgene Ebene der Website-Struktur (Überschriften-Ebenen, Alt-Texte, etc.) auf der aufgerufenen Website sichtbar, ohne den Ergebnissen jedoch eine Bewertung zuzuweisen. Wer sich schon etwas mit Barrierefreiheit und Website-Strukturen auskennt, kann sie nutzen, um Ebene für Ebene manuell zu erkunden. Auf der Werkzeugliste von „barrierefrei informieren und kommunizieren“ (BIK) findet ihr einen Unterpunkt mit einer Auflistung brauchbarer Bookmarklets.
– Web-Anwendungen zur Barrierefreiheits-Testung verfügen über eine Eingabemaske, in die ihr die zu testende Website eintragen könnt. Eine der bekanntesten, das WAVE-Tool, gehört zum gemeinnützigen WebAIM-Projekt der Utah State University und ist ebenfalls als Browser-Addon verfügbar.
Zur Website des WAVE-Tools zur Barrierefreiheits-Überprüfung von Websites
– Browser-Addons sind Zusatzprogramme, die im Browser (vor allem für Googles Chrome-Browser verfügbar) installiert werden können. Sie kann man – meist in Form einer seitlichen Taskleiste – zur gerade aufgerufenen Website hinzuschalten und zur Überprüfung verschiedener Kriterien nutzen.
Laut Wiebke Müller beziehen sich Web-Anwendungen und Browser-Addons auf die gleichen Algorithmen, werden also sehr ähnliche bis identische Ergebnisse ausspucken. Wählt daher einfach das Tool, das euch am einfachsten und übersichtlichsten erscheint. Nach unserer Erfahrung sind Browser-Addons wie WAVE und Silktide am einfachsten nutzbar.
Das Browser-Addon WAVE: Lohnender Einstieg für alle mit etwas Geduld und Zeit
Nach der Analyse übersäht das englischsprachige WAVE-Tool die überprüfte Website mit vielen bunten Icons und Symbolen, die auf Probleme oder Eigenschaften bezüglich der Barrierefreiheit hinweisen. Mit einem Klick auf die Icons kommt ihr zu ausführlicheren Beschreibungen. Ihr erfahrt, auf welche Kriterien der Web Content Accessibility Guidelines (WCAG) sie sich beziehen und was ihr tun könnt, um mögliche Fehler zu beheben. Viele der Empfehlungen sind umsetzbar, ohne den Code der Website anzufassen.
– Rote Icons: Fehler. Sie markieren ernsthafte Barrierefreiheitsprobleme (z. B. fehlender Alt-Text bei einem Bild, falsche Überschriftenstruktur oder Links, die nicht über ein maschinenlesbares Linkziel verfügen).
– Gelbe Icons: Warnungen. Sie geben Hinweise auf mögliche Probleme (z. B. niedriger Kontrast, lange oder übereinstimmende Alternativtexte).
– Grüne Icons: Barrierefreie Features. Sie zeigen z. B. korrekt verwendete ARIA-Rollen und vorhandene Alternativtexte an.
– Blaue Icons: Struktur. Sie beschreiben bestimmte Strukturelemente wie Überschriften oder Formularfelder.
– Violette Icons: ARIA-Attribute. Zeigen sämtliche Strukturelemente der Website an, denen ein ARIA-Attribut zugewiesen ist. Um euch für den Einstieg nicht zu überfordern, empfehlen wir, diese Auswertung an euren IT-Adminweiterzugeben und/oder ihn über die Seitenleiste auszublenden.
Silktide Accessibility Checker: Für den langsamen, leichten, spielerischen Einstieg
Der ebenfalls englischsprachige Silktide Accessibility Checker vom Tech-Unternehmen Silktide Ltd. eignet sich für alle, die sich lieber langsam vorantasten möchten, statt sofort (wie beim WAVE-Tool) mit einer von Icons übersäten Website überrumpelt zu werden.
Hier werden die erkannten Fehler und Merkmale zunächst nur in der seitlichen Tool-Bar aufgelistet. Klickt man sie an, springt das Tool zum Bereich der Website, in dem sich der Fehler oder das Merkmal befindet. Außerdem gibt es zusätzliche Hinweise zum WCAG-Kriterium hinter der Meldung und zu möglichen Verbesserungsmaßnahmen.
Die Tool-Bar bietet neben der Barrierefreiheits-Überprüfung auch die Möglichkeit, sich sämtliche Alternativtexte einer Seite anzeigen zu lassen. Außerdem gibt es (potenziell fragwürdige) Zusatzfunktionen, mit denen man Kurzsichtigkeit, Farbblindheit oder Dyslexie simulieren kann.
Das Browser-Addon AxeDevTools: Für den übersichtlichen Einstieg auf Deutsch
Das Browser-Addon AxeDevTools des Tech-Unternehmens Deque Systems muss nach Installation über die Entwicklertools von Chrome aufgerufen werden (1. Rechtsklick, 2. Untersuchen auswählen, 3. Tableiste ansteuern, 4. Pfeile nach rechts anklicken und Reiter „axe DevTools“ aussuchen).
Wer diesen etwas umständlichen Schritt geschafft hat, bekommt dafür eine deutschsprachige Übersicht der Mängel, die auf der aktuell aufgerufenen Website gefunden wurden. Die ebenfalls deutschsprachigen Handlungsempfehlungen sind hier ein klarer Vorteil. Fehler und Merkmale lassen sich nach Schweregrad sortieren. Allen Prüfstellen sind nicht nur WCAG-Kriterien zugeordnet, sondern auch die EU-Norm EN 301-549, die Grundlage des Barrierefreiheitsstärkungsgesetzes.
Im Gegensatz zu anderen Anwendungen bietet das Tool in der kostenlosen Variante keine Möglichkeit, die Struktur der Website nachzuvollziehen oder sich sämtliche Alternativtexte einer Seite anzeigen zu lassen.
Wie weiter mit den Testergebnissen?
Mängel eigenhändig beseitigen
Viele Probleme, die automatische Tools aufspüren können, lassen sich lösen, ohne den Code der Website anzufassen. Das betrifft fehlende oder zu lange Alternativtexte, Überschriften-Hierarchien oder Link-Beschriftungen. Ein Fall für eure Online-Redaktion – oder euch selbst.
Mängel an Fachpersonal weitergeben
Wenn der Code der Website betroffen ist, muss jemand mit Fachexpertise ran – zum Beispiel eure Webagentur oder interne IT-Kräfte. Das trifft beispielsweise bei Fehlern im Newsletter-Formular, bei unpassenden Stilen in der Überschriften-Hierarchie oder Mängeln in der Tastaturbedienbarkeit zu. Gibt es Probleme mit Farbkontrasten auf eurer Website, kann dies eine Schnittstellenaufgabe von IT und Design werden.
Den Status Quo in einer Barrierefreiheitserklärung transparent machen
Bisher sind nur ein paar der verfügbaren Formulare oder Angebote auf eurer Website barrierefrei?Nennt sie konkret in eurer Erklärung zur Barrierefreiheit – so gebt ihr Menschen die Chance, zumindest jene Teile eures Angebots zu nutzen, die für sie zugänglich sind. Auf der Website der Berliner Landesbeauftragten für digitale Barrierefreiheit erfahrt ihr, was drinstehen sollte. Dort gibt es außerdem eine Vorlage zum Download.
Das Momentum nutzen und weitere Schritte einleiten
Wie oben bereits erwähnt, lassen sich etwa 25 bis 30 Prozent der Anforderungen an digital barrierefreie Websites automatisiert testen. Die restlichen 70 bis 75 Prozent können nur manuell getestet werden. Hierfür gibt es verschiedene Ansätze.
Eine etablierte Herangehensweise ist die Testung durch zertifizierte Fachstellen. Sie prüfen auf der Basis eines festgelegten Protokolls, ob ein Webangebot bestimmten Anforderungen entspricht. Meist sind sie auf die Anforderungen spezialisiert, die sich aus der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) des Bundes ergeben. Viele dieser Fachstellen sind im „BIK BITV-Test Prüfverbund“ organisiert.
Doch es gibt prominente Stimmen, die deutliche Kritik am Prüfverbund und der Standardisierung von Prüfverfahren üben. Beispielsweise, weil sie objektive Messbarkeit suggerieren, wo die Vielfalt subjektiver menschlicher Bedürfnisse im Zentrum stehen sollte. Domingos de Oliveira, Experte für digitale Barrierefreiheit, führt viele Kritikpunkte in seinem Blogartikel aus: Die Größten Probleme des DIAS-BITV-Tests (Blogartikel von Domingos de Oliveira).
Der Gegenentwurf zur Testung durch Fachstellen ist die frühzeitige Einbindung von Expert:innen mit Behinderungen – selbstverständlich gegen eine angemessene Bezahlung. Das Argument: Wer wirklich belastbare Erkenntnisse über die Zugänglichkeit seiner digitalen Inhalte erhalten möchte, kommt mit nicht-behinderten Gutachter:innen oft nicht weit. Beispiel Screenreader: Ähnlich wie sehende Menschen Buchseiten in einem weit höheren Tempo überfliegen, als sie sie vorlesen würden, verarbeiten tägliche Nutzer:innen von Screenreadern deren Sprachausgabe in einem Tempo, bei dem andere kaum ein Wort verstehen.
Weiterführende Links
Wer auf eigene Faust weitermachen will, kann den Sprung in umfangreiche, öffentlich verfügbare Leitfäden und Übersichten wagen. Denn an denen mangelt es zum Glück nicht. Wir haben einige für euch zusammengestellt:
– Materialien der Landesfachstelle für Barrierefreiheit Sachsen-Anhalt
– Deutschsprachige Übersetzung der Web Content Accessibility Guidelines (WCAG) 2.1
– Leitfaden: Online-Kommunikation mit Alt-Texten
Wir arbeiten bereits an weiteren Tipps zu digitaler Barrierefreiheit. Ihr habt konkrete Fälle aus eurer Kulturwebsite, die auch für andere interessant sein könnten oder braucht weiterführende Tipps? Dann schreibt uns eine E-Mail – oder schaut im neuen kulturBdigital-Forum vorbei.