Abgabe Praxisprojekt

_works/2025-jungilligens-meike/02-titles-and-research-questions.md

@@ -0,0 +1,18 @@
+# Titel und Forschungsfrage
+
+### Titelideen
+- Analyse der Konformität von UI-Frameworks mit den WCAG-Standards
+- Accessibility by Default? Eine Untersuchung der Barrierefreiheit in UI-Komponentenbibliotheken
+- Barrierefreie UI-Komponenten: Wie viel Accessibility bieten moderne Frontend-Frameworks von Haus aus?
+- Accessibility in Material Design: Vergleich zwischen Vuetify (Vue.js) und Material UI (React)
+- Dark Mode, Kontraste und Farbblindheit: Wie barrierefrei sind Vue.js-UI-Bibliotheken für visuell eingeschränkte Nutzer?
+- Accessibility in Vue-Komponenten: Wie gut sind moderne UI-Libraries für Menschen mit Behinderungen nutzbar?
+- Tastaturnavigation und Screenreader-Support in Vuetify: Eine systematische Evaluierung
+- _**Barrierefreiheit in Frontend-Frameworks: Eine systematische Evaluierung anhand der WCAG 2.1 Standards am Beispiel von Vuetify**_
+- Vuetify und Screenreader: Wie gut sind die Standardkomponenten für blinde Nutzer nutzbar?
+- Verbesserung der Accessibility-Dokumentation von Vuetify: Ein Leitfaden für Entwickler
+
+### Mögliche Zielbilder
+- **Kriterienkatalog** für die weitere Evaluierung der Barrierefreiheit von UI-Komponenten
+- **Checkliste** für Entwickler bei der Benutzung entsprechender Komponenten
+- (Digitales) **Poster/Infografik** als Überblick über Forschungsergebnisse

_works/2025-jungilligens-meike/03-expose.md

@@ -0,0 +1,22 @@
+# Exposé


+## Barrierefreiheit in Frontend-Frameworks - Eine systematische Evaluierung anhand der WCAG 2.1 Standards am Beispiel von Vuetify


+## Problemfeld und Kontext

+Moderne Web-Frameworks wie Vuetify ermöglichen eine schnelle und einheitliche UI-Entwicklung, vor allem für komplexe Frontends mit Vue.js. Dennoch ist nicht sichergestellt, dass die damit erstellten Anwendungen automatisch barrierefrei sind. Die Einhaltung von Richtlinien wie den WCAG 2.1 (Web Content Accessibility Guidelines) bleibt oft in der Verantwortung der Entwickler*innen.

Gerade bei komplexen Frameworks mit vielen Komponenten ist nicht transparent, welche Elemente barrierefrei sind und wo nachgearbeitet werden muss. Aus Entwicklersicht ist die Einhaltung der WCAG 2.1 Standards besonders durch das am 28. Juni 2025 in Kraft tretende Barrierefreiheitsstärkungsgesetz (BFSG) kritisch.


+## Forschungsstand

