1 Einleitung

Digitale Transformation wird häufig mit spektakulären Technologien, neuen Plattformen oder innovativen Geschäftsmodellen verknüpft, doch sie vollzieht sich ebenso in bereits etablierten, digitalen Angeboten wie wissenschaftlichen Online-Magazinen. Gerade hier werden grundlegende Fragen sichtbar: Sollte der freie Zugang zu wissenschaftlichen Publikationen bei Open Access nicht auch zugleich den barrierefreien Zugang inkludieren? Wie können Inhalte so gestaltet werden, dass sie für möglichst viele Menschen zugänglich sind? Das war die Leitfrage für unser Gestaltungsprojekt im Masterstudiengang Digitale Transformation der Informations- und Medienwirtschaft im Wintersemester 2025/26. Unsere Aufgabe war es, die Gestaltung des API Magazins so zu verändern, dass ein möglichst hoher Grad an digitaler Barrierefreiheit etabliert werden kann.

Das API Magazin der Hochschule für Angewandte Wissenschaften (HAW) Hamburg wird von einer Studierendenredaktion mit Unterstützung von Lehrenden und externen Praktiker*innen produziert und adressiert Themen rund um Informationen, Bibliotheken und Medien. Jede Ausgabe entsteht in wechselnden studentischen Projektkonstellationen, sodass das Magazin zugleich Publikationsmedium und Lernumgebung für die praktische Umsetzung digitaler Publikationsprozesse ist. Gegründet wurde das API Magazin im Wintersemester 2019/20 und hat seit diesem Zeitpunkt die Gestaltung der Website nicht wesentlich verändert. Bei der Produktion der Beiträge gab es im Verlauf der Jahre jedoch Veränderungen. Im Februar 2025 wurde eine Ausgabe veröffentlicht, die neben PDF-Dokumenten erstmalig auch alle Beiträge als HTML-Version darbot. Während diese Beiträge noch in getrennten Produktionsschritten hergestellt wurden, kommt für die aktuelle Ausgabe (Band 7.2) im Juli 2026 als Premiere das Single-Source-Publishing-Verfahren zum Einsatz, bei dem die Artikel aus einer gemeinsamen Ausgangsdatei im Markdown-Format produziert werden. Diese Ausgabe soll dann auch erstmalig überwiegend barrierefrei gestaltet sein.

2 Standards

Unmittelbar nach Projektbeginn haben wir als Erstes damit begonnen, die für das API Magazin relevanten rechtlichen und technischen Grundlagen zur Erfüllung der Barrierefreiheit zu recherchieren, die im folgenden Kapitel näher erläutert werden.

2.1 Rechtliche Rahmenbedingungen

