Erklärung zur Barrierefreiheit

Diese Seite beschreibt, wie gut sich git.nrw mit Hilfsmitteln und ohne Maus nutzen lässt, welche Barrieren wir kennen und wie Sie uns eine Barriere melden. Wir folgen dabei dem Behindertengleichstellungsgesetz NRW (BGG NRW, § 10b) und der Verordnung zur Schaffung barrierefreier Informationstechnik (BITV NRW, §§ 4 und 5). Beide setzen die Richtlinie (EU) 2016/2102 um. Die Gliederung folgt der Mustererklärung der EU (Durchführungsbeschluss (EU) 2018/1523).

Für eine Meldung brauchen Sie kein GitLab-Konto. Barriere melden

Geltungsbereich

Diese Erklärung gilt für die öffentliche Website git.nrw in deutscher und englischer Sprache. Dazu gehören Startseite, Kurse und Lektionen, Dokumentation, FAQ, Neuigkeiten, Anwendungsfälle, Einstufungsquiz, Profilseite und Kontaktformular. Sie gilt auch für das Werkzeug zum Erstellen von Kursbildern unter /tools/thumbnail-generator/, das Autorinnen und Autoren von Kursen im Browser nutzen.

Nicht Teil dieser Erklärung sind:

  • Der GitLab-Dienst unter gitlab.git.nrw, auch die Anmeldung über die Hochschulen. Was wir über seine Barrierefreiheit wissen, steht im Abschnitt GitLab-Dienst.
  • Angebote Dritter, auf die wir verlinken oder die wir einbetten, zum Beispiel der Community-Chat, die Mailingliste und Video-Player externer Anbieter. Kurse anderer Anbieter sind auf ihrer Kursseite als solche gekennzeichnet.

Verantwortliche Stelle

Herausgeberin der Website ist die RWTH Aachen University. Inhaltlich verantwortlich ist das Projektkonsortium git.nrw, vertreten durch das IT Center der RWTH Aachen University, Seffenter Weg 23, 52074 Aachen. Im Impressum stehen die vollständigen Angaben.

Stand der Vereinbarkeit

Die Website git.nrw ist teilweise barrierefrei. Sie erfüllt die Anforderungen der harmonisierten Norm EN 301 549 und der BITV NRW nicht vollständig. Bei unseren Prüfungen haben wir Barrieren auf den Stufen A und AA der Web Content Accessibility Guidelines (WCAG) gefunden. Die Bereiche, in denen sie auftreten, stehen im nächsten Abschnitt.

Die Liste ist nicht abschließend. Automatische Prüfungen finden nur einen Teil der Barrieren, und einige Bereiche sind nicht bewertet.

Der Grund für die Barrieren ist, dass die Anforderungen dort nicht umgesetzt sind. Auf eine unverhältnismäßige Belastung berufen wir uns nicht.

Bekannte Barrieren und Alternativen

Die Liste nennt die Art der Barrieren je Bereich, nicht einzelne Fehler. Wo es eine Alternative gibt, steht sie dabei. Wir nennen keine Termine für Änderungen.

Kurse und Videos

  • Lernvideos von anderen Anbietern, die auf git.nrw eingebunden sind, haben zum Teil nur automatische oder unvollständige Untertitel.

Unter jedem eingebetteten Video anderer Anbieter steht, ob es Untertitel hat und ob sie automatisch erzeugt sind. Zusammenfassung und Lernziele der Videokurse stehen als Text auf der Kursseite. Sie ersetzen das Video nicht.

Werkzeug für Kursbilder

  • Das Layout des Werkzeugs passt sich nicht an schmale Bildschirme und starke Vergrößerung an.

Das Werkzeug brauchen nur Autorinnen und Autoren von Kursen. Kursbilder lassen sich auch aus einer Einstellungsdatei mit bun run thumbnail erzeugen.

GitLab-Dienst

Den GitLab-Dienst unter gitlab.git.nrw betreibt das Projektkonsortium git.nrw. Die Software entwickelt die Firma GitLab Inc. Wir halten den Dienst auf der neuesten Version von GitLab. Eine eigene Bewertung seiner Barrierefreiheit haben wir nicht vorgenommen.

GitLab Inc. lässt die Software von Deque Systems prüfen und veröffentlicht das Ergebnis als Accessibility Conformance Report nach WCAG und EN 301 549. Der Bericht gilt jeweils für die Version, die bei seiner Erstellung die neueste war. Er nennt Barrieren auf den Stufen A und AA, vor allem diese:

  • Bedienelemente, Überschriften, Listen und Tabellen sind oft nicht so ausgezeichnet, dass Screenreader ihre Rolle, ihren Namen oder ihren Zustand erkennen. Statusmeldungen werden oft nicht angesagt.
  • Die Reihenfolge beim Bedienen mit der Tastatur ist auf vielen Seiten nicht logisch. Einige Funktionen lassen sich nicht mit der Tastatur bedienen, in einigen Formularen bleibt der Fokus hängen, und nicht jedes Element zeigt den Fokus an.
  • Farbe ist oft das einzige Merkmal für einen Zustand, zum Beispiel bei Pipelines und Jobs. Kontraste von Text, Rahmen und Fokusanzeigen sind teils zu gering.
  • Inhalte, die beim Überfahren mit der Maus oder beim Fokus erscheinen, lassen sich oft nicht schließen oder verschwinden zu früh.
  • Bei 200 Prozent Vergrößerung, 320 Pixeln Breite oder größeren Textabständen gehen auf einigen Seiten Inhalte verloren.
  • Bilder und Diagramme, zum Beispiel in Auswertungen, haben teils keine Textalternative.