+Barrierefreiheit im Web ist umfassend durch die WCAG 2.1 geregelt, die auf internationaler Ebene weitgehend als Standard anerkannt ist ([W3C](https://www.w3.org/mission/accessibility/)).  Während es zahlreiche Beiträge zu allgemeiner Barrierefreiheit im Web oder zu Accessibility Testing gibt, ist der spezifische Bezug auf komponentengestützte Frameworks wie Vuetify bisher kaum untersucht. Einige Analysen existieren zu komponentenbasierter Entwicklung im Framework React, aber für Vue und insbesondere Vuetify fehlen strukturierte, komponentenbezogene Bewertungen nach WCAG.

Vuetify selbst verweist zwar auf Accessibility-Best Practices, jedoch meist allgemein oder auf Ebene einzelner Beispiele ([vuetifyjs.com](vuetifyjs.com/en/features/accessibility/)). Eine quellenbasierte, systematische Komponentenanalyse nach WCAG 2.1 für Vuetify liegt derzeit nicht vor und soll hier erstmals geleistet werden.


+## Fragestellung und Zielsetzung

+- Wie barrierefrei sind die Standardkomponenten des Vuetify-Frameworks in ihrer Grundkonfiguration gemäß den Anforderungen der WCAG 2.1?
+- Welche Barrieren bestehen bei der Nutzung von Vuetify-Komponenten in Bezug auf die WCAG 2.1, und welche Maßnahmen müssen Entwickler ergreifen, um diese zu beseitigen?
+In der vorliegenden Arbeit wird eine Auswahl an Vuetify-Komponenten systematisch im Hinblick auf ihre Barrierefreiheit analysiert. Die gewonnenen Erkenntnisse werden in Form einem praxisorientierten Poster für Entwickler aufbereitet. Dieses soll aufzeigen, bei welchen Komponenten zusätzliche Maßnahmen erforderlich sind, um Barrierefreiheit sicherzustellen, und welche Aspekte bei der Nutzung spezifischer Vuetify-Komponenten besonders beachtet werden müssen.
+## Methodik
+- Systematische Klassifikation und Vorauswahl der zu betrachtenden Komponenten
+- Erstellen einer Kriterienliste pro Komponente nach WCAG
+- Aufbau einer lokalen Testumgebung
+- Dokumentiertes Testen der Komponenten mit automatisierten Browser-Tools wie Axe und Lighthouse sowie manuelle Tests mit Screenreader NVDA

+- Erstellen einer praxisorientierten Barrierefreiheits-Checkliste für Vuetify-Entwickler


+## Zeitplanung

+- Woche 1: Literaturrecherche und -auswertung

+- Woche 2-3: Vorbereitung der Analyse (Auswahl der Komponenten sowie der zu erfüllenden Kriterien)

+- Woche 4-5: Durchführung und Auswertung der Analyse, Rohfassung der Poster

+- Woche 6: Fertigstellen der Poster

+- Woche 7-8: Anfertigung der schriftlichen Ausarbeitung

_works/2025-jungilligens-meike/04-results/README.md

@@ -0,0 +1,3 @@
+# Ergebnisse
+
+Bitte legen Sie Ihre Ergebnisse hier ab. Achten Sie bitte auf moderate Dateigrößen. Bitte legen Sie nur geschlossene Dokument, z.B. PDF statt *.doc ab.

_works/2026-jungilligens-meike/01-resarch-area-analysis/README.md

@@ -0,0 +1,3 @@
+# Themenfeldanalyse
+
+Bitte legen Sie Ihre Concept Map zur Themenfeldanalyse hier als PDF ab. Die Datei sollte nicht größer als 2 Mbyte sein.

_works/2026-jungilligens-meike/02-titles-and-research-questions.md

@@ -0,0 +1,21 @@
+# Titel und Forschungsfrage
+
+1. Barrierefreie Webkomponenten: Systematische Analyse und Optimierung von Vuetify
+
+2. Implementierung und Evaluation von Accessibility-Verbesserungen in Vuetify-Komponenten
+
+3. Screenreader-Usability in modernen Vue.js-Komponentenframeworks: Eine empirische Untersuchung
+
+4. **Verbesserung der Screenreader-Unterstützung in Vuetify: Eine komponentenbasierte Analyse und Optimierung der Accessibility-Implementierung nach WCAG 2.1**
+
+5. Screenreader-Performance in modernen Webframeworks: Eine Analyse und Optimierung von Vuetify-Komponenten
+
+6. Analyse und Verbesserung der Screenreader-Kompatibilität im Vuetify-Framework nach WCAG 2.1
+
+7. Accessibility als Framework-Herausforderung: Eine Untersuchung der Screenreader-Unterstützung in Vuetify
+
+8. ARIA in der Praxis: Eine Evaluation semantischer Accessibility-Implementierungen in Vuetify
+
+9. Evaluierung von ARIA-Implementierungen in Vuetify und deren Einfluss auf die Accessibility
+
+10. Vergleich semantischer HTML-Strukturen und ARIA-Implementierungen in Vuetify-Komponenten

_works/2026-jungilligens-meike/03-expose.md

@@ -0,0 +1,49 @@
+# Exposé
+
+## Verbesserung der Screenreader-Unterstützung in Vuetify: Eine komponentenbasierte Analyse und Optimierung der Accessibility-Implementierung nach WCAG 2.1 
+
+
+## Problemfeld und Kontext 
+Moderne UI-Frameworks wie Vuetify ermöglichen eine schnelle Entwicklung komplexer Frontends mit Vue.js. Dabei abstrahieren sie viele HTML- und DOM-Strukturen hinter wiederverwendbaren Komponenten. Diese Architektur erhöht jedoch die Gefahr, dass die semantische Bedeutung von Elementen und die korrekte Screenreader-Unterstützung verloren gehen.
+
+
+Trotz vorhandener Accessibility-Richtlinien und ARIA-Spezifikationen wird in der Praxis deutlich, dass selbst weit verbreitete Frameworks Barrieren für Screenreader-Nutzer*innen aufweisen. Im offiziellen Vuetify-Repository finden sich zahlreiche Issues zu unvollständigen ARIA-Attributen, inkonsistentem Fokus-Management oder nicht erkannten Rollen.
+
+
+Gerade im Hinblick auf gesetzliche Anforderungen wie das Barrierefreiheitsstärkungsgesetz (BFSG) ab Juni 2025 ist eine verlässliche Umsetzung der WCAG 2.1-Standards auch auf Framework-Ebene relevant. Die Arbeit untersucht deshalb, wie Vuetify-Komponenten aktuell mit Screenreader-Technologien interagieren und wie die Accessibility durch gezielte Optimierungen im Code verbessert werden kann.
+
+
+## Forschungsstand 
+Barrierefreiheit im Web ist durch die WCAG 2.1 des W3C umfassend definiert. Sie beschreibt unter anderem Anforderungen an semantische Struktur, Tastaturzugänglichkeit und Screenreader-Kompatibilität.  Während es zahlreiche Beiträge zu allgemeiner Web-Accessibility und automatisierten Tests (z. B. mit axe-core oder Lighthouse) gibt, fehlt eine systematische Untersuchung der Screenreader-Implementierung in komponentenbasierten Frameworks. Arbeiten zu React existieren vereinzelt, für Vue und Vuetify jedoch nicht. 
+
+
+Vuetify selbst verweist in seiner Dokumentation auf Accessibility-Best-Practices, bietet aber keine durchgehende Bewertung der eigenen Komponenten. Die Kombination aus automatisierter Analyse und praktischer Optimierung im Open-Source-Repo stellt somit einen neuen Beitrag zur systematischen A11y-Verbesserung in Vue-Frameworks dar.  
+
+
+## Fragestellung und Zielsetzung 
+
+- Wie gut lassen sich ausgewählte Vuetify-Komponenten mit Screenreadern bedienen, und welche typischen Barrieren treten dabei auf?
+- Welche Code-Anpassungen sind notwendig, um die Screenreader-Unterstützung zu verbessern, ohne die bestehende Architektur zu beeinträchtigen? 
+
+
+Ziel der Arbeit ist eine komponentenbasierte Analyse und Optimierung der Screenreader-Kompatibilität in Vuetify. Die Ergebnisse werden dokumentiert und in Form von Pull-Requests  in das öffentliche Repository eingebracht. Zudem werden die Verbesserungen in Bezug auf ihre Wirkung durch erneutes Testen evaluiert. 
+
+
+## Methodik 
+- **Vorbereitung:** Einarbeitung in Vuetify-Architektur (Monorepo-Struktur) und Sichtung der Dokumentation/Contributing-Guidelines, Auswahl relevanter Komponenten auf Basis der GitHub-Issues (Label a11y). 
+- **Analyse:** Durchführung von Accessibility-Tests (automatisiert (Lighthouse, a11y-Tree), manuell und mit Hilfswerkzeugen (Screenreader)) auf basis des Praxisprojekts
+- **Implementierung:** Ergänzen oder Korrigieren von ARIA-Attributen, Fokus-Management und semantischen Rollen in ausgewählten Komponenten.
+- **Evaluation:** Vergleich der Testergebnisse vor/nach den Anpassungen, qualitative Einschätzung der Screenreader-Nutzung.  
+- **Praxisbeitrag:** Bereitstellen der optimierten Komponenten als Pull-Request im Vuetify-Repository 
+
+
+## Zeitplanung  
+- **Woche 1:** Literatur- und Dokumentationsrecherche (WCAG 2.1, ARIA, Vuetify-Architektur). 
+- **Woche 2–3:** Auswahl der Komponenten, Aufbau der Testumgebung, Definition der Bewertungskriterien. 
+- **Woche 4–5:** Durchführung der Screenreader- und ARIA-Analysen. 
+- **Woche 6–7:** Umsetzung und Test der Verbesserungen, Erstellung von Pull-Requests. 
+- **Woche 8–9:** Evaluation, Diskussion, Fertigstellung der schriftlichen Ausarbeitung.  
+
+
+## Erwarteter Beitrag 
+Die Arbeit liefert eine erste dokumentierte Analyse der Screenreader-Tauglichkeit ausgewählter Vuetify-Komponenten. Sie zeigt strukturiert auf, welche Barrieren aktuell bestehen und wie diese technisch gelöst werden können. Dadurch entsteht sowohl ein praktischer Mehrwert (konkrete Verbesserungen im Vuetify-Ökosystem) als auch ein wissenschaftlicher Beitrag zur Diskussion, wie moderne Komponentenframeworks Accessibility konsequent umsetzen können.

_works/2026-jungilligens-meike/04-results/README.md

@@ -0,0 +1,3 @@
+# Ergebnisse
+
+Bitte legen Sie Ihre Ergebnisse hier ab. Achten Sie bitte auf moderate Dateigrößen. Bitte legen Sie nur geschlossene Dokument, z.B. PDF statt *.doc ab.