Laut § 4 Behindertengleichstellungsgesetz (BGG)¹ ist Barrierefreiheit dann gegeben, wenn Bauwerke, Transportmöglichkeiten des öffentlichen Nahverkehrs, Alltagsgegenstände – wozu auch elektronische Güter wie Handys oder Laptops, aber auch Webseiten zählen - so konzipiert sind, dass diese von „Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind”. Nur wenn analoge und digitale Bereiche barrierefrei sind, können Menschen mit Behinderung uneingeschränkt am gesellschaftlichen und kulturellen Leben teilhaben. § 3 Hamburgische Gesetz zur Gleichstellung von Menschen mit Behinderung (HmBGG)² konkretisiert dabei Menschen mit Behinderung als Personen, bei welchen somatische, kognitiv-psychische oder in der sensomotorischen Wahrnehmung „[B]eeinträchtungen [vorliegen], welche sie in Wechselwirkung mit einstellungs- und umweltbedingten Barrieren, an der vollen, wirksamen und gleichberechtigten Teilhabe an der Gesellschaft hindern können” (HmBGG 2025: § 3).
Die Hochschule für Angewandte Wissenschaften Hamburg als öffentliche Hochschule bemüht sich mit konkreten Konzepten um ein inklusives Hochschulleben (Hochschule für Angewandte Wissenschaften Hamburg 2019). Knapp 8% von Studierenden der HAW Hamburg leiden an „Mobilitäts- oder Sinnesbeeinträchtigungen” und etwa 3% leiden unter einer “Teilleistungsstörung” (ebd.: 9), wie Legasthenie. Folglich fördert die Umsetzung barrierefreier Maßnahmen beim API Magazin, dessen primäre Zielgruppe Studierende sind, auch das inklusive und gleichberechtigte Miteinander an der eigenen Hochschule. Diese ist als öffentliche Einrichtung³ nach § 11 HmbBGG verpflichtet, u.a. Websites und mobile Anwendungen im Internet barrierefrei zu gestalten. Die Anforderungen an die digitale Barrierefreiheit sind konkret in der Verordnung barrierefreier Informationstechnik (BITV 2.0)⁴ festgelegt. Hamburg greift diese Verordnung in einer bundeslandspezifischen Version (HambBITVO)⁵ auf und verpflichtet hier seine öffentlichen Träger zur Barrierefreiheit. Die in § 1 HambBITVO definierten Standards entsprechen den internationalen Web Content Accessibility Guidelines (WCAG). Diese vom World Wide Web Consortium (W3C) verfassten Richtlinien sollen dabei helfen, digitale Inhalte mittels technischer Normen einheitlich zu gestalten.⁶ In aktueller Fassung liegen die WCAG 2.2 vor. Dabei beinhaltet diese Fassung sowohl die Kriterien der 2008 erschienenen Version 2.0 und der 2018 veröffentlichten Version 2.1. Beide Vorgängerversionen sind weiterhin ebenfalls gültig.⁷

Des Weiteren müssen nach § 2 HambBITVO eine jährlich zu aktualisierende Erklärung zur Barrierefreiheit in einem barrierefreien und maschinenlesbaren Format auf der Startseite der Homepage eingebunden werden, aus der detailliert hervorgeht, in welchem Umfang die Website barrierefrei gestaltet wurde.

2.2 Technische Anforderungen

Die WCAG definiert für die digitale Barrierefreiheit verschiedene Kriterien nach dem Vier-Säulen-Prinzip von „Wahrnehmbarkeit […] Bedienbarkeit […] Verständlichkeit […] [und] Robustheit”.⁸ Online-Inhalte sind demnach wahrnehmbar, wenn sie über mehr als ein Sinnesorgan aufgenommen werden können. Das heißt Abbildungen sollen einen Alternativtext beinhalten, damit assistive Technologien, wie beispielsweise Bildschirmlesegeräte, blinden oder sehbeeinträchtigten Personen den Bildinhalt vorlesen können.⁹ Zudem sollte der Farbunterschied zwischen Fließtext und Hintergrund so gewählt sein, dass sie klar voneinander unterscheidbar sind. Sind Videos auf Webseiten vorhanden, sollten diese mit Titelergänzungen angeboten werden, damit auch gehörlose Menschen die Informationen wahrnehmen. Das Prinzip der Bedienbarkeit liegt dann vor, wenn eine Steuerung nicht nur mit einer Maus oder dem Laptoptouchpad möglich ist, sondern auch die Tastatur als Bedienungsinstrument verwendbar ist. Verständlichkeit liegt dann vor, wenn die Informationen in sachlicher und eindeutiger Sprache vorliegen und Fachtermini erklärt werden. Ebenso sollte die Navigation eindeutig und übersichtlich sein. Webinhalte sind robust, wenn ein interoperabler Gebrauch von assistiven Technologien, beispielsweise Bildschirmlesegeräten möglich ist. Die in den WCAG festgehaltenen Kriterien gliedern sich wiederum in drei Ebenen, den sogenannten Konformitätsstufen A, AA und AAA. Stufe A beinhaltet das niedrigste Umsetzungsniveau, während Stufe AAA die höchsten Anforderungen an Barrierefreiheit beinhaltet.¹⁰ Im Rahmen des Projektes wurde eine Barrierefreiheit nach der gesetzlich vorgeschriebenen Konformitätsstufe AA angestrebt, die einem realistischen Qualitätsniveau für übliche Webinhalte entspricht.¹¹

