Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:modul:m291:learningunits:lu05:theorie:c_accessibility [2026/03/08 21:08] – gkoch
+++ de:modul:m291:learningunits:lu05:theorie:c_accessibility [2026/03/08 22:22] (aktuell) – gkoch
@@ Zeile 1: / Zeile 1: @@
 ====== LU05c – Accessibility Basics (A11y) ======
-<WRAP info>
+{{:de:modul:m291:learningunits:lu05:theorie:1655410107982.jpeg?nolink&800| Illustration for Accessibility}}
-**Weiterführende Ressource:** Dieser Block stützt sich auf den Google-Kurs [[https://web.dev/learn/accessibility|web.dev – Learn Accessibility]].
+<WRAP box round 80% center>
+**Weiterführende Informationen:** Dieser Block stützt sich auf den Google-Kurs [[https://web.dev/learn/accessibility|web.dev – Learn Accessibility]].
 </WRAP>
@@ Zeile 18: / Zeile 20: @@
 Eine schlecht zugängliche Website kann für jemanden, der einen Screenreader benutzt, komplett unbenutzbar sein – genau wie eine fehlende Rampe jemanden im Rollstuhl ausschliesst.
 ==== Warum ist A11y wichtig? ====
+{{:de:modul:m291:learningunits:lu05:theorie:inclusion_0.5x.png?nolink&300|}}
 Barrierefreiheit ist kein «Nice-to-have» mehr – sie ist aus drei Gründen relevant:
@@ Zeile 30: / Zeile 35: @@
 ===== WCAG – Der internationale Standard =====
-Die **Web Content Accessibility Guidelines (WCAG)** werden vom World Wide Web Consortium (W3C) entwickelt und gelten als internationaler Goldstandard für digitale Barrierefreiheit. Sie bieten Entwickler:innen klare, prüfbare Kriterien dafür, wie eine zugängliche Website aussehen muss.
+{{youtube>7C-KHXPnDF0?}}
-==== Konformitätsstufen ====
+Die **Web Content Accessibility Guidelines (WCAG)** werden vom World Wide Web Consortium (W3C) entwickelt und gelten als internationaler Standard für digitale Barrierefreiheit. Sie bieten Entwickler:innen klare, prüfbare Kriterien dafür, wie eine zugängliche Website aussehen muss.
-^ Stufe ^ Bedeutung ^ Einsatz ^
-| **A** | Mindestanforderungen | Ohne diese ist die Nutzung fast unmöglich |
-| **AA** | Internationaler Standard | Pflicht für Unternehmen und öffentliche Stellen |
-| **AAA** | Höchste Stufe | Oft schwer vollständig umsetzbar |
-Für die meisten Projekte gilt **Stufe AA** als Ziel.
 ==== POUR – Die vier Grundprinzipien ====
+{{:de:modul:m291:learningunits:lu05:theorie:digital-accessibility-standards-scaled.jpg?nolink&800|}}
 Die WCAG sind um vier Grundprinzipien aufgebaut, die unter dem Kürzel **POUR** zusammengefasst werden:
 === 1. Wahrnehmbarkeit (Perceivable) ===
+{{:de:modul:m291:learningunits:lu05:theorie:chatgpt_image_mar_8_2026_09_46_15_pm.png?nolink&300|}}
 Inhalte müssen für Augen, Ohren oder Screenreader erkennbar sein.
   * Bilder brauchen aussagekräftige ''alt''-Attribute
-  * Videos benötigen Untertitel
+  * Videos benötigen Untertitel oder Transkripte
   * Texte müssen ausreichend Kontrast zum Hintergrund haben (Mindest-Verhältnis: **4,5:1** für Fliesstext)
 === 2. Bedienbarkeit (Operable) ===
+{{:de:modul:m291:learningunits:lu05:theorie:focus-indicators-example-2048x768.png?nolink&600|}}
 Die Website muss ohne Maus – also nur mit Tastatur oder Sprachsteuerung – vollständig nutzbar sein.
@@ Zeile 62: / Zeile 67: @@
 === 3. Verständlichkeit (Understandable) ===
+{{:de:modul:m291:learningunits:lu05:theorie:language_4x.png?nolink&300|}}
 Sprache und Aufbau müssen logisch und vorhersehbar sein.
@@ Zeile 70: / Zeile 77: @@
 === 4. Robustheit (Robust) ===
+{{:de:modul:m291:learningunits:lu05:theorie:elizabeth-woolner-9xxnzcjz8ba-unsplash.jpg?nolink&400|}}
 Inhalte müssen auf verschiedenen Geräten und mit Hilfstechnologien (Screenreader, Braille-Ausgabegeräte) zuverlässig funktionieren.
@@ Zeile 79: / Zeile 88: @@
 ===== Screenreader =====
-Ein **Screenreader** ist ein Hilfsprogramm, das den Bildschirminhalt vorliest. Der Browser baut parallel zum DOM-Baum einen **Accessibility Tree** auf – eine vereinfachte Darstellung der Seite mit Rollen, Zuständen und Namen aller Elemente. Der Screenreader liest diesen Tree aus.
+Ein **Screenreader** ist ein Hilfsprogramm, das den Bildschirminhalt vorliest. Der Browser baut parallel zum DOM-Baum einen **Accessibility Tree** auf – eine vereinfachte Darstellung der Seite mit Rollen, Zuständen und Namen aller Elemente. Der Screenreader liest diesen Tree aus. Unter Mac gibt es in den System-Einstellungen zur "Accessibility" (Bedienungshilfen) die Möglichkeit VoiceOver zu aktivieren. Unter Windows heisst es Sprachausgabe.
-^ Screenreader ^ Plattform ^ Kosten ^
-| **VoiceOver** | macOS / iOS | integriert (kostenlos) |
-| **NVDA** | Windows | kostenlos (Open Source) |
-| **JAWS** | Windows | kostenpflichtig |
-| **TalkBack** | Android | integriert (kostenlos) |
-==== Live-Demo: Alarado Landingpage mit VoiceOver ====
-In der Lektion demonstrieren wir, was ein Screenreader auf der Alarado Landingpage vorliest. Die Beobachtungen:
-  * **Navigation:** Die Links in der Nav-Bar werden korrekt erkannt und vorgelesen, z. B. «Features, Link».
-  * **Buttons:** Die Haupt-Buttons im Hero-Bereich sind per Tab erreichbar und werden vorgelesen.
-  * **Dark-/Light-Mode-Switch:** ❌ **Nicht erreichbar!** Der Switch erscheint für den Screenreader nicht – er kann ihn weder finden noch bedienen.
@@ Zeile 108: / Zeile 104: @@
   * Für Screenreader als «Schaltfläche» erkennbar
-Ein ''%%<div>%%'' mit ''onclick'' hat **keine** dieser Eigenschaften von Haus aus.
-<code html>
+<WRAP round box 80%>
-<!-- ❌ Nicht barrierefrei ohne viel Zusatzarbeit -->
-<div onclick="openPanel()">Frage anzeigen</div>
-<!-- ✅ Semantisch korrekt – sofort barrierefrei -->
-<button onclick="openPanel()">Frage anzeigen</button>
-</code>
-<WRAP important>
 **Erste ARIA-Regel:** Verwenden Sie ARIA **nicht**, wenn ein natives HTML-Element denselben Zweck erfüllt. Ein ''<button>'' braucht kein ''role="button"''. ARIA ist nur dann nötig, wenn HTML allein nicht ausreicht.
 </WRAP>
@@ Zeile 127: / Zeile 115: @@
 ARIA ist eine Sammlung von HTML-Attributen, die Screenreadern und Hilfstechnologien zusätzliche Bedeutung kommunizieren – Rollen, Zustände und Eigenschaften, die HTML allein nicht ausdrücken kann.
+<WRAP center round box 80%>
 **Drei ARIA-Konzepte:**
@@ Zeile 133: / Zeile 122: @@
 | **Zustand** | ''aria-*'' | ''aria-expanded="true"'', ''aria-checked="false"'' |
 | **Eigenschaft** | ''aria-*'' | ''aria-label="Menü öffnen"'', ''aria-hidden="true"'' |
+</WRAP>
@@ Zeile 140: / Zeile 130: @@
 Im HTML setzen wir ''aria-expanded="false"'' als Ausgangszustand:
+<WRAP center round box 80%>
 <code html>
 <button class="accordion-btn" aria-expanded="false">
@@ Zeile 149: / Zeile 139: @@
 </p>
 </code>
+</WRAP>
 **Was der Screenreader vorliest:**
@@ Zeile 154: / Zeile 145: @@
   * Aufgeklappt: «What is this project, Schaltfläche, aufgeklappt»
-Im JavaScript aktualisieren wir ''aria-expanded'' beim Klick:
-<code javascript>
-buttons.forEach((button) => {
-  button.addEventListener('click', (e) => {
-    const btn          = e.currentTarget;
-    const panelElement = btn.nextElementSibling;
-    const panelIsOpen  = panelElement.classList.contains('open');
-    // Alle Panels schliessen + aria-expanded zurücksetzen
-    buttons.forEach((andererBtn) => {
-      andererBtn.nextElementSibling.classList.remove('open');
-      andererBtn.setAttribute('aria-expanded', 'false'); // ← State kommunizieren
-    });
-    // Dieses Panel öffnen
-    if (!panelIsOpen) {
-      panelElement.classList.add('open');
-      btn.setAttribute('aria-expanded', 'true');         // ← State kommunizieren
-    }
-  });
-});
-</code>
 ===== Tastaturbedienbarkeit =====
@@ Zeile 182: / Zeile 150: @@
 Nicht alle Nutzenden arbeiten mit einer Maus. Menschen mit motorischen Einschränkungen, Sehbehinderungen oder temporären Verletzungen navigieren mit der Tastatur.
-^ Taste ^ Aktion ^
-| ''Tab'' | Zum nächsten fokussierbaren Element springen |
-| ''Shift + Tab'' | Zum vorherigen Element springen |
-| ''Enter'' / ''Space'' | Button oder Link aktivieren |
-| ''Esc'' | Dialog oder Dropdown schliessen |
-| Pfeiltasten | Navigation innerhalb von Komponenten |
-==== Focus-Styles nicht entfernen! ====
-Der sichtbare Fokusrahmen (''outline'') ist für Tastaturnutzende das einzige visuelle Feedback, wo sie sich auf der Seite befinden. Ihn zu entfernen ist einer der häufigsten Barrierefreiheitsfehler überhaupt:
-<code css>
-/* ❌ Nie so – macht Tastaturnavigation unsichtbar */
-button:focus {
-  outline: none;
-}
-/* ✅ Eigenes Design anbieten, aber nie einfach weglassen */
-button:focus-visible {
-  outline: 3px solid var(--violet-600);
-  outline-offset: 3px;
-  border-radius: 4px;
-}
-</code>
-<WRAP tip>
-**'':focus-visible'' statt '':focus'':** Die Pseudo-Klasse '':focus-visible'' zeigt den Fokusrahmen nur bei Tastaturnavigation – nicht beim Mausklick. So bleibt das Design sauber, ohne Tastaturnutzende zu benachteiligen.
-</WRAP>
@@ Zeile 215: / Zeile 155: @@
 ==== Das Problem ====
+<WRAP center round box 80%>
 Im Alarado-Projekt wurde der ''<input type="checkbox">'' mit ''display: none'' versteckt:
@@ Zeile 226: / Zeile 166: @@
 Das entfernt das Eingabefeld **komplett** aus dem Accessibility Tree. Screenreader und Tastaturnavigation überspringen den Switch – er ist für Nutzende von Hilfstechnologien unsichtbar und nicht bedienbar.
+</WRAP>
 ==== Das HTML im Alarado-Projekt ====
+<WRAP center round box 80%>
 <code html>
 <label class="switch">
@@ Zeile 236: / Zeile 177: @@
 </label>
 </code>
+</WRAP>
 ==== Die Lösung: Visuell verstecken, aber zugänglich halten ====
 Statt ''display: none'' verwenden wir eine CSS-Technik, die das Element **optisch unsichtbar** macht, es aber im Accessibility Tree **belässt**. Diese Technik nennt man «Visually Hidden»:
+<WRAP center round box 80%>
 <code css>
 /* Visuell versteckt, aber für Screenreader sichtbar */
@@ Zeile 290: / Zeile 232: @@
   * «Dark Mode aktivieren, Schalter, ausgeschaltet»
   * Nach Klick: «Dark Mode aktivieren, Schalter, eingeschaltet»
+</WRAP>
 ===== A11y-Grundsätze für jedes Projekt =====