Accessibility Conformance Report von GitLab (Englisch)

Inhalte in Projekten, zum Beispiel READMEs, Wikis und Tickets, erstellen die Nutzenden selbst. Wie das barrierefrei gelingt, beschreibt die Seite Barrierefreie Inhalte in GitLab. Barrieren auf gitlab.git.nrw können Sie über dasselbe Kontaktformular melden wie Barrieren auf dieser Website. Wir prüfen dann, ob wir sie als Betreiber beheben können, und geben sie sonst an GitLab Inc. weiter.

Nicht bewertete Bereiche

  • Eine eigene Prüfung des GitLab-Dienstes. Es gilt der Bericht von GitLab Inc., wie im Abschnitt GitLab-Dienst beschrieben.
  • Die Bedienung der eingebetteten Video-Player und die Frage, ob die Videos eine Audiodeskription brauchen. Die Untertitel haben wir nur stichprobenartig gelesen.
  • Textalternativen in allen Screenshots, Diagrammen, verlinkten Downloads und externen Lernmaterialien.
  • Nutzung mit Screenreadern, mit 200 und 400 Prozent Vergrößerung in allen Zuständen und durch Menschen mit Behinderungen. Eine unabhängige Prüfung durch Dritte hat nicht stattgefunden.

Erläuterungen in Leichter Sprache und in Deutscher Gebärdensprache bieten wir nicht an.

Erstellung dieser Erklärung

Diese Erklärung wurde am 24. Oktober 2026 erstellt. Sie beruht auf einer Selbstbewertung des Projektteams, nicht auf einer Prüfung durch Dritte.

Die Bewertung stützt sich auf:

  • eine automatische Prüfung aller ausgelieferten Seiten mit axe-core in Chromium nach den Regeln der WCAG 2.0, 2.1 und 2.2 (Stufen A und AA),
  • eine manuelle Prüfung ausgewählter Seiten und Abläufe mit der Tastatur, darunter Kontaktformular, FAQ, Dialoge, Quiz, Suche und das Menü auf Mobilgeräten,
  • eine Prüfung ausgewählter Seiten bei 320 Pixeln Breite und des mobilen Menüs bei 390 Pixeln Breite.

Wir überprüfen die Erklärung mindestens einmal im Jahr und außerdem, wenn wir einen Bereich beheben oder einen neuen ergänzen. Einzelne Mängel verfolgen wir als Tickets mit dem Label a11y im Projektarchiv.

Barriere melden oder Informationen anfordern

Haben Sie eine Barriere gefunden, können Sie Inhalte nicht nutzen oder möchten Sie Informationen in einer zugänglichen Form anfordern? Dann schreiben Sie uns über das Kontaktformular mit dem Thema „Barriere melden (Barrierefreiheit)“ und beschreiben Sie kurz, was passiert ist. Das Formular öffnet mit dem passenden Thema und fragt nach drei Dingen:

  • der Adresse der Seite,
  • was Sie tun wollten und was stattdessen passiert ist,
  • freiwillig, mit welchem Browser, Gerät und Hilfsmittel Sie unterwegs waren.

Sie brauchen kein GitLab-Konto und müssen sich nicht anmelden. Gesundheitsangaben brauchen wir nicht. Anhänge sind freiwillig. Die E-Mail-Adresse info@git.nrw aus dem Impressum erreicht das Projektkonsortium ebenfalls. Die Datenschutzerklärung gilt auch für das Formular.

Wir antworten Ihnen per E-Mail. Die BITV NRW sieht dafür in § 5 eine Frist von zwei bis höchstens sechs Wochen vor, je nach Größe der öffentlichen Stelle und Komplexität der Anfrage. Ist die Klärung bis dahin nicht abgeschlossen, erhalten Sie eine Zwischennachricht. Unsere Antwort verweist auf das Ombudsverfahren.

Beschwerde bei der Ombudsstelle

Sind Sie mit unserer Antwort nicht zufrieden oder bleibt sie aus, können Sie sich an die Ombudsstelle für barrierefreie Informationstechnik des Landes Nordrhein-Westfalen wenden. Sie ist der oder dem Beauftragten für die Belange der Menschen mit Behinderung zugeordnet (§ 10d BGG NRW, § 9 BITV NRW). Die Ombudsstelle versucht, die Umstände der fehlenden Barrierefreiheit zu klären, damit die öffentliche Stelle sie beheben kann.