3 Projektverlauf

Der Fokus des Gestaltungsprojekts lag von Beginn an in der Schaffung einer weitgehend barrierearmen und keiner vollständig barrierefreien Website, da dies aufgrund des Projektumfangs, der Gruppengröße sowie der verwendeten Zeitschriftensoftware keine realistische Zielsetzung darstellte. Gehostet wird das API Magazin durch den Verlag Hamburg University Press der Staats- und Universitätsbibliothek Hamburg Carl von Ossietzky. Dieser setzt die Open Source Software Open Journal Systems (OJS) ein, mit der sowohl die Publikationsprozesse gesteuert als auch die Zeitschriftenwebsite gestaltet wird. Die Software wurde entwickelt vom nordamerikanischen Public Knowledge Project (PKP), das mit Blick auf das Thema Barrierefreiheit eine Erklärung zur grundsätzlichen Zugänglichkeit verfasst hat, in der angegeben wird, dass die Software grundsätzlich die Standards WCAG 2.1 der Ebene AA erfüllt.¹² Hiervon sind allerdings Webinhalte ausgenommen, die durch mit OJS kompatiblen Plugins generiert wurden; ebenso wie die von einer Redaktion veröffentlichte Magazininhalte. Diese Ausnahmen waren auch für unseren weiteren Projektverlauf bedeutsam.

3.1 Barrierenanalyse der bestehenden Website

Obgleich OJS selbst angibt, den grundsätzlichen Standard der WCAG 2.1 zu erfüllen, musste eine Analyse auf mögliche existierende Barrieren durchgeführt werden. Für den automatischen Scan wurde das Tool decareto verwendet. Die Hamburger Firma bietet eine kostenlose zweiwöchige Testversion an, die bis zu fünf Webseitenscans ermöglicht.¹³ Hierfür benötigt man lediglich die entsprechende URL der Webseite. Der große Vorteil des automatischen Scans und im verwendeten Tool liegt darin, dass alle Seiten überprüft werden und ein ausführlicher Fehlerbericht erstellt wird. Dabei sind die aufgelisteten Fehler anklickbar, sodass man sofort an die entsprechende Fehlerquelle gelangt. Allerdings gewährleistet das Tool keine Vollständigkeit. Barrieren können unentdeckt bleiben, weswegen eine zweite manuelle Auswertung ebenfalls notwendig war. Diese manuelle Überprüfung der Webseite erfolgte mit dem WAVE Evaluation Tool der Utah State University, welches ebenfalls auf Basis der WCAG Fehler, Prüfhinweise und weitere Informationen zu den einzelnen Unterseiten erfasst.¹⁴ Der Nachteil einer händischen Auswertung liegt im deutlich höheren Zeitaufwand. Die Verwendung beider Tools ermöglichte jedoch eine allgemein umfangreiche Analyse.

Mit dem automatischen Initialscan durch decareto wurden 363 Seiten mit Fehlern entdeckt, darunter 203 Seiten mit kritischen Fehlern. 128 Seiten wies das Tool als unproblematisch aus. Kritische Fehlerhinweise waren primär fehlende Alternativtexte bei Abbildungen, mit insgesamt 54 Hinweisen. Das betraf sowohl Abbildungen innerhalb der OJS-Software als auch in den Magazinartikeln. Einige Fehler wiederholten sich auf mehreren Seiten wie zum Beispiel der fehlende Alternativtext für die ORCID-iD-Abbildungen. Zudem wurden fehlende Textinformationen bei Verlinkungen gefunden, insbesondere bei Verlinkungen, die zugleich als Grafik fungierten, beispielsweise die Open-Access-Verlinkung in der rechten Seitenleiste. Zusätzlich lag bei einzelnen Unterseiten eine nicht stringente Überschriftenhierarchie vor. Weitere festgestellte Fehler waren fehlende <title>-Elemente, fehlende lang-Attribut und fehlende main landmark, die durch das Plugin Citation Style Language generiert wurden. Und schließlich identifizierte das WAVE Evaluation Tool zahlreiche redundante Verlinkungen sowie Kontrastfehler.

