Hintergründe

Seit Anfang der 1990er Jahre waren erste Bestrebungen, Dinge im Internet zu standardisieren, aufgekommen und seit 1994 vor allem durch das World Wide Web Consortium, besser bekannt als W3C-Konsortium, vorangetrieben worden, das technische Spezifikationen und Richtlinien erarbeitet und transparent macht. Standardisierte Technologien sind etwa HTML oder auch die Web Content Accessibility Guidelines, kurz WCAG.

WCAG 1.0

Die zum W3C-Konsortium gehörende Web Accessibility Initiative (WAI) hat eine Empfehlungssammlung erstellt, die 1999 herausgegeben wurde. Diese enthält rund 60 Einzelpunkte in drei verschiedenen Prioritäten (A, AA, AAA) in 14 Kategorien, die eine Internetseite erfüllen soll. Die einzelnen Kategorien konzentrieren sich sehr auf die technischen Aspekte, insb. HTML und CSS, ansonsten bleiben die WCAG 1.0 aber recht unverbindlich, was die Umsetzung der Punkte und die spätere Validierung angeht.

WCAG 2.0

Die WCAG 2.0 haben am 11. Dezember 2008 Empfehlungsstatus erhalten. Im Gegensatz zu den WCAG 1.0 konzentrieren sie sich nicht mehr auf HTML und CSS als wichtigste Standards des Internets, sondern beschreiben allgemeiner, wie Layouts, Interaktionen u. a. gestaltet sein müssen, damit das Angebot barrierefrei ist. Die Umsetzung dieser Richtlinien für die einzelnen Technologien wie HTML, Java, Flash oder PDF obliegt den jeweils verantwortlichen Institutionen bzw. Unternehmen. Damit bleiben die WCAG offen für die raschen technologischen Entwicklungen des Internets und neue Techniken lassen sich integrieren. Im Juni 2018 wurden die WCAG 2.1 als W3C Standard verabschiedet, die sich v.a. mit Sehbehinderungen und kognitive Beeinträchtigungen sowie mobiler Nutzung beschäftigen. [https://www.w3.org/TR/WCAG21/ https://www.w3.org/Translations/WCAG20-de/]

Der WCAG-Test ist ein Testverfahren zur Prüfung der Zugänglichkeit von Webangeboten. Er wurde im Rahmen der vom Bundesministerium für Arbeit und Soziales geförderten Projektreihe „BIK – barrierefrei informieren und kommunizieren“ entwickelt und macht die Anforderungen der WCAG handhabbar, allerdings ist dieser Test in Bezug auf ein Lernmanagementsystem im Unterschied zu einer Webseite nicht sinnvoll.

Tests von Stud.IP auf Barrierefreiheit

Aufgrund dieser Feststellung hat der Arbeitskreis Barrierefreiheit mithilfe des Stud.IP e.V. eine Überprüfung einer Stud.IP-4.6 und einer Stud.IP-5.0-Installation von einer u.a. auf Überprüfung von Lernmanagementsystemen spezialisierten Agentur durchführen lassen und anhand der ausführlichen Berichte einen Maßnahmenkatalog erstellt, um Stud.IP barriereärmer zu machen und zwar mit einem sog. BITV-Test. Geprüft wurde die 4.6er-Installation nach den 60 Prüfschritten, die sich aus 50 Anforderungen der WCAG 2.1 (Konformitäten A und AA) ergeben. Geprüft wurde nach den vier Prinzipien der WCAG 2.1. Diesen sind 13 Richtlinien zugeordnet, welche die Grundziele für die Erstellung barrierefreier Webinhalte bilden.

• Wahrnehmbarkeit

Dazu gehören z.B. ob es Text-Alternativen gibt, ob Dinge anpassbar und unterscheidbar sind.

• Bedienbarkeit

Es wird getestet, ob das System mit Tastatur bedienbar ist und wie gut die Navigierbarkeit und Eingabemodalitäten sind.

• Verständlichkeit

Hierbei spielt eine Rolle, ob Texte lesbar sind, die Bedienung intuitiv funktioniert und ob es z.B. Eingabehilfen gibt.

• Robustheit

WCAG-Prinzip: „Inhalte müssen robust genug sein, damit sie zuverlässig von einer großen Auswahl an Benutzeragenten einschließlich assistierender Techniken interpretiert werden können.“ Unter diesen Punkt fällt auch die Analyse auf korrekte Syntax. Die Prüfschritte haben sich 2021 auf 85 und 2022 sogar auf 98 erhöht.

Gesetzliche Vorgaben

Auf die WCAG haben Staatenverbünde wie die EU, Staaten und Bundesländer reagiert und verschiedene Gesetze erlassen, die die Guidelines umsetzen sollen. Vorab sei zur besseren Einordnung bemerkt, dass jedes nationale Gesetz, das einer EU-Verordnung widerspricht, sofort wirkungslos ist. Denn eine europäische Verordnung wird mit ihrer Verkündung automatisch zum Bestandteil der nationalen Rechtsordnungen und muss nicht noch erst von den einzelnen EU-Mitgliedstaaten in nationales Recht umgesetzt werden. Eine europäische Richtlinie dagegen kommt erst nach einer im Gesetzestext festgelegten Frist zum Zuge. Vor dieser sich mitunter hinziehenden Verankerung in der bundesdeutschen Gesetzgebung sind die in einer europäischen Richtlinie festgelegten Ziele noch nicht für die hiesigen Behörden rechtlich verbindlich. Wobei hier die Form und die Mittel der Umsetzung dem jeweiligen Mitgliedsland sowieso selbst überlassen bleiben, so dass es in konkreten Fällen immer zu unterschiedlichen Gerichtsentscheidungen auf nationaler und europäischer Ebene kommen kann und wird. Die barrierefreie-Informationstechnik-Verordnung (BITV), die auf den WCAG 1.0 fußt und 2002 in der BRD erstmals in Kraft getreten ist, soll nach § 1 eine umfassend und grundsätzlich uneingeschränkt barrierefreie Gestaltung moderner Informations- und Kommunikationstechnik gewährleisten und gilt daher für

• Webseiten
• mobile Anwendungen (Apps)
• elektronisch unterstützte Verwaltungsabläufe und
• grafische Programmoberflächen des Bundes.

Auch die Bundesländer der BRD haben darauf fußend entsprechende Gesetze erlassen, wie zum Beispiel Niedersachsen: Das NBGG, das Niedersächsische Behindertengleichstellungsgesetz (25.11.2007; Fassung vom 25.10.2018, gültig ab 02.11.2018) hat folgende wichtigste Inhalte:

• (§ 9 a) öffentliche Stellen müssen ihre Webseiten und mobilen Anwendungen barrierefrei gestalten
• (§ 9b) öffentliche Einrichtungen müssen eine Erklärung zur Barrierefreiheit veröffentlichen, die auch Stellen benennt, die ausnahmsweise nicht barrierefrei sind und Alternativen dazu
• die einen Hinweis auf Durchsetzungsverfahren und Verlinkung zu Schlichtungsstellen enthält

Neue Gesetzeslage und Rahmenbedingungen

Seit dem 26.10.2016 ist die EU-Richtlinie 2016/2012 des europäischen Parlaments und Rats über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen in Kraft, die sich an die Mitgliedstaaten richtet. Diese müssen die Richtlinie in nationales Recht überführen. Durch das Inkrafttreten der EU-Richtlinie und der sog. Harmonisierung in den Mitgliedstaaten haben die Diskussion und auch die Handlungen im Sinne der Barrierefreiheit sowohl auf Bundes- als auch auf Landesebene neue Fahrt aufgenommen. Die BITV 2.0 (in Kraft getreten am 25. Mai 2019) setzt die EU-Richtlinie 2016/2012 konkret um, die nicht schon 2018 im aktualisierten Behindertengleichstellungsgesetz (BGG) umgesetzt wurden. Die BITV 2.0 wurde seit 2007 in einer Arbeitsgruppe aus Vertretern von Behindertenverbänden, des Bundesministeriums für Arbeit und Soziales, des Bundesverwaltungsamtes sowie aus Forschung und Technik erarbeitet. Die neue Gesetzeslage hat veränderte Rahmenbedingungen zufolge: Es existieren seit einiger Zeit Überwachungsstellen für barrierefreies Internet; Beispiel Niedersachsen (nach § 9c NBGG) Dazu muss man sagen, dass die Politik zögerlich auf die Gesetzeslage reagiert hat. Außerdem sind einige der Überwachungsstellen tatsächlich schlecht im Netz zu finden.

Die Überwachungsstellen haben folgende Aufgaben:

• periodische Überwachung, ob und inwiefern die Angebote öffentlicher Stellen der Barrierefreiheit genügen
• Feststellung von Mängelbeseitigung
• Beratung, Schulung, Sensibilisierungsprogramme
• Erstellen eines Berichtes (u.a. für den Landtag)
• Unterstützung der sog. Schlichtungsstelle Die Schlichtungsstelle ist bei der oder dem Landesbeauftragten für Menschen mit Behinderungen eingerichtet. Diese ist für das sog. Durchsetzungsverfahren (nach Art. 9 der EU-Richtlinie 2016/2012) zuständig. Die Schlichtungsstelle muss:
• unabhängig und unparteiisch handeln
• Verfahrensregeln transparent handhaben/offenlegen
• Beteiligten des Schlichtungsverfahrens rechtliches Gehör verschaffen
• Vertraulichkeit gewährleisten
• barrierefreie Kommunikation sicherstellen
• und kann die Überprüfung einzelner öffentlicher Stellen durch die Überwachungsstelle verlangen

Was bedeutet das für Stud.IP und deren Betreiber:innen?

Universitäten als Körperschaften öffentlichen Rechts und auch Verbände/Vereine gelten meist als öffentliche Einrichtungen, daher unterliegen sie der jeweiligen Bundes- oder Landesrechtsprechung und müssen daher entsprechende Anwendungen barrierefrei gestalten. Sie müssen über den Stand der Barrierefreiheit berichten und Feedbackprozesse etablieren, was auch Stud.IP und andere LMSe betrifft. Dazu gehören:

1. eine Erklärung, die auf Webseiten eingebunden ist und Ansprechpartner benennt und über den Stand der Barrierefreiheit Auskunft gibt, (https://gitlab.studip.de/studip/studip/-/wikis/Barrierefreiheit#erkl%C3%A4rung-zur-barrierefreiheit-der-websiteapp-und-feedbackmechanismus)
2. ein technischer Feedback-Mechanismus, der es erlaubt Rückmeldung über Barrieren zu geben, und zwar direkt an den Objekten bzw. auf der Seite, die Barrieren darstellen (https://gitlab.studip.de/studip/studip/-/wikis/Barrierefreiheit#erkl%C3%A4rung-zur-barrierefreiheit-der-websiteapp-und-feedbackmechanismus)
3. Personenstellen, die sich um den Abbau von Barrieren kümmern. Die Durchsetzungsstellen haben in Bayern bei den HSen direkt nach dem Stand der Barrierefreiheit nachgefragt. Von vielen wird gewünscht, die LMSe zu zertifizieren, damit man dieses Zertifikat bei den Stellen einreichen kann. Die Software an sich kann man jedoch nicht zertifizieren, da man sie nicht getrennt vom Inhalt, den u.a. viele Lehrende einstellen, betrachten kann. Zu den ersten beiden Punkten ist bereits Abhilfe geschaffen worden. Die Möglichkeit, Barrieren von überall aus dem System melden zu können, ist bereits gegeben und seit 2021 als Plugin verfügbar (läuft ab Stud.IP 4.4). Die Inhalte und Kontaktdaten müssen vom jeweiligen Standort hinterlegt werden.

Daraus folgt weiterhin, dass:

• die öffentlichen Stellen befürchten müssen, dass sich Beschwerden häufen und Bugfixing/Verbesserungsbedarf an Plugins und dem Kern entstehen und somit ein erhöhter Zeit-/Personalbedarf entsteht
• sie direkt von den Überwachungsstellen überwacht werden können
• dass zu wenige Mitarbeiter:innen ins Thema eingearbeitet sind und Zeit für Einarbeitung/Weiterqualifikation einzuplanen ist
• wenn es zu einem Durchsetzungs- oder sogar Schlichtungsverfahren kommt, die öffentliche Stelle verpflichtet ist, diese zu unterstützen.

Umsetzungsprojekt Stud.IP barriereärmer machen

Der oben bereits erwähnte Maßnahmenkatalog wurde von sieben Hochschulen querfinanziert und einzelne Arbeitspakete in Auftrag gegeben. Bei data-quest ist darauf ein Umsetzungsprojekt entstanden, das von September 2021 bis April 2023 läuft. Ein Ergebnis ist die Dokumentation und Guidelines, wie man in Zukunft barriereärmer programmieren sollte.

Sicherstellung der Barrierearmut von neuem Programmcode

Wie in Open Source-Projekten üblich, programmieren auch bei Stud.IP viele verschiedene Personen von verschiedensten Standorten an der Software und erweitern/modernisieren sie nicht nur durch Plugins, sondern auch durch neuen Code im Kern. Das stellt natürlich eine Herausforderung dar, wenn es darum geht, die Qualität der veröffentlichten Software zu gewährleisten und unter verschiedensten Kriterien zu überprüfen. Das Projekt hat jedoch einen merkbaren Einfluss auf das Bewusstsein und die Motivation der Entwickelnden zum Thema Barrierefreiheit genommen und so schon zu barriereärmeren Programmcode geführt. Die Community hat mit völliger Offenheit auf das Thema reagiert, neue Arbeitspakete werden nun immer auch von Anfang an unter dem Aspekt der Barrierefreiheit betrachtet. Das zentrale Gremium, das entscheidet, welche Arbeiten am Stud.IP-Code in neue Versionen aufgenommen werden und welchen Kriterien diese genügen müssen, ist die Coregroup. Hier wurde im Jahr 2022 eine neue Zuständigkeit zum Bereich „Barrierefreiheit“ geschaffen, die nicht nur als Anlaufstelle zu Fragen rund um barrierefreie Programmierung dient, sondern auch jeglichen Code, der in den Stud.IP-Kern eingebaut werden soll, auf barrierefreie Gestaltung und Bedienung überprüft und ggf. ein Veto gegen den Einbau einlegen darf. Damit wird sichergestellt, dass die im Umsetzungsprojekt vorgenommenen Änderungen nicht nur dokumentarisch erhalten bleiben, sondern der Programmcode von Stud.IP auch zukünftig nachhaltig unter dem Aspekt der Barrierefreiheit weiterentwickelt wird.

Barriereärmer programmieren

Die Dokumentation, was bereits umgesetzt worden ist und worauf Programmierer:innen in Zukunft achten sollten, um barrierearmen Code zu erstellen, lesen Sie hier.