Thema: accessibility
-
Farbbarrierefreie Spielsignale: Zustände nicht allein über den Farbton vermitteln
Farbe mit stabilen Symbolen, Mustern und Beschriftungen kombinieren und das vollständige Signal in der tatsächlichen Spielgrösse testen, statt sich allein auf ein Paletten-Preset zu verlassen.
-
Lokalisierungsfähige Oberflächen: Intl-Pluralregeln, Datumsformate und Rechts-nach-links-Layout
Zahlen, Daten und relative Zeitangaben mit den Intl-Objekten des Browsers formatieren statt mit Zeichenketten-Arithmetik, Pluralformen anhand der Kategorien von Intl.PluralRules statt anhand von n == 1 wählen, mit logischen CSS-Eigenschaften layouten, damit sich ein dir=rtl-Dokument selbst spiegelt, und Platz für Text lassen, der bei der Übersetzung länger wird.
-
Lesbarer Fliesstext: Zeilenlänge, Zeilenabstand und Kontrast
Drei Eigenschaften entscheiden, ob langer Text bequem lesbar ist: die Zeilenlänge (das AAA-Kriterium der WCAG deckelt sie bei 80 Zeichen), der Zeilenabstand (mindestens das 1,5-Fache der Schriftgrösse muss möglich sein, ohne dass das Layout bricht) und der Kontrast (4,5:1 für normalen Text, 3:1 für grossen). In relativen Einheiten setzen, damit Nutzende Text vergrössern und neu spationieren können.
-
SVG-Icons: Inline-Markup, ein Sprite mit use, oder ein img-Element
Inline-SVG lässt sich mit currentColor und CSS stylen, wiederholt aber bei jedem Vorkommen dieselben Bytes; ein Sprite vom gleichen Origin, referenziert mit use, wird einmal gecacht und folgt trotzdem der Textfarbe; ein img ist cachebar, aber für CSS undurchsichtig. Je nach Rolle des Icons wählen, dekorative Icons vor assistiven Technologien verbergen, und jedes Icon mit fester Grösse versehen, damit nichts verrutscht, während das Sprite lädt.
-
Lesbarer Fliesstext: Zeilenlänge, Zeilenhöhe und Kontrast
Drei Eigenschaften entscheiden, ob sich langer Text bequem lesen lässt: die Zeilenlänge (das AAA-Kriterium der WCAG begrenzt sie auf 80 Zeichen), der Zeilenabstand (mindestens das 1,5-Fache der Schriftgrösse muss möglich sein, ohne das Layout zu zerstören) und der Kontrast (4.5:1 für normalen Text, 3:1 für grossen Text). Diese Werte in relativen Einheiten setzen, damit Nutzende den Text vergrössern und neu beabstanden können.
-
Dark Mode mit prefers-color-scheme, color-scheme und light-dark()
Dark Mode besteht aus drei Teilen: der Media Query prefers-color-scheme, um die Wahl der Nutzenden zu erkennen, der Eigenschaft color-scheme (und dem Meta-Tag), um dem Browser mitzuteilen, welche Schemata die Seite unterstützt, damit Formularelemente, Scrollbalken und die Zeichenfläche folgen, sowie light-dark() oder Custom Properties, um Palettenwerte auszutauschen, ohne Regeln zu verdoppeln.
-
Stabile Selektoren und Auto-Waiting in Browser-End-to-End-Tests
Zwei Ursachen dominieren flackernde Browser-Tests: Selektoren, die brechen oder das falsche Element treffen, und Sleeps, die von einem angenommenen Timing ausgehen. Elemente über Rolle, Label oder Test-ID auffinden, jeden Locator auf genau ein Element treffen lassen und über wiederholende Assertions und Actionability-Prüfungen synchronisieren statt über Zeit.
-
Barrierefreie Formulare: Labels, Fehlermeldungen und Autocomplete
Jedem Steuerelement ein über for und id verknüpftes Label geben, Pflichtfelder im Text und über das Attribut kennzeichnen, Autocomplete-Tokens verwenden, damit Browser und assistive Technologien den Zweck eines Feldes kennen, und Fehler in einer Zusammenfassung plus feldbezogenen, über aria-describedby verknüpften Meldungen melden.
-
dialog versus popover: modales Verhalten, der Top Layer und Light Dismiss
dialog mit showModal() ist modal: Top Layer, inerte Seite, ::backdrop, Escape, closedby und form method=dialog; das popover-Attribut macht ein beliebiges Element zu einem nicht-modalen Top-Layer-Overlay, das ein Button ohne Skript umschaltet und das im auto-Zustand per Light Dismiss geschlossen wird. dialog für blockierende Eingabeaufforderungen und Formulare einsetzen, popover für Menüs, Tooltips und Toasts.
-
Untertitel und Captions in Spielen: Bedeutung, Timing und Lesbarkeit erhalten
Dialoge und bedeutsame Geräuschereignisse als zeitgesteuerte Cues abbilden, Überlappungen bewusst behandeln und eine gut lesbare Darstellung bereits vor der ersten gesprochenen Szene anbieten.
-
Was erwarten Personen, die reduzierte Bewegung aktivieren: dass alle Animation entfernt wird, grosse Bewegung oder nur Autoplay?
Offene Frage: Die Einstellung für reduzierte Bewegung sagt reduce, nicht none, und Leitlinien empfehlen, kleine bedeutungstragende Übergänge zu behalten und Parallax, Zooms und Autoplay zu entfernen; gibt es Belege dafür, was Nutzerinnen und Nutzer, die die Einstellung aktivieren, tatsächlich wollen, und ob sich ihre Erwartungen je nach Grund unterscheiden (vestibuläre Störung, Ablenkung, Akkulaufzeit, Vorliebe)?
-
ARIA-Rollen: warum ein natives HTML-Element einem div mit Rolle überlegen ist
Die erste Regel des W3C für den Einsatz von ARIA lautet, ein natives HTML-Element oder -Attribut zu bevorzugen, das die benötigte Semantik und das Verhalten bereits mitbringt; ARIA ändert nur, was assistiven Technologien mitgeteilt wird, nie, was das Element tatsächlich tut. Ein div mit role=button braucht Fokussierbarkeit, Tastaturbehandlung und Zustände weiterhin von Hand hinzugefügt, und jeder Fehler dabei bleibt im visuellen Test unsichtbar.
-
Tastaturnavigation in zusammengesetzten Widgets: Roving Tabindex, Pfeiltasten und Escape
Tab und Umschalt+Tab bewegen sich zwischen Komponenten; Pfeiltasten bewegen sich innerhalb einer Komponente wie einer Tab-Liste, Symbolleiste, einem Menü oder einer Radiogruppe. Umsetzen lässt sich das mit einem Roving Tabindex (ein Element mit tabindex=0, alle übrigen mit -1) oder mit aria-activedescendant; vorübergehende Oberflächen mit Escape schliessen und den Fokus nie ohne angekündigten Ausweg einsperren.
-
Fokus-Management bei Single-Page-Interaktionen: Dialoge, Routenwechsel und entfernte Elemente
Ändert sich eine Seite ohne vollständigen Ladevorgang, muss der Tastaturfokus gezielt bewegt werden: in einen Dialog hinein, wenn er sich öffnet, und zurück zu seinem Auslöser, wenn er sich schliesst, zur Überschrift der neuen Ansicht nach einem clientseitigen Routenwechsel, und zu einem sinnvollen Nachbarn, wenn das fokussierte Element gelöscht wird. Andernfalls fällt der Fokus auf den Document Body zurück, und Screenreader-Nutzende werden an den Seitenanfang zurückgeschickt.
-
prefers-reduced-motion: Welche Animationen reduziert werden sollten und wie
Das Media-Feature prefers-reduced-motion gibt an, ob der Nutzer das Betriebssystem um weniger Bewegung gebeten hat; seine Werte sind no-preference und reduce. Es wird respektiert, indem grosse Bewegungen (Parallax, Zooms, Slides, automatisch startende Animationen) durch Überblendungen oder sofortige Wechsel ersetzt werden, während kleine bedeutungstragende Zustandsübergänge erhalten bleiben; dieselbe Regel gilt auch für skriptgesteuerte Animation.
-
Unity Input Action Maps: Kontexte, Control Schemes und persistentes Rebinding
Semantische Actions nach Spielkontext ordnen, Geräteschemata von der Aktivierung der Maps trennen und dem Rebinding einen vollständigen Lebenszyklus geben.
-
Barrierefreiheit: die vier WCAG-Grundsätze praktisch angewendet
Die WCAG 2.2 ordnen alle Erfolgskriterien vier Grundsätzen zu: wahrnehmbar, bedienbar, verständlich, robust. Wer pro Grundsatz die häufigsten Verstösse kennt (fehlende Textalternativen, Tastaturfallen, zu wenig Kontrast, unbeschriftete Felder, zu kleine Ziele), findet viele Barrieren ohne Spezialwerkzeug; Stufe AA ist das übliche Ziel.
-
Welcher Anteil der bei manuellen Audits oder durch Nutzende gefundenen Barrierefreiheitsmängel hatte die automatisierten Prüfungen in der CI bestanden, und welche Arten entgingen ihnen?
Offene Frage: Die W3C-WAI-Anleitung zu Evaluationswerkzeugen hält fest, dass sich manche Barrierefreiheitsprüfungen nicht automatisieren lassen und manuelles Eingreifen erfordern; bei Websites, die bei jedem Build einen automatisierten Prüfer laufen lassen, welcher Anteil der später bei einem manuellen Audit gefundenen oder von Nutzenden gemeldeten Mängel diesen Prüfer bestanden hatte, und welche Mängeltypen machen diese Lücke aus?
-
Touch-Zielflächen und Zeigertypen: Bedienelemente für Finger und Maus dimensionieren
WCAG 2.2 verlangt auf Stufe AA Zeiger-Zielflächen von mindestens 24 mal 24 CSS-Pixeln, mit Ausnahmen für Abstand, Inline-Links und gleichwertige Bedienelemente, und 44 mal 44 auf Stufe AAA. Die Media Features pointer und hover melden, ob die primäre Eingabe grob oder fein ist und ob sie hovern kann, sodass ein Design Bedienelemente vergrössern und reine Hover-Interaktionen weglassen kann, wo der Finger der Zeiger ist.
-
Grundlagen der Barrierefreiheit: wahrnehmbar, bedienbar, verständlich, robust
WCAG ordnet Anforderungen unter vier Prinzipien; die häufigsten Fehler auf Content-Websites sind fehlende Textalternativen, reine Farbsignale, Tastaturfallen, niedriger Kontrast und unbeschriftete Bedienelemente.
Maschinenlesbar: JSON