Bei einer individuellen Überprüfung fiel zusätzlich auf, dass die Website keine Tastaturbedienbarkeit ermöglichte und dass die gewählten Schriftarten für sehbehinderte Personen schwer lesbar waren. Außerdem fehlten die rechtlich vorgeschriebene Erklärung zur Barrierefreiheit und die Informationen in leichter Sprache. Damit gab es zahlreiche Barrieren, die wir beheben mussten.

3.2 Einordnung der gefundenen Barrieren

Vor der Erarbeitung von Lösungsvorschlägen zu Fehlerbehebung bedurfte es zunächst einer Klärung und Fehlererläuterung. Die identifizierten Fehler betrafen jeweils unterschiedliche Säulen der WCAG. Alternativtexte und die richtige Kontrastwahl zählen zur Wahrnehmbarkeit. Damit Textinhalte gut lesbar sind, sollten Kontraste von Vorder- und Hintergrund mindestens ein Verhältnis von 4,5:1 aufweisen (vgl. Endres u. a. 2025: 172). Des Weiteren wird empfohlen, dass Webinhalte in einer einheitlichen bevorzugt serifenlosen Schrift präsentiert werden.¹⁵

Eine Tastaturbedienbarkeit, <title>-Elemente, die Überschriftenstruktur, aber auch das Vorhandensein einer land-mark-region gehören zur Bedienbarkeit. Ist die Überschriftenhierarchie nicht hierarchisch aufgebaut, können sich Personen mit assistiven Technologien schlechter auf der Seite orientieren. Mit korrekt gesetzten Überschriften können Informationen leichter gefunden werden. Die wichtigsten Informationen stehen bestenfalls direkt am Seitenanfang.¹⁶ Eine stringente Überschriftenhierarchie kann sichergestellt werden, indem nacheinander die entsprechenden Überschriften beginnend mit einer <h1> für die Hauptüberschrift bis hin zu einer <h6> für Folgeüberschriften vergeben werden, ohne dass eine Zahl übersprungen wird (vgl. Endres u. a. 2025: 172).

Ein <title>-Element dient ebenfalls der Seitenorientierung. Das <title>-Element der „Kontakt”-Seite des API Magazins lautet beispielsweise „Kontakt”. Assistive Technologien stellen diese Information zur Verfügung, sodass Personen wissen, dass sie sich nun auf der Kontaktseite befinden. Fehlt ein solcher Titel, ist nicht klar, auf welcher Seite man sich aktuell befindet. Daher sollte auf jeder Seite ein solches Element implementiert sein (Theofanos und Redish 2003: 43–48).

Ebenso geben landmark regions an, auf welchem Seitenabschnitt man sich gerade befindet. Sie kennzeichnen dabei Stellenbereiche, wie den Header- oder den Footerbereich.¹⁷ Fehlt die Information, fällt die Orientierung schwer.

Lang-Attribute geben wiederum an, in welcher Sprache die Website verfasst ist. „Lang” ist hierbei für eine Abkürzung für „language”. Hier geht es darum, dass assistive Technologien die Informationen in der verfassten Sprache wiedergeben. Fehlt ein solches Attribut kann es zu Informationsverlusten in der Übersetzung assistiver Technologien kommen.¹⁸

Eine sachlich und einfach verständliche Informationsdarbietung sowie die Information, in welcher Sprache die Seite verfasst ist, verortet sich unter der Säule der Verständlichkeit. Um eine einheitliche und barrierearme Gendersprache zu gewährleisten, empfiehlt der Deutsche Blinden- und Sehbehindertenverband neben geschlechtsneutralen Formulierungen die Verwendung des Gendersternchens. Im Gegensatz zu anderen Kurzformen wie beispielsweise dem Doppelpunkt, ist das Sternchen besser wahrnehmbar und für assistsive Technologien verständlich.¹⁹

