Staatliches Gutachten zur digitalen Barrierefreiheit
ghpp.de
Nutzbarkeit mit unterschiedlichen Behinderungen
Blindheit Mit Hindernissen nutzbar
Mehrere Alternativtext-, Struktur- und Tastaturfehler beeinträchtigen Screenreader-Nutzung deutlich, machen die Seite aber nicht vollständig unbedienbar.
Sehbehinderung Mit Hindernissen nutzbar
Schlechter Fokuskontrast, unzureichende Nicht-Text-Kontraste und problematische Overlays erschweren Orientierung und Erkennung zentraler Funktionen.
Hörbehinderung Mit Hindernissen nutzbar
Inhalte sind überwiegend textbasiert nutzbar, aber es fehlen Gebärdensprache-Angebote und Erklärinhalte, was Barrieren bei komplexen Informationen schafft.
Motorische Behinderung Mit Hindernissen nutzbar
Viele wesentliche Elemente und Overlays sind mit Tastatur nur eingeschränkt oder gar nicht bedienbar, wodurch reine Tastaturnutzung stark behindert wird.
Lernbehinderung Mit Hindernissen nutzbar
Fehlende Leichte Sprache, unlogische Fokusreihenfolgen, schwer schließbare Overlays und uneindeutige Beschriftungen erschweren Verständnis und Orientierung.
Neurodivergenz Mit Hindernissen nutzbar
Unklare Fokusführung, ständig offene Overlays und unstrukturierte Filter- und Navigationskomponenten können Reizüberflutung und Desorientierung verursachen.
Hinweis: Diese Zusammenfassung mit generativer KI basiert auf den Informationen aus diesem Gutachten. Künstliche Intelligenz kann Inhalte nicht automatisch barrierefrei machen oder Prüfungen durchführen. Behinderungen sind komplex und mehrschichtig, weshalb diese Analysen nicht zutreffen müssen.
Technische Umgebung
- OS
- Windows 11
- Browser
- Chrome 135.0.7049.115 (Offizieller Build) (64-Bit)
- Screenreader
- NVDA
- Tools
- Color Contrast Analyser (CCA), PDF Accessibility Checker (PAC), Chrome web inspector, NVDA ScreenReader, HeadingsMap (Chrome), Landmark Navigation (Chrome)
-
https://ghpp.de/ Web-Angebot öffnen
-
https://ghpp.de/?s=Gesundheit
-
https://ghpp.de/projekte/
Prüfkriterien
Nicht bestanden
| Kriterium | Status | Notizen |
|---|---|---|
|
9.1.1.1 Nicht-Text-Inhalt – Dekorative Hintergrundgrafik |
nicht bestanden | Die dekorative Weltkarte ist zwar mit aria-hidden ausgezeichnet, aber der alt-Text enthält den Wert „World“. Dadurch kann sie von Screenreadern dennoch vorgelesen werden. Dekorative Bilder benötigen ein leeres alt-Attribut (alt="") und ggf. aria-hidden="true", damit sie vollständig ignoriert werden. |
|
9.1.1.1 Nicht-Text-Inhalt – Inkonsistente Alternativtexte |
nicht bestanden | Im Bereich „Aktuelle Projekte“ wurde das zweite, sachlich gleichwertige Bild ohne beschreibenden Alternativtext als dekorativ markiert. Beide Bilder müssen analog gekennzeichnet sein, damit die Informationen für assistive Technologien identisch zugänglich bleiben. |
|
9.1.1.1 Nicht-Text-Inhalt – Informationstragende Bilder als dekorativ ausgezeichnet |
nicht bestanden | Die Bilder im Bereich „Neues aus dem GHPP“ wurden mit alt="" oder aria-hidden="true" versehen, obwohl sie relevante Informationen enthalten. Diese Bilder benötigen aussagekräftige Alternativtexte, damit Screenreader-Nutzende den Kontext mitbekommen. |
|
9.1.1.1 Nicht-Text-Inhalt – Landkarte ohne ausreichenden Alternativtext |
nicht bestanden | Die Landkarte im Abschnitt „Start der Phase II“ trägt lediglich alt="Image" und vermittelt keinen lokalen Kontext. Der Alternativtext sollte die gezeigten Regionen oder markierten Orte beschreiben und ggf. durch weiterführende Beschreibungen ergänzt werden. |
|
9.1.1.1 Nicht-Text-Inhalt – Bild zur Phase I ohne Kontext |
nicht bestanden | Das Bild im Bereich „Bericht zur Phase I“ wurde mit alt="Image" gekennzeichnet. Da es den Bericht visuell stützt, ist es informationstragend. Ein beschreibender Alternativtext (z. B. „Titelseite des GHPP-Berichts zu Phase I“) stellt sicher, dass der Kontext auch non-visuelle Nutzende erreichen kann. |
|
9.1.1.1 Nicht-Text-Inhalt – Dekorative Trennlinie |
nicht bestanden | Die Trennlinie über „Aktuelle Projekte“ ist visuell ein reines Stilmittel, wird aber von Screenreadern angesprochen. Sie sollte für assistive Technologien ausgeblendet werden (z. B. aria-hidden="true" und alt=""), damit keine unnötigen Elemente in der Wahrnehmung verbleiben. |
|
9.1.1.1 Nicht-Text-Inhalt – Platzhaltergrafik mit sinnlosem Alternativtext |
nicht bestanden | Die Platzhaltergrafik im Slider („Neues aus dem GHPP“) nutzt alt="No Image", was für Screenreadernutzende keine nützliche Information liefert. Da es sich um ein dekoratives Element handelt, sollte sie ein leeres alt-Attribut (alt="") tragen und ggf. aria-hidden="true" erhalten. |
|
9.1.3.1 Info und Beziehungen – Einzelner Schalter in Liste |
nicht bestanden | Der Schalter „Link kopieren“ steht als einziges <li> ohne weiteren Listenkontext. Er sollte entweder außerhalb einer Liste in einem eigenständigen Container liegen oder gleichartige Funktionen in einer echten Liste gruppiert werden. Zudem fehlt ein Hinweis, welcher Link kopiert wird (data-copy-url=""), sodass die Funktion unklar bleibt. |
|
9.1.3.1 Info und Beziehungen – Suchfeldbeschriftung nicht verständlich |
nicht bestanden | Das Suchfeld ist mit dem Label „Search“ beschriftet, obwohl die Seite deutschsprachig ist. Der Labeltext sollte durch eine verständliche deutsche Formulierung ersetzt werden, z. B. „Suche“ oder „Suchbegriff eingeben“, damit alle Nutzenden die Funktion erkennen können. |
|
9.1.3.1 Info und Beziehungen – Benutzerdefiniertes Auswahlfeld ohne semantische Struktur |
nicht bestanden | Die Filterauswahl für Status, Region, Länder und Institute besteht aus Buttons und Checkboxen ohne Rolle wie combobox oder listbox, ohne aria-controls oder aria-haspopup, und das legend enthält weitere interaktive Elemente. Die Komponente muss semantisch korrekt mit zugänglichen Containern (role="listbox" / role="option" oder natives HTML) aufgebaut werden sowie aria-expanded-state und Gruppierung (role="group" oder Feldgruppe) bereitstellen. |
|
9.1.3.1 Info und Beziehungen – Zahlendarstellung nicht screenreader-kompatibel |
nicht bestanden | Das Projektbudget wird als „~ 700.000 EUR“ ausgegeben. Screenreader lesen die Punktnotation u. U. als Dezimalpunkt, was zu Missverständnissen führt. Zahlen sollten entweder ohne Punkte (700000 EUR) oder mit aria-hidden und separatem aria-label („siebenhunderttausend Euro“) dargestellt werden oder eine sprachliche Formulierung wie <span lang="de">ungefähr 700 000 Euro</span> nutzen. |
|
9.1.3.1 Info und Beziehungen – Paginierung ohne semantische Beschriftung |
nicht bestanden | Die Seitennavigation stellt sich lediglich als Zahlen dar („1“, „2“, „3“) ohne Hinweis auf den Kontext. Um Screenreader zu informieren, muss die Paginierung als Navigation (z. B. <nav aria-label="Seitennavigation">) markiert und die Links mit aria-labels ("Seite 1" etc.) oder sichtbaren Texten versehen werden. |
|
9.1.3.1 Info und Beziehungen – Suchergebnisse ohne Überschrift |
nicht bestanden | Über der Suchergebnisliste fehlt eine semantische Überschrift; die Anzahl der Ergebnisse steht ohne Kontext. Oberhalb der Liste ist eine Überschrift (z. B. <h2>Suchergebnisse</h2>) und ggf. ein ergänzender Satz zur Anzahl notwendig, damit assistive Technologien den Bereich erkennen. |
|
9.1.3.1 Info und Beziehungen – Mehrere Navigationsbereiche mit identischem aria-label |
nicht bestanden | Im Footer existieren mehrere Navigationselemente, die alle aria-label="Footer" tragen. Jede Region benötigt ein eindeutiges aria-label (z. B. "Footer – Servicelinks", "Footer – Rechtliches") oder visible Überschriften mit aria-labelledby, damit Screenreader die Bereiche unterscheiden können. |
|
9.1.3.2 Bedeutungsvolle Reihenfolge – Cookie-Dialog nicht am DOM-Anfang |
nicht bestanden | Der Cookie-Dialog erscheint visuell, ist im DOM jedoch erst nach weiteren Inhalten positioniert. Tastaturnutzende müssen dadurch erst durch vorherige Elemente tabben, bevor sie die Datenschutzeinstellungen erreichen. Der Dialog muss direkt nach <body> stehen oder der Fokus beim Laden automatisch (und barrierefrei) darauf gesetzt werden, damit die Reihenfolge stimmt. |
|
9.1.4.11 Nicht-Text-Kontrast – Button „Link kopieren“ |
nicht bestanden | Der Button „Link kopieren“ erreicht mit einem Kontrastverhältnis von 1,4:1 nicht die Mindestanforderung von 3:1 gegenüber dem weißen Hintergrund. Der Kontrast von Text- oder Icons auf Hintergrund muss erhöht werden, damit die Schaltfläche für sehbehinderte Menschen erkennbar ist. |
|
9.1.4.13 Eingeblendeter Inhalt – Such-Overlay lässt sich nicht schließen |
nicht bestanden | Nach dem Öffnen der Suche bleibt das Overlay dauerhaft sichtbar und lässt sich weder über einen Schließen-Button noch durch erneut klicken schließen. Eine schließbare Funktion (sichtbar und per Tastatur erreichbar, z. B. Schließen-Schaltfläche oder erneuter Klick auf „Suche“) mit role/aria-Label ist erforderlich, damit Nutzer nicht im Overlay gefangen sind. |
|
9.1.4.13 Eingeblendeter Inhalt – Sprachmenü kann nicht geschlossen werden |
nicht bestanden | Das Sprachmenü bleibt nach Aktivierung dauerhaft sichtbar und lässt sich weder über den Dropdown-Button noch ESC schließen. Eine klare Schließmöglichkeit (ESC, Button oder erneutes Aktivieren) plus richtige aria-expanded-Werte sind erforderlich, damit das Menü den Fokusfluss nicht blockiert. |
|
9.1.4.13 Eingeblendeter Inhalt – Ausklappliste schließt nicht bei Fokusverlust |
nicht bestanden | Filterlisten öffnen sich beim Fokussieren und verbleiben offen, ohne dass sie ohne durchlaufen aller Optionen geschlossen werden können. Die Listen müssen über Enter/Pfeiltasten/ESC oder Fokuswechsel schließbar sein und den Status über aria-expanded vermitteln, damit Tastaturbedienung möglich bleibt. |
|
9.1.4.13 Eingeblendeter Inhalt – Sortiermenü öffnet sich bei Fokus |
nicht bestanden | Das Sortiermenü öffnet sich allein beim Fokussieren und kann nicht ohne Auswahl geschlossen werden. Es darf nur durch aktive Aktion (Enter/Leertaste) geöffnet werden, muss per ESC oder erneutes Aktivieren schließbar bleiben und aria-expanded muss den Zustand kommunizieren. Optional sollte ein überspringbares Verhalten (Tab) möglich sein. |
|
9.2.1.1 Tastatur – Registerkarten nicht tastaturfähig |
nicht bestanden | Die Registerkarten „Liste“ und „Karte“ sind zwar fokussierbar, aber nicht per Eingabetaste oder Pfeiltasten auswählbar. Außerdem gibt es keine aria-selected/aria-controls-Verknüpfung. Aktivierung per Enter/Leertaste, Pfeiltasten-Navigation sowie Kennzeichnung mit aria-selected und role="tabpanel" ist notwendig. |
|
9.2.1.1 Tastatur – Sortiermenü ohne semantische Rollen |
nicht bestanden | Das benutzerdefinierte Sortiermenü nutzt ein Button-Element ohne aria-haspopup oder aria-expanded, keine role="listbox"/role="option" und keine Tastatursteuerung. Die Komponente muss gemäß BFIT-Handreichung (Tab fängt Liste, Enter/Leertaste öffnet, Pfeiltasten wählen, ESC schließt) mit aria-activedescendant, aria-expanded und proper roles umgesetzt werden. |
|
9.2.1.1 Tastatur – Schaltfläche in Projektkarte nicht fokussierbar |
nicht bestanden | Das Element „Weitere Informationen“ ist ein <span> mit onclick und kein fokussierbares HTML-Element. Ohne <button> bzw. <a> kann die Aktion nicht per Tastatur ausgelöst werden. Der Span muss durch ein semantisch korrektes Steuerelement ersetzt werden (z. B. <button> oder <a>). |
|
9.2.1.1 Tastatur – Ausklappliste ohne Enter-Auswahl |
nicht bestanden | Die Werte in der Filterliste lassen sich zwar per Tab ansteuern, jedoch nicht per Enter auswählen. Alle interaktiven Einträge müssen per Enter/Leertaste auswählbar sein, ebenso Navigation mit Pfeiltasten, Fokusmanagement über aria-selected/aria-activedescendant und ESC zum Schließen. |
|
9.2.4.3 Fokus-Reihenfolge – Fokus springt auf unsichtbares Overlay nach Hauptmenü |
nicht bestanden | Nach dem Hauptmenü wandert der Fokus unerwartet auf ein unsichtbares Such-Overlay und beinhaltet Eingabefelder, bevor die Suche aktiviert wurde. Diese Elemente sollten erst nach expliziter Aktivierung in die Tab-Reihenfolge gelangen (z. B. mit tabindex="-1"/aria-hidden), da sonst Tastaturnutzende verwirrt werden. |
|
9.2.4.3 Fokus-Reihenfolge – Kein Fokuswechsel beim Öffnen des Sprachmenüs |
nicht bestanden | Beim Öffnen des Sprachumschalters verbleibt der Fokus auf dem Button statt auf dem ersten Menüeintrag. Der Fokus muss programmgesteuert auf das erste auswählbare Element gesetzt werden, um die Erwartung an eine logische Fokusfolge zu erfüllen. |
|
9.2.4.3 Fokus-Reihenfolge – Unsichtbare Slider-Inhalte fokussierbar |
nicht bestanden | In den Sliderbereichen (Aktuelle Projekte, Neues aus dem GHPP) durchläuft der Fokus alle nicht sichtbaren Slides. Inaktive Slides müssen mit aria-hidden="true" sowie tabindex="-1" (oder aus DOM entfernt) versehen sein, wodurch nur sichtbare Inhalte fokussierbar bleiben. |
|
9.2.4.3 Fokus-Reihenfolge – Slider-Steuerelemente hinter Inhalten |
nicht bestanden | Die Vor- und Zurück-Schaltflächen liegen im DOM nach den Slide-Inhalten, sodass Tastaturnutzende erst alle Inhalte durchlaufen müssen, bevor sie steuern können. Platzieren Sie diese Steuerungselemente vor oder oberhalb der Inhalte bzw. bieten Sie einen Skip-Link an, damit sie früh erreichbar sind. |
|
9.2.4.3 Fokus-Reihenfolge – Fokus wird nach Aktionen an den Seitenanfang gesetzt |
nicht bestanden | Bei Aktionen wie Suche oder Pagination springt der Fokus automatisch an den Seitenanfang zurück, sodass Tastaturnutzende ihre Position verlieren. Nach einer Aktion sollte der Fokus gezielt auf eine sinnvolle Stelle gesetzt werden (z. B. Überschrift „XX Beiträge“ oder erstes Ergebnis). |
|
9.2.4.4 Linkzweck – Nicht-Text-Inhalte ohne aussagekräftige Alternativtexte im Bereich Fachinstitute |
nicht bestanden | Die verlinkten Cards der Fachinstitute nutzen identische Alternativtexte wie die Überschrift, wodurch der Linkzweck nicht erkennbar ist. Entweder als dekorativ markieren oder den alt-Text um den Linkzweck ergänzen (z. B. „Logo des Bernhard-Nocht-Instituts – zur Institutsseite“). |
|
9.2.4.7 Fokus sichtbar – Fokusrahmen mit geringem Kontrast |
nicht bestanden | Der mintgrüne Fokusrahmen hat zu wenig Kontrast zum Hintergrund und wird für sehbehinderte Nutzende kaum wahrgenommen. Der Fokuszustand muss klar sichtbar hervorgehoben werden (z. B. kontrastreiche Umrandung, Schatten oder Hintergrundfarbe) und möglichst mindestens 3:1 Kontrast zu angrenzenden Farben bieten. |
|
9.2.5.3 Beschriftung (Label) im Namen – Cookie-Switches ohne Statusübermittlung |
nicht bestanden | Die Schalter im Cookie-Dialog (z. B. für Statistiken, Externe Medien) haben zwar Labels, diese sind aber nicht korrekt mit den Eingabeelementen verknüpft und der Zustand (an/aus) wird nicht programmgesteuert übermittelt. Labels müssen mit for/id bzw. aria-labelledby verbunden und aria-checked oder aria-pressed genutzt werden, damit der Status assistiven Technologien mitgeteilt wird. |
|
9.3.1.2 Sprache von Teilen – Skip-Link nicht ausgezeichnet |
nicht bestanden | Der sichtbare Skip-Link trägt den englischen Text „Skip to main content“, obwohl sich die Seite im Deutschen befindet. Entweder den Text ins Deutsche übersetzen oder das passende lang-Attribut (z. B. lang="en") verwenden, damit Screenreader die Aussprache korrekt interpretieren. |
|
9.4.1.2 Name, Rolle, Wert – Sprachschalter unzureichend benannt |
nicht bestanden | Der Sprachschalter zeigt nur „DE“ und liefert keinen beschreibbaren Accessible Name. Ergänzen Sie ein aussagekräftiges aria-label, z. B. aria-label="Sprache auswählen: Deutsch", oder fügen Sie für Screenreader sichtbaren Text hinzu, damit die Funktion verständlich ist. |
|
Zusatzkriterien Deutsche Gebärdensprache / Leichte Sprache / Barrierefreiheitserklärung Zusatzkriterien – Inhalte in Deutscher Gebärdensprache, Leichter Sprache und formale Erklärung fehlen |
nicht bestanden | Links oder Inhalte zu deutschen Gebärdensprachvideos, Leichter Sprache, Erläuterungen zur Barrierefreiheit etc. fehlen komplett (Nicht Vorhanden #1). Die notwendigen Zugangswege und Erklärungen zu den wesentlichen Inhalten, Navigation und zur Erklärung zur Barrierefreiheit müssen bereitgestellt und verlinkt werden. |
Unterstützung
Barrieren sichtbar machen kostet Geld. Hilf uns, dranzubleiben.
BarrierenWatch wird ehrenamtlich betrieben und finanziert sich über Steady-Mitgliedschaften von Menschen wie dir, die Barrierefreiheit und Inklusion voranbringen möchten.
ab
5
Euro
im Monat
für Recherche, Prüfungen und den Betrieb der Plattform.