004 Informatik
Refine
Document Type
- Bachelor Thesis (5)
Language
- German (5)
Has Fulltext
- yes (5)
Is part of the Bibliography
- no (5)
Keywords
- Barrierefreiheit (5) (remove)
Institute
Über 90 % der umlaufenden PDF-Dokumente sind zumindest teilweise unzugänglich. Aus diesem Grund hat Adobe eine künstliche Intelligenz (KI) entwickelt, die automatisch Tags in PDF-Dokumente setzt, um sie barrierefreier zu gestalten.
Um dies zu überprüfen, wurde in unserer Bachelorarbeit die barrierefreien PDF-Dokumente nach dem Standard PDF/UA (DIN ISO 14289-1:2016-12) untersucht. Wir verwendeten für die Ermittlung des PDF/UA Standards das Matterhorn Protokoll. Für den Versuch erstellten wir PDF-Dokumente, die die Fehlerbedingungen des Matterhorn Protokolls und den Richtlinien von PDF/UA verstoßen.
Unsere Ergebnisse zeigen, dass 37 % der Fehler vom Matterhorn Protokoll behoben wurden, während 42 % nicht behoben wurden. Die restlichen 21 % der Fehler konnten von der KI technisch nicht gelöst werden, da sie nicht dafür entwickelt wurde. Zu den 21 % gehören auch Fehler, die technisch nicht von uns umgesetzt werden konnten oder nicht den heutigen Standards angepasst worden sind.
Wenn die manuellen Fehler von den maschinellen Fehlern in der Gesamtstatistik getrennt werden, dann konnte die KI 46 % der manuellen Fehlerbedingungen beheben. Bei den maschinellen Fehlerbedingungen konnten 32 % gelöst werden.
Anhand der Ergebnisse kann erkannt werden, dass die bearbeiteten PDFs nicht PDF/UA Standard entsprechen. Zudem konnte die KI in der Auswertung die Fehler in den PDFs nicht zuverlässig beheben und erkennen. Während der Untersuchung konnten wir außerdem inhaltliche Veränderungen feststellen und zusätzlich generierte sie auch neue Fehler.
Obwohl es nicht den PDF/UA Standard entspricht, konnten 46 % der manuellen Fehlerbedingungen des Matterhorn Protokolls gelöst werden. Dieses Ergebnis ist beeindruckend, weil die manuellen Fehler zurzeit nur von Menschen behoben werden können. Mit ausreichenden Optimierungen kann diese KI-Technologie in Zukunft als hilfreiches Werkzeug für die Gestaltung von barrierefreien PDF-Dokumenten verwendet werden.
This paper deals with the contrast modes of the operating systems Windows, Mac OS, IOS and Android. The various effects, of web browsers and operating systems, on the implementation of contrast modes, are analysed and documented. This is done using a test website created for this purpose, which combines different definitions for fore- and background colors.
Based on the results, own bookmarklets are developed. These, simulate the selected contrast modes from the Windows system, during the implementation in the web brow-sers Google Chrome, Mozilla Firefox and Microsoft Edge.
The work aims to facilitate the creation of barrier-free(accessible) websites. This is at-tempted by implementing checks for sufficient contrast between the font and the back-ground, as well as the effects in different web browsers, during their development or a subsequent test.
To conclude, there is a recommendation on how to best define the fore- and background colours for websites in order to achieve the minimum contrast according to WCAG 2.1, even when using the operating system's own contrast modes.
Anhand der Ergebnisse werden eigene Bookmarklets entwickelt, die die ausgewählten Kontrastmodi aus dem Windowssystem in der Umsetzung in den Webbrowsern Google Chrome, Mozilla Firefox und Microsoft Edge simulieren.
Die Arbeit soll dazu beitragen, das Erstellen von barrierefreien Websites zu erleichtern, indem schon während ihrer Entwicklung oder einem nachfolgenden Test auf ausrei-chend Kontraste zwischen der Schrift und dem Hintergrund und Auswirkungen in ver-schiedenen Webbrowsern geprüft werden kann.
Abschließend gibt es eine Handlungsempfehlung, wie die Vorder- und Hintergrundfar-ben für Websites am besten zu definieren sind, damit sie auch bei Anwendung der Be-triebssystem eigenen Kontrastmodi möglichst das Minimum an Kontrast nach den Vor-gaben WCAG 2.1 erreichen.
Ab Mitte 2025 wird das Barrierefreiheitsstärkungsgesetz viele Unternehmen in Deutschland dazu verpflichten, ihre Websites und Online-Shops barrierefrei zu gestalten. Sie stehen vor der Herausforderung, die Barrierefreiheit künftig in den Entwicklungsprozess ihrer digitalen Plattformen zu integrieren.
Um dies zu erleichtern, entwarfen wir im Rahmen dieser Arbeit einen Entwicklungsprozess für barrierefreie Webanwendungen in Scrum, der in einem Experiment mit anschließender heuristischer Evaluation und einer Befragung in einem E-Commerce-Unternehmen validiert wurde. Der Entwicklungsprozess befasst sich mit der Einbeziehung von Barrierefreiheit in Scrum-Elemente wie Product Backlog Items, die Definition of Ready und Definition of Done. Außerdem zeigt er bewährte Praktiken für die Implementation und das Testen von Barrierefreiheit auf.
Die Ergebnisse zeigten, dass die Erfassung von Barrierefreiheitsanforderungen in Form von Gherkin-Szenarien zu einer schnelleren Bearbeitung von Aufgaben und höheren Zufriedenheit mit dem Entwicklungsansatz im Scrum-Team beiträgt. Ferner wurde deutlich, dass die Schulung des Personals unerlässlich ist, um die Anforderungen der EN 301 549 und der WCAG vollständig zu erfüllen.
Diese Arbeit macht deutlich, dass Unternehmen zeitnah Maßnahmen ergreifen müssen, um das Barrierefreiheitsstärkungsgesetz rechtzeitig umsetzen zu können.
Diese Arbeit stellt aktuell verfügbare Prüf-Tools auf Erfolgskriterium 1.3.5 der Web
Content Accessibility Guidelines 2.1 (WCAG) zusammen und vergleicht diese miteinander.
Der Vergleich zeigt, dass die derzeitigen Test-Anwendungen nicht ausreichend
in ihrem Vorgehen und ihrer Funktionalität sind. Die Prüferinnen und Prüfer müssen
dabei immer selbst beurteilen, ob der autocomplete-Attributs-Wert korrekt und
erforderlich ist.
Das im Zuge dieser Arbeit programmierte Autocomplete-Check-Plugin ist den aktuellen
Prüf-Tools vor allem durch das Alleinstellungsmerkmal der heuristisch getroffenen
autocomplete-Vorschläge überlegen und unterstützt und komplementiert den
Prüfvorgang somit bestens. Die wichtigsten Komponenten des Plugins werden vorgestellt
und deren Implementierung erläutert. Außerdem werden die methodischen
Vorgehensweisen, die in dieser Arbeit angewendet wurden, behandelt. Die Validierung
des Plugins wurde anhand vorher unbekannter Test-Webseiten durchgeführt, sie bescheinigt
dem Autocomplete-Check-Plugin eine hohe Genauigkeit bei der Vorhersage
von autocomplete-Werten, damit ist es hervorragend geeignet, Webseiten auf das Erfolgskriterium
1.3.5 zu untersuchen. Das Plugin wird unter der MIT-Lizenz auf Github
veröffentlicht.
Um Websites für jeden Menschen ohne Einschränkungen verfügbar zu
machen, wurden auf nationaler sowie internationaler Ebene Gesetze und Normen verabschiedet, welche die Barrierefreiheit für Internetauftritte anhand festgelegter Richtlinien
wahren sollen. Zur Einhaltung dieser Richtlinien wurden Prüfverfahren entwickelt, die anhand unterschiedlicher Evaluationsmethoden den Grad der Zugänglichkeit von Webseiten
und ihren Inhalten bewerten. Zwei dieser Prüfverfahren sind der Barrierefreiheitscheck-Web sowie der BIK BITV-Test. Für die manuelle Durchführung der Tests wird üblicherweise
eine repräsentative Stichprobe der Website erstellt und das Ergebnis der Prüfung auf die
Stichprobe für die gesamte Website generalisierend angenommen. Die Erstellung der Seitenauswahl ist bei umfangreichen Websites jedoch mit großem Aufwand verbunden und
soll im Zuge dieser Arbeit mit Hilfe einer serverseitigen Web-Anwendung automatisiert
werden.
Dazu wurden verschiedene existierende Stichprobenverfahren und Crawling-Methoden
analysiert und anschließend für die Eignung der technischen Umsetzung eingeordnet. Im
Rahmen der Arbeit wird ein eigener Ansatz für die automatisierte Seitenauswahl präsentiert, der auf dem HTML class-Attribut basiert. Dieser Ansatz nutzt die Eigenschaft von
Klassennamen aus, den Namen des Strukturelements zu beinhalten. Dadurch zielen wir
darauf ab, wichtige Inhalte der zu prüfenden Website zu erfassen und diese Informationen als Grundlage für die Auswahl der Stichprobe zu nehmen.
Die Evaluation wurde durch den Vergleich der generierten Liste unserer Anwendung von
drei ausgewählten Webseiten, mit der von Experten des Kompetenzzentrums Digitale
Barrierefreiheit der HdM erstellten Liste, durchgeführt. Die Ergebnisse zeigten, dass unsere Anwendung eine Liste von Seiten generieren konnte, die ein breites Spektrum an
Inhalten abdeckte, jedoch begrenzte Fähigkeiten hatte, der Liste der Experten zu gleichen
und daher in der aktuellen Version für den Barrierefreiheitscheck-Web nicht als alleinstehendes Tool geeignet ist.