3.3 Konzeption und Umsetzung barrierefreier Maßnahmen

Auf Basis der zuvor geschilderten Kriterien und Vorgaben erfolgte die Fehlerkorrektur. Dabei lag der Fokus auf den Barrieren der OJS-Software und nicht in den Magazininhalten. Eine Korrektur der bisherigen Magazininhalte war deshalb nicht möglich, da veröffentlichte Inhalte zur Wahrung der wissenschaftlichen Integrität nicht nachträglich modifiziert werden sollten. Es hätte allenfalls die Möglichkeit bestanden, mit hohem personellen Aufwand eine zweite Edition zu erstellen und damit die Inhalte zu aktualisieren, während die bisherige Erstedition weiterhin simultan auf der Seite besteht. Die Neuedition war im Rahmen unserer zeitlich limitierten Projektes jedoch nicht zu leisten. Daher wurde direkt zu Projektbeginn entschieden, die Magazininhalte unangetastet zu lassen.

Aufgrund der hohen Fehleranzahl haben wir uns prioritär um das Implementieren von Alternativtexten gekümmert. Beim ORCID-Logo sind wir beispielsweise wie folgt vorgegangen: Zunächst haben wir die Grafik mit einem Alternativtext versehen. In diesem haben wir auch angegeben, dass die Grafik als Link fungiert und das Linkziel benannt. Die Alternativtexte müssen sachlich und prägnant formuliert werden und sollten die Anzahl von 100 Zeichen nicht überschreiten, was sich in Einzelfällen als herausfordernd darstellte.

Ein weiterer Fehler, den wir beheben mussten, waren identische Alternativtexte für verschiedene Abbildungen. Redundante Verlinkungen erschweren insbesondere bei der Verwendung assistiver Technologien eine grundsätzliche Orientierung und die Navigation. Im Falle der „Archiv”-Seite werden die Links über zwei verschiedene Wahrnehmungskanäle vermittelt. Das Magazincover ist ein visueller, die Überschrift ein textbasierter Link. Daher werden diese als zwei unterschiedliche Verlinkungen angezeigt. Die redundanten Verlinkungen ließen sich aufgrund der OJS-Struktur nicht ändern, jedoch konnte eine verbesserte Linkübersicht durch die Korrektur der Alternativtexte ermöglicht werden. Eine Herausforderung bestand darin, dass die Alternativtexte der Archivausgaben nicht im HTML-Quellcode bearbeitet werden konnten. Stattdessen gibt es bei OJS zur jeweiligen Ausgabe eine entsprechende Zeile, in der der Alternativtext eingetragen werden kann. Ursprünglich waren hier Bildnachweis für die Coverabbildungen eingetragen. Da die Cover jedoch gleichzeitig auch auf die jeweilige Ausgabe verlinken, musste zusätzlich das Linkziel implementiert werden. Der Lösungsvorschlag lag darin, sowohl die Ausgabe als auch die Bildrechte anzugeben nach folgendem Muster: „Ausgabe Bd. 1 Nr. 1 (2020) Foto: Dirk Theune”.

Um den im Ausgangszustand unzureichend sichtbaren Tastaturfokus zu verbessern, wurden insbesondere die Navigationslinks, das Logo mit der Startseitenverlinkung, die Magazin-Cover im Archiv sowie auf der Startseite technisch so angepasst, dass sie per Tastatur erreichbar sind und einen deutlich sichtbaren Fokusrahmen erhalten. Zusätzlich wurden Kontrastprobleme behoben, da einzelne Grautöne des Standard-OJS-Themes die geforderten Mindestkontraste nicht erfüllten. Dies betraf unter anderem Textelemente, Navigationsbereiche sowie Links, die zuvor ausschließlich über Farbe gekennzeichnet waren. Die Anpassungen erfolgten durch gezielte Anpassung von Farbwerten, Schriftgrößen und Schriftstärken.

