EN 301 549 Konformitätsbericht #
Dieser Bericht ist eine strukturierte Selbstbewertung von EthicsPortal gegen die Anforderungen zur Barrierefreiheit in EN 301 549 V3.2.3 (und damit transitiv WCAG 2.2 Level AA). Er richtet sich an Beschaffungsprüfer:innen, die eine klauselweise Antwort benötigen, die über die Erklärung zur Barrierefreiheit hinausgeht.
| Feld | Wert |
|---|---|
| Produkt | EthicsPortal — EU-Compliance-Plattform für Hinweisgeber:innen |
| Produktversion | Kontinuierliche Bereitstellung; dieser Bericht beschreibt den Stand am Erstellungsdatum |
| Norm | EN 301 549 V3.2.3 (umfasst WCAG 2.2 Level AA) |
| Konformitätsansatz | Selbstbewertung |
| Erstellungsdatum | 14. Mai 2026 |
| Nächste Überprüfung | August 2026 (vierteljährlich) |
| Kontakt | accessibility@ethicsportal.eu |
Eine PDF-Fassung dieses Berichts kann für Beschaffungsverfahren auf Anfrage bereitgestellt werden.
Geltungsbereich #
Dieser Bericht deckt drei Bereitstellungsflächen ab:
- Webanwendung —
secure.ethicsportal.eu, die authentifizierte Oberfläche für Fallbearbeiter:innen - Öffentliche Meldeportale —
*.ethicsportal.eu, die hinweisgeberseitige Einreichung und Fallverfolgung - Marketing-Website —
ethicsportal.eu, die mit Hugo gerenderte öffentliche Website (einschließlich dieser Seite)
Er deckt außerdem über diese Flächen ausgelieferte Dokumente zum Download sowie Support-Dienste ab.
EthicsPortal ist ein webbasiertes SaaS-Produkt. Es bietet keine nativen Mobile Apps, Kiosk-Hardware, bidirektionale Sprach-IKT, Videoausgabe für Medien oder Echtzeittext. Die Klauseln 6, 7, 8 und 13 der EN 301 549 sind daher weitgehend nicht anwendbar.
Zusammenfassung #
| Klauselbereich | Status |
|---|---|
| §5 Allgemeine Anforderungen | Konform, mit Ausnahmen in §5.4 |
| §6 IKT mit bidirektionaler Sprachkommunikation | Nicht anwendbar |
| §7 IKT mit Videofunktionen | Nicht anwendbar |
| §8 Hardware | Nicht anwendbar |
| §9 Web | Teilweise konform (siehe §9-Details) |
| §10 Nicht-Web-Dokumente | Nicht konform — siehe §10.1 |
| §11 Software | Teilweise konform (siehe §11-Details) |
| §12 Dokumentation und Support-Dienste | Konform |
| §13 IKT mit Vermittlungs- oder Notrufzugang | Nicht anwendbar |
Klauselweise Bewertung #
§5 Allgemeine Anforderungen #
| Klausel | Anforderung | Status | Hinweise |
|---|---|---|---|
| 5.1.2.2 / 5.1.3 | Aktivierung von Barrierefreiheits-Funktionen | Konform | Die Plattform stellt Barrierefreiheits-Funktionen über Standard-HTML und ARIA bereit. Kein proprietärer Aktivierungsschritt erforderlich |
| 5.2 | Aktivierung von Barrierefreiheits-Funktionen | Konform | Einstellungen auf Browser- und OS-Ebene (Zoom, Kontrast, reduzierte Bewegung, Screenreader) werden berücksichtigt |
| 5.3 | Biometrie | Nicht anwendbar | Authentifizierung erfolgt per Magic Link oder Einmalcode mit optionalem TOTP; keine biometrische Eingabe erforderlich |
| 5.4 | Erhalt von Barrierefreiheits-Informationen bei der Konvertierung | Teilweise konform | Anwendungsinhalte erhalten Barrierefreiheits-Informationen; PDF-Exporte nicht (siehe §10.1) |
| 5.5 | Bedienbare Teile | Konform | Alle interaktiven Elemente sind per Tastatur und Zeigegerät bedienbar; Zielgröße erfüllt §2.5.8 |
| 5.6 | Sperr- oder Schaltzustände | Konform | Schaltzustände werden über aria-pressed / aria-expanded bereitgestellt |
| 5.7 | Tastenwiederholung | Nicht anwendbar | Software konfiguriert keine System-Tastenwiederholung |
| 5.8 | Akzeptanz von Doppelanschlägen | Nicht anwendbar | Software konfiguriert keine System-Tastenakzeptanz |
| 5.9 | Gleichzeitige Benutzeraktionen | Konform | Keine Interaktion erfordert gleichzeitige Benutzeraktionen |
§9 Web (umfasst WCAG 2.2 Level A und AA) #
EthicsPortal zielt auf WCAG 2.2 Level AA. Die in WCAG 2.2 neu hinzugekommenen Kriterien werden einzeln berichtet, damit Prüfer:innen die Abdeckung über WCAG 2.1 hinaus bestätigen können.
Prinzip 1 — Wahrnehmbar
| SC | Titel | Stufe | Status | Hinweise |
|---|---|---|---|---|
| 1.1.1 | Nicht-Text-Inhalte | A | Konform | Bilder und SVG-Icons haben Alt-Text oder sind als dekorativ gekennzeichnet. Icon-only-Schaltflächen tragen aria-label. Allein über Icons vermittelte Status haben ein sr-only-Textäquivalent |
| 1.2.x | Zeitbasierte Medien | A/AA | Nicht anwendbar | Keine Audio- oder Videoinhalte |
| 1.3.1 | Info und Beziehungen | A | Konform | Semantisches HTML; Tabellen verwenden <th scope>; Formulare verwenden <label> |
| 1.3.2 | Sinnvolle Reihenfolge | A | Konform | DOM-Reihenfolge entspricht der visuellen Reihenfolge |
| 1.3.3 | Sensorische Eigenschaften | A | Konform | Anweisungen verlassen sich nicht allein auf Form, Größe oder Position |
| 1.3.4 | Ausrichtung | AA | Konform | Layout funktioniert hochkant und quer |
| 1.3.5 | Eingabezweck identifizieren | AA | Konform | Eingabefelder, die WCAG-Eingabezwecken entsprechen, nutzen autocomplete |
| 1.4.1 | Verwendung von Farbe | A | Konform | Farbe ist nie das einzige Signal — kombiniert mit Text oder Icons |
| 1.4.3 | Kontrast (Minimum) | AA | Konform | Fließtext ≥ 4,5:1, großer Text ≥ 3:1, intern geprüft |
| 1.4.4 | Textgröße ändern | AA | Konform | Layout reflowt bei 200 % Zoom ohne Inhaltsverlust |
| 1.4.5 | Textbilder | AA | Konform | Das Markenlogo ist das einzige Textbild; alle UI-Beschriftungen sind HTML |
| 1.4.10 | Reflow | AA | Konform | Reflowt bei 320 CSS-Pixeln Breite (Tabellen und Code-Blöcke wie zulässig ausgenommen) |
| 1.4.11 | Nicht-Text-Kontrast | AA | Konform | UI-Komponenten und grafische Objekte erreichen 3:1 |
| 1.4.12 | Textabstand | AA | Konform | Nutzerseitige Textabstands-Overrides brechen das Layout nicht |
| 1.4.13 | Inhalt bei Hover oder Fokus | AA | Konform | Tooltips sind verwerfbar (Escape), hoverbar und persistent, bis der Auslöser den Fokus verliert |
Prinzip 2 — Bedienbar
| SC | Titel | Stufe | Status | Hinweise |
|---|---|---|---|---|
| 2.1.1 | Tastatur | A | Konform | Alle Funktionen sind tastaturbedienbar |
| 2.1.2 | Keine Tastaturfalle | A | Konform | Modale Dialoge fangen den Fokus nur, solange sie geöffnet sind, und stellen ihn beim Schließen wieder her |
| 2.1.4 | Einzelzeichen-Tastenkürzel | A | Nicht anwendbar | Keine Einzelzeichen-Kürzel implementiert |
| 2.2.1 | Anpassbares Timing | A | Konform | Sitzungs-Inaktivitäts-Timeout beträgt 30 Tage und erfüllt die 20-Stunden-Ausnahme |
| 2.2.2 | Pausieren, Stoppen, Ausblenden | A | Konform | Keine sich automatisch aktualisierenden Inhalte bewegen oder blinken länger als 5 Sekunden ohne Steuerung zum Anhalten |
| 2.3.1 | Drei Blitze oder unterhalb | A | Konform | Keine blinkenden Inhalte |
| 2.4.1 | Blöcke umgehen | A | Konform | Skip-Link zum Hauptinhalt auf jedem Layout vorhanden |
| 2.4.2 | Seite betitelt | A | Konform | Jede Seite hat einen lokalisierten, beschreibenden <title> |
| 2.4.3 | Fokusreihenfolge | A | Konform | Fokus folgt der DOM-Reihenfolge |
| 2.4.4 | Linkzweck (im Kontext) | A | Konform | Linktexte beschreiben das Ziel |
| 2.4.5 | Mehrere Wege | AA | Konform | Sitesuche, Navigation und Breadcrumbs sind verfügbar |
| 2.4.6 | Überschriften und Beschriftungen | AA | Konform | Eine <h1> pro Seite; Überschriften steigen ohne Sprünge ab |
| 2.4.7 | Fokus sichtbar | AA | Konform | :focus-visible global aktiviert; Fokusringe werden nicht deaktiviert |
| 2.4.11 | Fokus nicht verdeckt (Minimum) | AA (neu in 2.2) | Konform | Fokussierte Elemente werden nicht vollständig von Sticky-Headern oder anderen Inhalten verdeckt |
| 2.5.1 | Zeigegesten | A | Konform | Keine Mehrfach- oder Pfadgesten erforderlich |
| 2.5.2 | Zeigerabbruch | A | Konform | Alle Klick-Aktionen schließen mit up-event ab |
| 2.5.3 | Beschriftung im Namen | A | Konform | Zugängliche Namen enthalten die sichtbare Beschriftung |
| 2.5.4 | Bewegungsauslöser | A | Nicht anwendbar | Keine Gerätebewegungs-Eingaben |
| 2.5.7 | Ziehbewegungen | AA (neu in 2.2) | Konform | Keine reinen Drag-Flows; Uploads akzeptieren Klick- und Tastaturalternativen |
| 2.5.8 | Zielgröße (Minimum) | AA (neu in 2.2) | Konform | Interaktive Ziele ≥ 24×24 CSS-Pixel |
Prinzip 3 — Verständlich
| SC | Titel | Stufe | Status | Hinweise |
|---|---|---|---|---|
| 3.1.1 | Sprache der Seite | A | Teilweise konform | Anwendungs- und Portalseiten setzen <html lang> auf das aktive Locale. Statische Fallback-Fehlerseiten sind nur in Englisch — siehe Erklärung zur Barrierefreiheit |
| 3.1.2 | Sprache von Teilen | AA | Konform | Eingebettete fremdsprachige Strings verwenden bei Bedarf lang-Attribute |
| 3.2.1 | Bei Fokus | A | Konform | Fokus löst keine Kontextänderung aus |
| 3.2.2 | Bei Eingabe | A | Konform | Eingabe löst ohne Vorwarnung keine Kontextänderung aus |
| 3.2.3 | Konsistente Navigation | AA | Konform | Navigationsreihenfolge ist anwendungsweit konsistent |
| 3.2.4 | Konsistente Kennzeichnung | AA | Konform | Icons und Komponenten werden konsistent verwendet |
| 3.2.6 | Konsistente Hilfe | A (neu in 2.2) | Konform | Support-Kontakt und Hilfelinks erscheinen auf jeder authentifizierten Seite an derselben Stelle (Sidebar-Footer) und im Portal-Footer |
| 3.3.1 | Fehleridentifikation | A | Konform | Fehler werden über role="alert" ausgegeben und der nutzenden Person beschrieben |
| 3.3.2 | Beschriftungen oder Anweisungen | A | Konform | Eingabefelder sind beschriftet; Hinweise verwenden aria-describedby |
| 3.3.3 | Fehlervorschlag | AA | Konform | Fehler sagen, was falsch ist und wie zu beheben |
| 3.3.4 | Fehlervermeidung (rechtlich, finanziell, Daten) | AA | Konform | Reversible Aktionen oder explizite Bestätigung bei destruktiven Aktionen |
| 3.3.7 | Redundante Eingabe | A (neu in 2.2) | Konform | Zuvor in derselben Sitzung eingegebene Informationen (E-Mail, Organisation) werden bei erneutem Bedarf vorausgefüllt |
| 3.3.8 | Zugängliche Authentifizierung (Minimum) | AA (neu in 2.2) | Konform | Authentifizierung erfolgt per Magic Link und Einmalcodes, die eingefügt werden können; keine kognitiven Funktionstests erforderlich |
Prinzip 4 — Robust
| SC | Titel | Stufe | Status | Hinweise |
|---|---|---|---|---|
| 4.1.2 | Name, Rolle, Wert | A | Konform | Bedienelemente legen Name, Rolle und Zustand offen |
| 4.1.3 | Statusmeldungen | AA | Konform | Flash-Meldungen, Benachrichtigungen und asynchrone Ergebnisse verwenden aria-live-Regionen |
§10 Nicht-Web-Dokumente #
| Klausel | Anforderung | Status | Hinweise |
|---|---|---|---|
| 10.1 | Nicht-Web-Dokumente (PDFs) | Nicht konform | Compliance-Berichte, Zertifikate, Richtlinienvorlagen, Poster, das Handbuch für Fallbearbeiter:innen und Fallexporte werden als nicht getaggte PDFs erstellt. Barrierefreie HTML-Alternativen sind auf Anfrage über accessibility@ethicsportal.eu verfügbar. Eine getaggte PDF-Pipeline ist in Planung. |
| 10.2 | DOCX-Richtlinienvorlagen | Teilweise konform | Generierte DOCX-Dateien (Hinweisgeberrichtlinie, Datenschutzhinweis) tragen ihre Struktur, sind aber nicht gegen PDF/UA-äquivalente Erwartungen für bearbeitbare Dokumente geprüft. HTML-Alternativen sind auf Anfrage verfügbar. |
§11 Software #
Die Webanwendung qualifiziert sich als Software nach §11. §11 umfasst WCAG (oben unter §9 bewertet) zuzüglich softwarespezifischer Klauseln:
| Klausel | Anforderung | Status | Hinweise |
|---|---|---|---|
| 11.5 | Interoperabilität mit assistiven Technologien | Konform | Auf semantischem HTML und ARIA aufgebaut; getestet mit VoiceOver, NVDA und plattformseitiger Tastaturnavigation |
| 11.6 | Dokumentierte Barrierefreiheits-Nutzung | Konform | Diese Seite und die Erklärung zur Barrierefreiheit dokumentieren Funktionen und bekannte Einschränkungen |
| 11.7 | Nutzerpräferenzen | Konform | OS-Präferenzen (reduzierte Bewegung, Farbschema, Textskalierung) werden berücksichtigt |
| 11.8 | Autorenwerkzeuge | Teilweise konform | Die Oberfläche für Fallbearbeiter:innen ist ein Autorenwerkzeug nach §11.8, da Bearbeiter:innen Inhalte erstellen, die Hinweisgeber:innen konsumieren. Datei-Uploads akzeptieren Beschreibungen; künftige Rich-Text-Funktionen werden gegen ATAG 2.0 bewertet |
§12 Dokumentation und Support-Dienste #
| Klausel | Anforderung | Status | Hinweise |
|---|---|---|---|
| 12.1.1 | Barrierefreiheits- und Kompatibilitätsmerkmale | Konform | Dieser Bericht und die Erklärung zur Barrierefreiheit beschreiben die unterstützten assistiven Technologien und Plattformkombinationen |
| 12.1.2 | Barrierefreie Dokumentation | Konform | Dokumentation wird als semantisches HTML auf der Marketing-Site und über die In-App-Hilfe ausgeliefert |
| 12.2.2 | Informationen zu Barrierefreiheits-Merkmalen | Konform | Support-Personal und die veröffentlichte Erklärung können Anfragen zur Barrierefreiheit beantworten |
| 12.2.3 | Effektive Kommunikation | Konform | Feedback-Kanal zur Barrierefreiheit wird an jedem Werktag überwacht; Bestätigung innerhalb von 2 Werktagen |
| 12.2.4 | Barrierefreie Dokumentation (Support) | Teilweise konform | Dokumente, die in Reaktion auf Support-Anfragen ausgeliefert werden, erben den Status der zugrunde liegenden Artefakte — PDFs sind gekennzeichnet; HTML-Alternativen sind verfügbar |
Bekannte Einschränkungen #
Die folgenden Punkte werden offen geführt, nicht versteckt:
- Nicht getaggte PDFs. Größte Lücke. Heute durch barrierefreie HTML-Alternativen auf Anfrage abgemildert; geplant ist der Ersatz durch eine getaggte PDF- oder HTML-Canonical-Pipeline.
- Statische Fehlerseiten nur in Englisch. Treten selten auf; dieselbe Information ist in der Anwendung in der Nutzersprache verfügbar.
- Drittanbieter-Einbettungen (Crisp, Stripe-Seiten) liegen außerhalb unserer direkten Kontrolle; Dokumentation der Anbieter zur Barrierefreiheit wird jährlich überprüft.
Testmethodik #
Die Selbstbewertung kombinierte:
- Automatisiert:
axe-core-capybaraläuft gegen die öffentlichen Meldeportal-Flows (Startseite, Einreichung, Nachverfolgung) in der CI übertest/system/portal_accessibility_system_test.rb; jede Verletzung lässt den Build fehlschlagen. Die Ausweitung der automatisierten Abdeckung auf die authentifizierten Fallbearbeitungs-Flows ist auf der Roadmap - Manuelle Tastaturtests über den Meldeflow, den Arbeitsablauf der Fallbearbeitung, die Kontoverwaltung und die Authentifizierung
- VoiceOver (macOS, Safari) und NVDA (Windows, Firefox) Screenreader-Durchläufe auf denselben Flows
- 200 % Zoom Reflow-Prüfung auf jedem Layout bei 1280×800
- Reduzierte Bewegung verifiziert durch Aktivierung der OS-Präferenz
- Farbenblindheits-Simulation mit Coblis
- Code-Review gegen den internen Engineering-Leitfaden zur Barrierefreiheit
Kontakt und Feedback #
Anliegen zur Barrierefreiheit, Anfragen nach alternativen Formaten und Beschaffungsfragen:
- accessibility@ethicsportal.eu — an jedem Werktag überwacht
- Siehe die Erklärung zur Barrierefreiheit für das vollständige Feedback- und Durchsetzungsverfahren
Normen und Referenzen #
- EN 301 549 V3.2.3
- EN 301 549 V3.2.1 (harmonisierte Fassung)
- Richtlinie (EU) 2016/2102
- Richtlinie (EU) 2019/882 — European Accessibility Act
- Durchführungsbeschluss (EU) 2018/1523
- WCAG 2.2 Level AA
- ATAG 2.0
Zuletzt aktualisiert: