Erklärung zur Barrierefreiheit 2026 Was muss sie enthalten, wie wird sie erstellt und wer kontrolliert sie?
Ein praktischer Leitfaden für öffentliche Einrichtungen, Stiftungen und Unternehmen, die unter die EAA fallen – mit technischen HTML-Anforderungen, Meta-Tags und den häufigsten Fehlern.
Kurz gesagt
Für wen gilt dies:
Alle öffentlichen Einrichtungen (Behörden, Schulen, Krankenhäuser, Kultureinrichtungen, Stiftungen, die öffentliche Aufgaben wahrnehmen). Ab dem 28.06.2025 auch private Unternehmen in den vom European Accessibility Act erfassten Sektoren (E-Commerce, Bankwesen, Verkehr).
Frist:
Aktualisierung bis zum 31. März jedes Jahres. Neue Websites ab dem 1. August 2024 – zwingend im Format der Erklärung 2.0.
Format:
Ausschließlich HTML (kein PDF, kein Word, kein Bild). Muss vollständig digital zugänglich sein – auch wenn die Seite selbst die WCAG nicht erfüllt.
Meta-Tag: Das
Ministerium für Digitalisierung empfiehlt, in den Code jeder Unterseite folgenden Tag einzufügen: . Dies ermöglicht die automatische Erkennung der Erklärung durch Überwachungstools.
Strafe:
Bis zu 5.000 PLN bei fehlender oder unvollständiger Erklärung. Die Kontrolle erfolgt durch das Ministerium für Digitalisierung.
Die Erklärung zur Barrierefreiheit ist ein Dokument, das Nutzer – insbesondere Menschen mit Behinderungen – über den Stand der digitalen Barrierefreiheit einer Website oder einer mobilen App informiert. Es handelt sich dabei nicht um eine marketingtechnische Absichtserklärung. Es ist eine gesetzliche Verpflichtung, die sich aus dem Gesetz vom 4. April 2019 über die digitale Barrierefreiheit von Websites und mobilen Anwendungen öffentlicher Stellen ergibt. Selbst wenn Ihre Website die WCAG-Anforderungen nicht erfüllt, muss die Erklärung vorhanden und vollständig zugänglich sein. Dies ist eine bewusste Entscheidung des Gesetzgebers: Nutzer mit Behinderungen haben das Recht, vor der Nutzung der Website zu erfahren, was sie dort erwartet.
In diesem Artikel zeigen wir Ihnen, was genau die Erklärung im Jahr 2026 enthalten muss (Version 2.0, gültig ab 1. August 2024), wie man sie technisch veröffentlicht – einschließlich Meta-Tag und HTML-Identifikatoren – welche Fehler öffentliche Stellen am häufigsten begehen und wer dies kontrolliert.
Was hat sich durch die Erklärung zur Barrierefreiheit 2.0 geändert?
Am 31. Juli 2024 veröffentlichte das Ministerium für Digitalisierung eine neue Fassung der technischen Bedingungen für die Veröffentlichung der Erklärung – Version 2.0. Neue Websites, die ab dem 1. August 2024 erstellt werden, müssen diese Fassung anwenden. Bestehende Websites sollten die Erklärung bei der nächsten Überprüfung (bis zum 31. März) aktualisieren.
Die wichtigsten Änderungen
• Einheitliche Dokumentstruktur – feste Abschnitte und Überschriften, die für Screenreader vorhersehbar sind.
• Geänderte HTML-Identifikatoren (id-Attribut) – neue Abschnittsnamen, mehr erforderliche IDs.
• Obligatorischer Link zum Bericht oder zur Selbstbewertung – es reicht nicht aus, die Konformität zu erklären, man muss auch angeben, auf welcher Grundlage.
• Mehr HTML-Code-Beispiele in der Dokumentation – einfachere Umsetzung.
• Klarere Trennung der Erklärungen für Webseiten und mobile Anwendungen.
Was muss die Erklärung enthalten? Pflichtfelder
Die Erklärung zur Barrierefreiheit besteht aus mehreren festen Abschnitten. Jeder Abschnitt hat eine bestimmte Überschrift und eine HTML-Kennung. Nachfolgend finden Sie eine vollständige Liste mit Erläuterungen.
Einleitung – Erklärung zur BarrierefreiheitÜberschrift: „Erklärung zur Barrierefreiheit“. ID: id="a11y-deklaracja". Enthält den Namen der öffentlichen Einrichtung, den Namen der Website und den Status der Konformität mit der Norm EN 301 549 (die sich auf WCAG 2.1 AA bezieht). Der Status kann lauten: konform, teilweise konform, nicht konform. Wichtig: Wenn die Website teilweise konform oder nicht konform ist, musst du beschreiben, welche Elemente nicht barrierefrei sind und warum. Du darfst nicht schreiben „die Website ist konform“, wenn dies nicht der Fall ist.
Inhalte nicht verfügbarKennung: id="a11y-nichtkonform". Abschnitt, in dem konkrete Elemente beschrieben werden, die die Anforderungen nicht erfüllen. Typische Beispiele: fehlende Alt-Texte bei einigen Bildern, unstrukturierte PDF-Dokumente, Videos ohne Untertitel, Formulare ohne Beschriftungen. Zu jedem Problem sollte angegeben werden, wann es behoben wird oder warum eine Behebung nicht möglich ist (z. B. Archivmaterial vor dem 23.09.2018).
Erstellungsdatum und BewertungsmethodeDatum der ersten Veröffentlichung der Seite, Datum der letzten wesentlichen Aktualisierung, Datum der Erstellung der Erklärung, Datum der letzten Überprüfung. Bewertungsmethode: Selbstbewertung, internes Audit oder externes Audit. Die Erklärung 2.0 erfordert einen Link zu dem Bericht, der der Bewertung zugrunde liegt. Wenn Sie ein Audit durchgeführt haben – Link zum Bericht. Wenn Sie eine Selbstbewertung durchgeführt haben – Beschreibung der Methode.
Feedback und KontaktdatenIdentifikator: id="a11y-kontakt". Obligatorische Überschrift: „Feedback und Kontaktdaten“ – genau in dieser Form. Kontaktdaten (Vorname, E-Mail, Telefon) zur Meldung von Problemen mit der Barrierefreiheit. Beschreibung des Verfahrens zur Bearbeitung von Meldungen: unverzüglich, bis zu 7 Tage, maximal 2 Monate. Hinweis auf die Möglichkeit, eine Beschwerde beim Bürgerbeauftragten einzureichen, falls die Stelle nicht reagiert.
BarrierefreiheitKennung: id="a11y-architektura". Beschreibung der baulichen Barrierefreiheit des Standorts: Eingänge, Aufzüge, Toiletten, Behindertenparkplätze, Assistenzhunde, Gebärdensprachdolmetscher. Dies ist keine Option – jede öffentliche Einrichtung muss jeden Standort beschreiben.
Mobile Apps (falls zutreffend)Wenn ein Unternehmen mobile Apps anbietet, fügt es einen Abschnitt mit Informationen zu deren Verfügbarkeit, Download-Links und dem Kompatibilitätsstatus hinzu.
Technische Anforderungen für HTML Wie man eine Erklärung veröffentlicht
Die Erklärung muss im HTML-Format (beliebige Version) veröffentlicht werden. Es darf sich nicht um eine PDF-Datei, ein Bild, ein Word-Dokument oder einen Scan handeln. Sie muss die Anforderungen der WCAG 2.1 AA erfüllen – auch wenn die Website selbst diese Anforderungen nicht erfüllt.
Wo soll der Link platziert werden?
Der Link zur Erklärung muss auf jeder Unterseite sichtbar sein – in der Regel in der Fußzeile (Footer) oder in der Kopfzeile. Der Nutzer muss von jeder Unterseite aus auf intuitive und barrierefreie Weise zur Erklärung gelangen können. Der Linktext sollte „Erklärung zur Barrierefreiheit“ lauten – nicht „WCAG“, nicht „Barrierefreiheit“, nicht „A11y“.
Meta-Tag Empfehlung des Ministeriums für Digitalisierung
Neben dem sichtbaren Link in der Fußzeile empfiehlt das Ministerium für Digitalisierung, in den Quellcode jeder Unterseite einen Meta-Tag einzufügen, der auf die Adresse der Erklärung zur Barrierefreiheit verweist. Dadurch können die Überwachungstools (die vom Ministerium zur Kontrolle verwendet werden) die Erklärung automatisch finden, ohne die visuelle Struktur der Seite zu analysieren.
Das von gov.pl empfohlene offizielle Format lautet:
In der Praxis verwenden einige Akteure auch ein alternatives Format mit einem Link-Element:
<link rel="deklaracja-dostępności" href="https://twoja-strona.pl/deklaracja-dostepnosci">
Beide Formate kommen in der Praxis vor. Die offizielle Empfehlung des Ministeriums für Digitalisierung (Portal gov.pl/web/dostepnosc-cyfrowa) verweist auf den Meta-Tag. Das „link rel“-Format ist eine von einigen Institutionen verwendete Alternative, wird jedoch in den offiziellen Richtlinien nicht ausdrücklich erwähnt. Unsere Empfehlung: Verwenden Sie den Meta-Tag (da er offiziell ist) und fügen Sie gleichzeitig einen sichtbaren Link in die Fußzeile ein. Doppelte Abdeckung – Robots finden den Tag, Menschen finden den Link.
Wie implementiert man einen Meta-Tag im CMS TYPO3?
Im CMS TYPO3 kann der Meta-Tag auf zwei Arten hinzugefügt werden. Über TypoScript – global auf allen Unterseiten:
page.meta.deklaracja-dostępności = //deine-seite.pl/deklaracja-dostepnosci
Oder direkt in der Fluid-Vorlage im Abschnitt <head>: <br><strong><meta name="Zugänglichkeitserklärung" content="{f:uri.page(pageUid: 123)}"> </strong></head>
Der zweite Ansatz nutzt den Fluid ViewHelper, um die URL der Seite mit der Erklärung dynamisch zu generieren – wenn du den Slug der Erklärung änderst, wird der Meta-Tag automatisch aktualisiert.
Obligatorische HTML-Identifikatoren (id-Attribut) vollständige Liste
Die Deklaration 2.0 schreibt die Verwendung bestimmter Identifikatoren in HTML-Elementen vor. Das ist keine reine Dekoration – die Überwachungswerkzeuge des Ministeriums für Digitalisierung (darunter der Validator deklaracja-dostepnosci.info) suchen im Code nach ID-Attributen, die mit „a11y-“ beginnen, und bewerten anhand dieser die Vollständigkeit der Erklärung. Fehlende Identifikatoren = Erklärung für das Monitoring nicht erkennbar.
Nachfolgend finden Sie eine vollständige Liste der Identifikatoren, die gemäß den technischen Anforderungen des Ministeriums für Digitalisierung erforderlich sind, gruppiert nach Abschnitten.
Einleitung Erklärung
• a11y-deklaracja — Hauptüberschrift:
Erklärung zur Barrierefreiheit
• a11y-wstęp — gesamter Inhalt der Einleitung („Name der Einrichtung verpflichtet sich, die Barrierefreiheit zu gewährleisten...“)
• a11y-Einrichtung — Name der öffentlichen Einrichtung, z. B.Stadtverwaltung Krakau
• a11y-url — Link zur Website, auf die sich die Erklärung bezieht, z. B. Website der Stadtverwaltung
Abschnitt „Konformitätsstatus“
• a11y-status – Konformitätsstatus: konform / teilweise konform / nicht konform mit dem Gesetz
• a11y-niezgodnosc – Liste der nicht barrierefreien Inhalte (erforderlich, wenn der Status nicht „konform“ ist)
Abschnitt zur Erstellung der Erklärung
• a11y-data-sporzadzenie — Datum der Erstellung der Erklärung im Format JJJJ-MM-TT, z. B. 2026-03-15
• a11y-auditor — Name der externen Stelle, die das Audit durchgeführt hat (optional — nur erforderlich, wenn die Prüfung von einer externen Stelle durchgeführt wurde)
• a11y-ocena — Link zum Dokument mit der Analyse der übermäßigen Belastung (optional)
Kontaktbereich am häufigsten übersehen
Dies ist der Abschnitt, in dem am häufigsten IDs fehlen. Jedes Kontaktelement muss eine eigene ID haben:
• a11y-kontakt — Überschrift des Abschnitts:
Feedback und Kontaktdaten
• a11y-osoba — Vor- und Nachname der für die Barrierefreiheit zuständigen Kontaktperson, z. B. Jan Kowalski. Dies ist NICHT der Datenschutzbeauftragte — es handelt sich um den Barrierefreiheitskoordinator oder die Person, die diese Funktion ausübt.
• a11y-email — E-Mail-Adresse der Kontaktperson: [email protected]
• a11y-telefon — Telefonnummer der Kontaktperson
• a11y-procedura — Beschreibung des Beschwerdeverfahrens (was zu tun ist, wenn die Stelle nicht reagiert: Beschwerde beim Bürgerbeauftragten)
Warum a11y-osoba wichtig ist: Ein Nutzer mit Behinderung muss wissen, an wen er sich konkret wenden kann. „Kontakt“ reicht nicht aus – das Gesetz verlangt die Angabe einer Person. Der Validator prüft, ob diese Kennung im HTML-Code der Erklärung vorhanden ist.
Abteilung für bauliche und verkehrstechnische Barrierefreiheit
• a11y-architektura — Überschrift des Abschnitts:
Barrierefreiheit in der Architektur
• a11y-architektura-url — Link zu einer separaten Seite mit einer Beschreibung der Barrierefreiheit in der Architektur (falls sich die Beschreibung auf einer anderen Unterseite befindet)
• a11y-kommunikation — Abschnitt mit Informationen zur kommunikativen und informativen Barrierefreiheit (PJM-Dolmetscher, Induktionsschleife usw.)
• a11y-applikationen — Abschnitt mit mobilen Anwendungen (falls der Anbieter diese bereitstellt)
Beispiel für korrekten HTML-Code
Auszug aus dem Kontaktbereich mit allen erforderlichen Angaben:
<h2 id="a11y-kontakt">Feedback und Kontaktdaten</h2> <p>Ansprechpartnerin ist <span id="a11y-osoba">Anna Nowak</span>, E-Mail:<a id="a11y-email" href="mailto:[email protected]"> [email protected]</a>, Telefon: <span id="a11y-telefon">12 345 67 89</span>. </p> <div id="a11y-procedura"> <p>Jeder hat das Recht, die Gewährleistung der digitalen Barrierefreiheit einer Website oder eines ihrer Elemente zu verlangen...</p> </div>
Der Validator auf deklaracja-dostepnosci.info durchsucht den HTML-Code nach allen Elementen mit einem id-Attribut, das mit „a11y-“ beginnt, und vergleicht diese mit den Anforderungen der Technischen Bedingungen 2.0. Fehlt die erforderliche Kennung, wird die Erklärung als unvollständig markiert. Das Tool ist öffentlich zugänglich und jeder kann seine Erklärung vor der Überprüfung durch das Ministerium überprüfen.
Erforderliche HTML-Header
Die Erklärung 2.0 erfordert mindestens 8 Überschriften in einer entsprechenden Hierarchie:
• Erklärung zur Barrierefreiheit — Überschrift (h1)
• Stand der digitalen Barrierefreiheit — untergeordnet zur Überschrift (h2)
• Erstellung der Erklärung zur Barrierefreiheit — h2
• Feedback und Kontaktdaten – h2 (genau dieser Name, obligatorische Formulierung)
• Bearbeitung von Anträgen und Beschwerden im Zusammenhang mit der Barrierefreiheit — h2
• Architektonische Barrierefreiheit — h2
• Kommunikations- und Informationsbarrierefreiheit — h2
• Mobile Anwendungen — h2 (sofern die Einrichtung diese bereitstellt)
Die Hierarchie muss logisch sein: Wenn der Titel h1 ist, sind die Abschnitte h2. Wenn die Erklärung in eine Seite mit eigenem h1 eingebettet ist, kann der Titel der Erklärung h2 und die Abschnitte h3 sein. Wichtig: Es dürfen keine Ebenen übersprungen werden (z. B. h1 → h3 ohne h2). Der Screenreader verliert sonst den Kontext.
Die häufigsten Fehler Was beobachten wir bei unseren Kunden?
Bevor Sie mit der Veröffentlichung der Erklärung fortfahren, sollten Sie sich ansehen, wo am häufigsten Probleme auftreten. In der Praxis sind die meisten Fehler nicht auf mangelnden guten Willen zurückzuführen, sondern auf ungenaue Anforderungen oder das Kopieren vorgefertigter Vorlagen, ohne deren Bedeutung zu verstehen. Das Ergebnis ist dasselbe: Die Erklärung sieht „auf den ersten Blick“ korrekt aus, erfüllt jedoch nicht die formalen oder technischen Anforderungen und besteht die Validierung nicht. Im Folgenden haben wir die häufigsten Fehler zusammengestellt, die wir regelmäßig in Projekten sehen – sowohl bei öffentlichen Einrichtungen als auch bei Unternehmen, die den Anforderungen an die Barrierefreiheit unterliegen.
Formale Fehler
✗ Die Erklärung wurde als PDF veröffentlicht – dies verstößt gegen das Gesetz, sie muss im HTML-Format vorliegen.
✗ Es fehlt das Datum der letzten Überprüfung – die Erklärung scheint aus dem Jahr 2020 zu stammen.
✗ Keine Angaben zur Bewertungsmethode – es ist nicht bekannt, auf welcher Grundlage die Barrierefreiheit bewertet wurde.
✗ Fehlender Link zum Bericht oder zur Selbstbewertung – Anforderung der Erklärung 2.0.
✗ Kopieren der Erklärung von einer anderen Einrichtung – häufig, durch Überwachung leicht zu erkennen.
Technische Fehler
✗ Fehlende HTML-Identifikatoren (id-Attribut) – Überwachungstools erkennen die Abschnitte nicht.
✗ Fehlender Meta-Tag – automatische Erkennung nicht möglich.
✗ Überschriften in falscher Hierarchie – z. B. H3 nach H1 ohne H2. Der Screenreader verliert den Kontext.
✗ Die Erklärung selbst ist nicht barrierefrei – fehlender Kontrast, fehlende Tastaturnavigation, fehlende Fokusindikatoren. Ironie: Das Dokument zur Barrierefreiheit ist nicht barrierefrei.
Inhaltliche Fehler
✗ Der Status „konform“, obwohl die Website offensichtliche Probleme aufweist – das ist falsch und kann Anlass für eine Beschwerde sein.
✗ Fehlende Beschreibung nicht barrierefreier Inhalte – „die Website ist teilweise konform“, ohne zu erklären, was nicht konform ist.
✗ Fehlende Kontaktdaten des Barrierefreiheitsbeauftragten – der Nutzer weiß nicht, an wen er sich bei Problemen wenden soll.
✗ Fehlende Informationen zur baulichen Barrierefreiheit – besonders häufig bei Institutionen mit mehreren Standorten.
Wer überprüft die Erklärungen zur Barrierefreiheit? Welche Strafen drohen bei Nichteinhaltung der Vorschriften?
Die Überwachung der digitalen Barrierefreiheit wird vom Ministerium für Digitalisierung durchgeführt. Es veröffentlicht jährlich einen Bericht mit den Ergebnissen der Überprüfung der Websites öffentlicher Einrichtungen. Die Überprüfung kann planmäßig (Stichprobe) oder auf Hinweis eines Nutzers erfolgen.
Vorgehensweise: Das Ministerium fordert eine Nachbesserung – die Einrichtung hat 60 bis 120 Tage Zeit, um zu reagieren. Reagiert sie nicht, kann eine Geldstrafe von bis zu 5.000 PLN wegen fehlender oder unvollständiger Erklärung verhängt werden. In extremen Fällen kann das Ministerium die Einrichtung zur Einstellung des Dienstes verpflichten oder ein Verbot des weiteren Betriebs der Website erlassen.
Darüber hinaus hat jeder Nutzer das Recht, beim Bürgerbeauftragten eine Beschwerde wegen mangelnder Barrierefreiheit einzureichen. Das bedeutet, dass selbst wenn das Ministerium gerade Ihre Website nicht überprüft, ein Nutzer mit Behinderung das Verfahren selbst einleiten kann.
Wichtig: Ab dem 28. Juni 2025 unterliegen auch private Unternehmen in den vom EAA erfassten Sektoren (E-Commerce, Bankwesen, Verkehr, Telekommunikation) den Anforderungen an die Barrierefreiheit. Sie werden von anderen Behörden (PFRON, Branchenaufsichtsbehörden) kontrolliert, aber der Grundsatz ist derselbe: mangelnde Barrierefreiheit = rechtliche und finanzielle Konsequenzen.
Wie erstellt man eine Steuererklärung? Schritt für Schritt
Wenn Sie gerade eine Erklärung erstellen oder eine bestehende aktualisieren müssen, finden Sie hier eine bewährte Vorgehensweise.
- Führen Sie ein Barrierefreiheits-Audit Ihrer Website durch
Entweder selbst (Checkliste von gov.pl, Tools wie WAVE, Lighthouse und aXe) oder durch Beauftragung eines Prüfers. Du musst wissen, was konform ist und was nicht, bevor du die Erklärung verfasst.
- Sammeln Sie Daten zur barrierefreien Gestaltung
An jedem Standort: Eingänge, Aufzüge, Toiletten, Behindertenparkplätze, Assistenzhund, PJM-Dolmetscher.
- Schreibe eine Deklaration in HTML
Verwende die Struktur aus der Deklaration 2.0: Überschriften mit Kennungen, feste Abschnittsnamen, korrekte Hierarchie.
- Füge den Meta-Tag in den Code jeder Unterseite ein
- Füge einen sichtbaren Link in die Fußzeile ein
Der Text „Erklärung zur Barrierefreiheit“, der auf jeder Unterseite angezeigt wird.
- Überprüfen Sie die Verfügbarkeit der Erklärung selbst
Kontrast, Tastaturnavigation, Bildschirmleseprogramm. Die Erklärung muss vollständig barrierefrei sein.
Erstelle eine Erinnerung für die InspektionBis zum 31. März jedes Jahres und nach jeder größeren Neugestaltung der Website.
Häufig gestellte Fragen
Wenn die Stiftung öffentliche Aufgaben wahrnimmt oder öffentliche Mittel erhält – ja, dann unterliegt sie dem Gesetz über die digitale Barrierefreiheit. Wenn sie rein privat ist – muss sie nicht, kann aber ab dem 28.06.2025 dem EAA unterliegen, wenn sie in den betroffenen Sektoren (z. B. E-Commerce) tätig ist.
Nein. Das Gesetz schreibt das HTML-Format vor. PDF-Dateien sind nicht auf dieselbe Weise zugänglich wie HTML-Seiten – Screenreader unterstützen HTML nativ, während PDF-Dateien eine zusätzliche Struktur (PDF/UA-Tags) erfordern, über die die meisten Dokumente nicht verfügen.
Du musst die Erklärung dennoch veröffentlichen. Gib den Status „nicht konform“ oder „teilweise konform“ an und beschreibe konkret, welche Elemente nicht verfügbar sind. Die Erklärung ist keine Strafe – sie dient als Information für die Nutzer. Besser eine ehrliche Erklärung „nicht konform“ als eine falsche „konform“.
Der Meta-Tag () ist eine offizielle Empfehlung des Ministeriums für Digitalisierung – er dient dazu, dass die Erklärung von Überwachungstools automatisch erkannt wird. Der Link-Rel-Tag (<link rel="deklaracja-dostępności" href="URL">) ist ein alternatives Format, das von einigen Institutionen verwendet wird, jedoch nicht ausdrücklich in den offiziellen Richtlinien erwähnt wird. Unsere Empfehlung: Verwenden Sie den (offiziellen) Meta-Tag und fügen Sie einen sichtbaren Link in die Fußzeile ein.
Mindestens einmal jährlich – bis zum 31. März. Zusätzlich nach jeder größeren Neugestaltung der Website, einem Wechsel des CMS oder der Hinzufügung neuer Funktionen (Formulare, Multimedia, E-Services). In der Praxis empfiehlt es sich, die Erklärung nach jeder Aktualisierung von Inhalten zu überprüfen, die sich auf die Barrierefreiheit auswirken könnten (z. B. neue PDF-Dateien, neue Videos).
Der Generator ist ein guter Ausgangspunkt – er erstellt ein Grundgerüst mit den richtigen Abschnitten und Kennungen. Sie müssen ihn jedoch an Ihre konkrete Situation anpassen: Beschreiben Sie die tatsächlichen Probleme, fügen Sie Kontaktdaten, Informationen zur barrierefreien Zugänglichkeit und einen Link zum Bericht hinzu. Eine allgemeine Vorlage kann eine individuelle Bewertung des Zustands Ihrer Website nicht ersetzen.
Teilweise. Den Meta-Tag und den Link in der Fußzeile fügst du einmalig in TypoScript oder in einer Fluid-Vorlage ein. Der Inhalt der Deklaration ist eine HTML-Unterseite in TYPO3 – der Redakteur aktualisiert sie wie jede andere Seite auch. HTML-Identifikatoren fügen Sie manuell im HTML-Editor oder über einen speziellen Content Block ein. EYE-ABLE Report kann die Deklaration automatisch auf Basis der Scan-Ergebnisse generieren – sie muss jedoch trotzdem von einem Menschen überprüft werden.
Wie können wir helfen?
Die Erstellung einer korrekten Erklärung zur Barrierefreiheit erfordert drei Dinge: Kenntnisse über den Zustand Ihrer Website (Audit), Kenntnisse der rechtlichen und technischen Anforderungen (Version 2.0, Kennungen, Meta-Tag) sowie die Fähigkeit, dies in einem bestimmten CMS umzusetzen. Wir vereinen alle drei Aspekte.
Unser Portfolio umfasst realisierte Websites von öffentlichen Einrichtungen, Stiftungen und Institutionen auf dem CMS TYPO3 – darunter CUS Drobin, das Internationale Jugendbegegnungszentrum in Oświęcim und das Deutsche Historische Institut in Warschau. Jedes dieser Projekte erforderte eine vollständige Barrierefreiheitserklärung, ein WCAG-Audit und die Umsetzung von Korrekturen. Wir wissen, wie das in der Praxis aussieht – nicht nur in der Theorie.
Wenn Sie ein Barrierefreiheits-Audit, die Erstellung einer Erklärung gemäß Version 2.0, die Implementierung von Meta-Tags und HTML-Identifikatoren oder eine umfassende Anpassung Ihrer Website an die WCAG benötigen – kontaktieren Sie uns. Telefon: 12 333 44 01. E-Mail: [email protected].