Für eine leichtere Lesbarkeit der Schrift fiel die typografische Entscheidung auf IBM Plex Sans, da diese Schriftart eine sehr gute Buchstabenunterscheidung bietet und einer freien Lizenz steht. Durch die klare Differenzierung einzelner Buchstaben (z. B. von I und l sowie b und d) und durch ihre humanistische Formgebung (z. B. beim Buchstaben g), die sich an die Schreibschrift anlehnt, werden sehbeeinträchtigte Personen unterstützt. Die Schriftart wird zukünftig auch beim Logo verwendet, sowie für Überschriften und die Magazininhalte.

Parallel dazu wurde ein WCAG-2.1-AA-konformes Farbsystem entwickelt. Das neue Primärgrün erreicht auf dem Hintergrund ein Kontrastverhältnis von 5.6:1 und erfüllt damit die Anforderungen an ausreichende Lesekontraste. Ergänzend wurden klare Fokusrahmen und ein ruhiger Footer-Hintergrund definiert, der besser zu den dort abgebildeten Logos passt als das ursprüngliche Beige im Footer.

Die gestalterische und technische Umsetzung des graphischen Redesigns erfolgte zunächst im OJS-Sandkastensystem auf einem Testserver, um sämtliche Anpassungen kontrolliert zu entwickeln und zu testen. Zur Implementierung der Designentscheidungen wurde eine eigenständige CSS-Datei erstellt und im System hinterlegt. Diese Datei ist ausführlich kommentiert, sodass Struktur, Zweck und Wirkungsweise einzelner Anpassungen auch für zukünftige Bearbeitungen nachvollziehbar bleiben.

Über die CSS-Datei wurden zentrale gestalterische Parameter des neuen Erscheinungsbildes technisch umgesetzt. Dazu zählen insbesondere das Farbsystem, die Optimierung von Kontrastwerten gemäß den Anforderungen der WCAG-Richtlinien sowie die Ausarbeitung einer klaren visuellen Hierarchie durch differenzierte Typografie, konsistente Schriftgrößen, Zeilenabstände und Abstandslogiken. Die neue Schrift wurde lokal auf dem Server eingebunden und im Stylesheet referenziert. Abstände und Innenräume (Paddings & Margins) wurden systematisch in 10px-Schritten (OJS-Standard) vereinheitlicht, um ein konsistentes Layout zu gewährleisten. Darüber hinaus wurden Hover- und Interaktionszustände vereinheitlicht und Links grundsätzlich unterstrichen.

Die Zwischenpräsentation vor den Kolleg*innen des Verlags Hamburg University Press bot Gelegenheit, die von den Plugins generierten Barrieren anzusprechen. Denn mit Blick in den Fehlerbericht wurde deutlich, dass das Citation-Style-Plugin für die Hinweise zur fehlenden main landmark, des fehlenden lang-Attributes und des <title>-Elements ursächlich ist. Ebenso generiert das Google-Scholar-Plugin keinen Alternativtext für die Abbildungen. OJS gab in ihrer Zugänglichkeitserklärung bereits an, dass die externen Plugins nicht barrierefreie Inhalte generieren. Dies führte zur Frage, ob die Barrieren im Rahmen des Projektes überhaupt gelöst werden können. Nach einer Abstimmung mit den Projektverantwortlichen wurde entschieden, dass lediglich eine Korrektur von Barrieren in benutzerdefinierten, nicht jedoch in den oben genannten, systemintegralen Plugins möglich war. Das API Magazin verwendet insgesamt drei benutzerdefinierte Plugins, von denen das Open-Access-Plugin und das Copyright-Plugin nicht barrierefreie Inhalte generieren. Diese Plugins sind für die verlinkten Abbildungen ohne Alternativtext in der rechten Seitenleiste der Webseite verantwortlich. Durch das Einfügen von Alternativtexten, die das Linkziel jeweils beschreiben, konnten diese Barrieren beseitigt werden. Die Open-Access-Abbildung verlinkt nun auf die „Open Access”- Unterseite des API Magazins. Daher wurde der Alternativtext so formuliert, dass deutlich wird, dass man auf jene Unterseite gelangt, sobald man die Abbildung anklickt.

Und abschließend haben wir noch eine neue Unterseite erstellt, welche die wichtigsten Informationen über das API Magazin in Leichter Sprache bereitstellt. Davon können eine Vielzahl von Menschen profitieren, u.a. Personen mit Leseschwäche und mit nur geringfügigen Deutschkenntnissen. Im Fall des API Magazins könnten dies beispielsweise Austauschstudierende sein. Bei Erläuterungen in Leichter Sprache ist der Aufbau entscheidend, da ein Satz möglichst eine Zeile lang sein sollte. Jeder Satz transportiert dabei eine einzige Aussage. Der Satzbau ist dabei kurz und klar. Das Vokabular besteht aus allgemein bekannten und leicht zugänglichen Wörtern. Fach- und Fremdwörter gilt es zu vermeiden (Schach 2023: 319). Interessierte Personen können nun in Leichter Sprache nachlesen, was das API Magazin ist, wer es erstellt, was Open Access bedeutet und welche Inhalte die Website enthält.

3.4 Evaluation

Nach dem erfolgreich durchgeführten Relaunch wurde im Februar 2026 ein automatischer Abschlussscan ebenfalls mit decareto durchgeführt. Das Ergebnis zeigt dabei die Verbesserung im Vergleich zum Initialbeginn. Die Anzahl von 363 problematischen Seiten reduzierte sich auf 321. Ebenso minimierten sich die Seiten mit kritischen Problemen von 203 auf 158. Gleichzeitig verbesserten sich unproblematische Seiten von 128 auf 178. Die abschließend von decareto gefundenen Barrieren beziehen sich auf die eingangs beschriebenen OJS-inhärenten Barrieren, verursacht durch das Citation-Style-Language-Plugin und das Google-Scholar-Plug-in sowie fehlende Alternativtexte der bereits veröffentlichten Magazininhalte.

Um die Umsetzung der Maßnahmen neben der automatischen Auswertung in der Praxis überprüfen zu können, musste das API Magazin zudem mithilfe assistiver Technologien getestet werden. Hier wurde mit der Voice-Over-Funktion des eigenen Macbooks überprüft. Die von Apple entwickelte Voice-Over findet sich unter „Einstellungen”-> „Bedienungshilfen”. Das Voice-Over ist ein Bildschirmlesegerät, das es die Webinhalte in gesprochener Sprache wiedergibt. Gesteuert wird die Funktion mithilfe der Tastatur. Die Tatstaturbedienbarkeit wurde mithilfe der neuen Designvorlage erfolgreich implementiert. Getestet wurden unter anderem, wie Alternativtexte und Verlinkungen wiedergegeben werden. Auf den Seiten, deren Überschriftenhierarchie wiederhergestellt wurde, wurde zudem die Orientierung überprüft. Der Selbsttest erwies sich als überaus hilfreich. Alternativtexte wurden erfolgreich wiedergegeben. Voice-Over gab beispielsweise den Alternativtext zur ORCID-Abbildung mit den Worten „Zur Startseite von ORCID - Bild” wieder. Das heißt Nutzende erhalten den vollständig implementierten Alternativtext inklusive des Hinweises „Bild” und wissen, dass es sich um eine Abbildung handelt, die sie zur ORCID-Startseite führt. Neben der korrekten Wiedergabe der eingesetzten Alternativtexte, glückt auch die Orientierung beispielsweise auf der Kontaktseite. Die neu implementierte h2-Überschrift führt dazu, dass das Voice-Over erkennt, in welchem Seitenabschnitt sich Personen befinden. Den Nutzenden wird vorgelesen „Du bist jetzt auf: Überschrift-Ebene 2”. Obgleich ein Usability-Test mit der betroffenen Zielgruppe nicht möglich war, zeigt der Selbsttest, dass die Alternativtexte von Bildschirmlesegeräten korrekt ausgesprochen und Überschriftenebenen erkannt und wiedergegeben werden. Die getätigten Maßnahmen zur Verbesserung der Barrierefreiheit sind demnach erfolgreich umgesetzt und verhelfen betroffenen Personen, die Webinhalte besser wahrzunehmen und sich auf der Seite zu orientieren.

4 Fazit

Zusammenfassend lässt sich feststellen, dass alle änderbaren Barrieren unter Anwendung der WCAG-Standards korrigiert wurden und ein bestmögliches barrierearmes Ergebnis erzielt wurde. Die bestehenden Barrieren wurden in der Erklärung zur Barrierefreiheit vermerkt, die im Anschluss an den Abschlussscan angefertigt wurde. In eben jener Erklärung ist festgehalten, inwiefern das API Magazin die Richtlinien zur Barrierefreiheit erfüllt, gefolgt von einer Auflistung, welche Inhalte nicht barrierefrei sind. Zuzüglich enthält die Erklärung eine ausführliche Erläuterung, weshalb keine durchgängige Barrierefreiheit gewährleistet werden kann. Sollten Betroffene weitere nicht aufgelistete Barrieren identifizieren, ist ein Kontakt sowie eine Ombudsstelle hinterlegt, an die sich im gegebenen Falle wenden können.

Trotz der erfolgreichen Zielerreichung war das Projekt mit verschiedenen Herausforderungen verbunden. Eine zentrale Schwierigkeit bestand in den technischen Rahmenbedingungen des verwendeten OJS-Systems. Bestimmte Barrieren konnten nicht behoben werden, da sie durch systeminterne Plugins oder strukturelle Vorgaben der Software verursacht wurden. Diese Einschränkungen machten deutlich, dass die vollständige Umsetzung der WCAG-Richtlinien innerhalb des Projektrahmens nicht möglich war und stattdessen eine barrierearme Lösung angestrebt werden musste. Eine weitere Herausforderung bestand in der technischen Umsetzung barrierefreier Maßnahmen ohne umfangreiche Programmierkenntnisse. Insbesondere die Arbeit mit HTML-Strukturen und CSS erforderte eine intensive Einarbeitung und einen erheblichen Zeitaufwand.

Insgesamt sind die erzielten Ergebnisse eindeutig positiv zu bewerten, müssen jedoch kritisch eingeordnet werden. Zwar konnte eine erhebliche Reduktion von Barrieren erreicht werden und die abschließenden Scans zeigen eine klare Verbesserung gegenüber dem Ausgangszustand, dennoch bestehen weiterhin Einschränkungen. Diese betreffen insbesondere pluginbasierte Inhalte sowie bereits veröffentlichte Magazinartikel. Auch die Überprüfung der praktischen Nutzbarkeit assistiver Technologien erfolgte überwiegend im Rahmen von Selbsttests. Dadurch konnten zwar grundlegende Funktionen überprüft werden, eine Prüfung mit betroffenen Nutzergruppen fand jedoch nicht statt.

Trotz dieser Einschränkungen besitzen die Projektergebnisse eine hohe Bedeutung für die Professionalisierung und zukünftige Entwicklung des API Magazins. Durch die konsequente Orientierung an Standards wie den WCAG-Richtlinien sowie durch die zeitgleiche Einführung verbindlicher KI-Richtlinien, die ebenfalls vom Projektteam entwickelt wurden, positioniert sich das Magazin als verantwortungsbewusstes wissenschaftliches Publikationsmedium und unterstützt zugleich den inklusiven Anspruch der Hochschule.

Perspektivisch kann die barrierefreie Weiterentwicklung des Magazins konsistent fortgeführt werden. Neben der laufenden Fortentwicklung der erarbeiteten Richtlinien und Gestaltungsvorgaben könnten zukünftige Projekte prüfen, inwiefern pluginbasierte Barrieren reduziert oder alternative technische Lösungen gefunden werden können. Und insbesondere die barrierefreie Gestaltung zukünftiger Magazinbeiträge wird die Zugänglichkeit zu den studentischen Publikationen noch einmal deutlich verbessern, so dass das API Magazin dann bestenfalls vollumfänglich offen für alle Nutzende sein wird.

Literatur