Start / Seminare / Modern UI und UX Engineering für Webanwendungen
Modul
Visuelle und responsive Accessibility
9 Kapitel in diesem Modul-Video · Laufzeit
Transkript
Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.
Visuelle und responsive Accessibility
0:00 In Modul fünf haben wir Gestaltungsentscheidungen getroffen — über Farbe, Kontrast, Zielgrößen und Bewegung. Damals habe ich Ihnen versprochen, dass die konkreten Werte später kommen. Hier sind sie. Dieses Modul liefert die Prüfwerte zu den Regeln von damals, und das ist der Grund, warum es das letzte von Tag zwei ist: Alles hier ist messbar.
0:20 Nicht diskutierbar, nicht Geschmackssache — messbar. Und genau deshalb ist es der beste Übergang zu Tag drei, an dem wir aus diesen Messgrößen Prüfverfahren machen. Am Ende prüfen Sie eine Seite unter fünf verschiedenen Bedingungen.
Visuelle und responsive Accessibility
0:35 Neun Kapitel, und sie sind sortiert nach der Art der Wahrnehmung. Erst zweimal Farbe: Kontrastwerte und die Regel, dass Farbe nie allein trägt. Dann Größe und Fläche — Reflow bei starker Vergrößerung und Zielgrößen. Dann drei Systemeinstellungen: reduzierte Bewegung und die erzwungenen Farbmodi. Und zum Schluss zwei Kapitel über Medien: Icons und Diagramme, dann Untertitel und Transkripte.
0:59 Die Übung am Ende ist eine, die ich Ihnen als Dauereinrichtung im Team empfehle — fünf Bedingungen, fünf Blickwinkel, in fünfzig Minuten.
Farbkontraste
1:09 Fangen wir mit dem an, was am häufigsten geprüft und am schlechtesten verstanden wird: Kontrastwerte. Es gibt drei Zahlen, sie sind schnell gemerkt, und die Fallen liegen nicht in den Zahlen. Drei Werte, mehr müssen Sie nicht wissen. Normaler Text braucht ein Verhältnis von mindestens vier Komma fünf zu eins. Große Schrift kommt mit drei zu eins aus, weil dickere Buchstaben leichter zu erkennen sind.
1:32 Und Bedienelemente samt ihren Zuständen brauchen ebenfalls drei zu eins — das ist der Wert, der am häufigsten fehlt, weil viele nur den Text prüfen. Wichtig ist der zweite Satz: Geprüft wird gegen die tatsächliche Hintergrundfarbe, auch bei Verläufen und Bildern. Und deaktivierte Elemente sind ausgenommen — das ist eine Ausnahme, die gern zur Ausrede für völlig unlesbare Zustände wird.
1:56 Die rechte Spalte ist Ihre Prüfliste, denn dort stehen die Stellen, an denen es tatsächlich schiefgeht. Hinweistexte in Grau — das ist die Nummer eins, weil Grau ja zurückhaltend wirken soll. Überschriften auf Farbflächen, weil dort nur die Fläche geprüft wurde, nicht die Kombination. Rahmen von Eingabefeldern, weil das viele gar nicht als prüfpflichtig auf dem Schirm haben — es ist aber ein Bedienelement.
2:19 Und der Fokus auf farbigem Grund, was uns zu den Tokens aus Modul sechs zurückbringt: Wenn der Fokusindikator ein Token ist, prüfen Sie ihn einmal gegen alle relevanten Untergründe und sind fertig. Der erste Stolperstein ist ein Messfehler: gegen Weiß prüfen, obwohl das Element auf einer Farbfläche liegt. Das passiert automatisch, wenn man Farbwerte aus dem Entwurfswerkzeug in ein Prüfwerkzeug tippt statt am gerenderten Element zu messen.
2:46 Der zweite ist ein Vollständigkeitsfehler: nur den Ruhezustand prüfen. Hover, Fokus und Fehler haben eigene Farben — und die sind oft schwächer, weil sie „nur" Zwischenzustände sind. Und der dritte ist die eben erwähnte Ausrede: aus der Ausnahme für Deaktiviertes eine Erlaubnis für Unlesbarkeit machen. Formal zulässig, praktisch schlecht.
3:06 Wer nicht lesen kann, was deaktiviert ist, weiß nicht, was ihm fehlt.
Information nicht nur über Farbe
3:11 Jetzt kehrt eine Folie aus Modul fünf zurück — dort war sie eine Gestaltungsregel, hier ist sie ein Prüfkriterium. Und die Prüfung dauert zwei Minuten. Nehmen wir die verspätete Fahrt bei Fahrtwind, erkennbar an einer roten Zeile. Für wen geht diese Aussage verloren? Für Menschen mit Farbfehlsichtigkeit — das ist etwa jeder zwölfte Mann. Beim Schwarzweißausdruck, den Reisegruppen tatsächlich noch machen.
3:37 Bei starker Sonneneinstrahlung am Bahnsteig, also genau in unserem Nutzungskontext aus Modul zwei. Und bei jedem, der einen alten oder schlecht kalibrierten Bildschirm hat. Die Lösung ist immer dieselbe und immer einfach: eine zweite Codierung. Ein Symbol, eine Beschriftung, ein Muster oder eine Position. Die Farbe darf bleiben — sie darf nur nicht allein tragen.
4:00 Fünf Schritte, und die ganze Prüfung dauert wenige Minuten. Sie betrachten die Seite in Graustufen — jeder Browser kann das über die Entwicklerwerkzeuge, alternativ tut es ein Schwarzweißausdruck. Dann notieren Sie jede Stelle, an der eine Aussage verschwindet. Für jede wählen Sie eine zweite Codierung. Und dann kommt Schritt vier, der laut Fußzeile Gestaltung von Barrierefreiheit unterscheidet: Prüfen Sie, ob die zweite Codierung auch im Accessibility Tree ankommt.
4:28 Ein Symbol ohne zugänglichen Namen hilft nur beim Sehen — für Screenreader-Nutzende ändert sich gar nichts. Zum Schluss noch einmal in Graustufen gegenlesen. Der erste Stolperstein sind die beliebtesten Farben überhaupt: Ampelfarben verwenden, ohne Rot und Grün zusätzlich zu benennen. Ausgerechnet diese beiden sind die häufigste Farbsehschwäche — die Ampelmetapher funktioniert für viele Menschen gerade nicht.
4:52 Der zweite ist die halbe Lösung aus Schritt vier: ein Symbol ergänzen und ihm keinen zugänglichen Namen geben. Sieht dann in Graustufen gut aus und ist im Baum weiterhin leer. Und der dritte kennen Sie aus Modul elf: Pflichtfelder allein über die Rahmenfarbe kennzeichnen. Das Pflicht-Attribut ist eine Zeile und meldet es zuverlässig.
Reflow, Zoom bis 400 Prozent und Orientierung
5:12 Jetzt zu einem Test, der viele überrascht — sowohl positiv als auch negativ. Bei starker Vergrößerung wird aus Ihrem Desktoplayout faktisch ein mobiles. Wer responsiv baut, besteht meist automatisch. Zwei Anforderungen, die zusammenhängen. Text muss sich auf zweihundert Prozent vergrößern lassen, ohne dass Inhalt verloren geht.
5:33 Und der Inhalt muss bei dreihundertzwanzig CSS-Pixeln Breite umbrechen, ohne dass horizontal gescrollt werden muss. Diese dreihundertzwanzig Pixel sind genau das, was von einem gewöhnlichen Desktopfenster bei vierhundert Prozent Zoom übrig bleibt — deshalb der Titel. Wenn das scheitert, sind die Ursachen fast immer dieselben drei: feste Höhen, absolute Positionierung und Text, der in Grafiken eingebacken ist.
5:57 Und noch eine Anforderung: Kein Inhalt darf auf eine Bildschirmausrichtung festgelegt sein. Oben zwei Muster, die den Test zuverlässig nicht bestehen. Eine feste Höhe schneidet Text ab, sobald er umbricht — und bei Vergrößerung bricht alles um. Eine feste Breite in Pixeln erzwingt horizontales Scrollen. Und die Regel, die an der Bildschirmausrichtung hängt, ist ein eigenes Problem: Ein Tablet in einer festen Halterung — am Rollstuhl, an der Wand — dreht sich nicht mit.
6:26 Wer eine Ansicht auf Querformat festlegt, schließt diese Menschen aus. Unten die Gegenstücke: eine Mindesthöhe statt einer festen Höhe, eine Maximalbreite in relativen Einheiten. Zwei Wörter geändert, Test bestanden. Der erste Stolperstein ist der häufigste Einzelgrund für abgeschnittenen Text: feste Höhen setzen. Sie sehen im Entwurf gut aus, weil der Beispieltext genau passt — bei längerem Text oder größerer Schrift bricht es.
6:52 Der zweite ist der eben genannte: Layouts an die Bildschirmausrichtung binden. Denken Sie an fest montierte Geräte, das ist kein Randfall. Und der dritte ist ein Prüffehler, den wir schon aus Modul fünf kennen: nur die Breakpoints prüfen und die Zwischenbereiche auslassen. Ziehen Sie das Fenster langsam schmaler und beobachten Sie. Die kaputten Zustände liegen zwischen den Sprungpunkten.
Zielgrößen und Abstände
7:15 Jetzt ein Kriterium aus Version 2.2 mit einer konkreten Zahl — und mit einem eleganten Trick, wie man es erfüllt, ohne die Gestaltung zu verändern. Die Anforderung lautet: vierundzwanzig mal vierundzwanzig CSS-Pixel für Bedienelemente, oder alternativ ausreichender Abstand zu den Nachbarn. Das ist der Mindestwert; empfehlenswert ist deutlich mehr, üblich sind vierundvierzig Pixel als Zielgröße.
7:39 Und die typischen Verstöße sind so vorhersehbar, dass Sie sie in Ihrem Projekt sofort finden werden: kleine Schließkreuze, dicht gesetzte Seitenzahlen und Icon-Reihen in Tabellenzeilen. Alle drei kommen bei Fahrtwind vor, und alle drei kommen in fast jeder Verwaltungsoberfläche vor. Der Grund ist immer derselbe — entworfen und getestet wurde mit einem Mauszeiger, der pixelgenau trifft.
8:02 Hier kommt der Trick, der das häufigste Gegenargument entkräftet. Der Einwand lautet: „Dann sehen die Symbole plump aus." Muss aber gar nicht. Oben ist die Schaltfläche exakt so groß wie das Symbol — sechzehn Pixel, unmöglich zu treffen. Unten wächst die Trefferfläche auf vierundvierzig Pixel, während das Symbol darin zentriert und unverändert klein bleibt. Optisch ändert sich fast nichts, praktisch alles.
8:26 Das ist eine Änderung an einer Stelle im Design System, wenn Sie die Zielgröße als Token führen — und dann wirkt sie überall, ganz wie in Modul sechs beschrieben. Der erste Stolperstein begleitet uns seit Modul fünf: die Zielgröße am Mauszeiger bemessen statt am Finger. Ein Mauszeiger ist ein Punkt, eine Fingerkuppe etwa einen Zentimeter breit. Der zweite ist die Alternative, die vergessen wird: Icon-Reihen ohne Abstand setzen.
8:52 Sie können die Größe nämlich auch über Abstand erfüllen — nur wird beides gleichzeitig unterschritten, wenn fünf Symbole aneinanderkleben. Und der dritte ist die naive Umsetzung des Kriteriums: nur die sichtbare Grafik vergrößern statt der Trefferfläche. Dann haben Sie plumpe Symbole und die Gestaltungsdiskussion, die Sie mit dem eben gezeigten Muster vermieden hätten.
Reduzierte Bewegung respektieren
9:14 Weiter zu einer Systemeinstellung, die Menschen bewusst setzen — und über die wir in Modul fünf schon gesprochen haben. Hier geht es darum, was sie praktisch bedeutet. Die Medienabfrage für reduzierte Bewegung meldet keine Vermutung, sondern eine bewusste Einstellung. Jemand hat in seinem Betriebssystem gesagt: Ich will weniger Bewegung.
9:34 Meist, weil ihm sonst schwindelig wird. Wer diese Abfrage auswertet, ersetzt Parallaxe und aufwendige Übergänge durch schlichte Ein- und Ausblendungen. Und ich betone es noch einmal, weil ich es für wichtig halte: Vestibuläre Beschwerden sind kein Randfall — nach verschiedenen Schätzungen ist ein spürbarer Anteil der Bevölkerung betroffen, viele davon vorübergehend.
9:56 Die Umsetzung kostet fünf Zeilen. Das Verhältnis von Aufwand zu Nutzen ist selten so eindeutig. Vier Konkretisierungen. Keine Parallaxe, keine großflächigen Verschiebungen, kein automatischer Bildlauf — das sind die drei stärksten Auslöser. Übergänge dürfen bleiben, sollen aber kurz sein und ohne Ortsveränderung; das ist genau die Balance aus Modul fünf, nicht alles abzuschalten.
10:19 Automatisch startende Videos und Karussells laufen nicht von allein — auch das gehört zur Bewegungseinstellung, was viele nicht bedenken. Und der vierte Punkt ist der, der im Alltag am häufigsten scheitert: Die Einstellung gilt für die ganze Anwendung. Nicht nur für die Startseite, auf der jemand einmal daran gedacht hat.
10:38 Der erste Stolperstein ist die Übererfüllung, vor der ich schon in Modul fünf gewarnt habe: sämtliche Übergänge entfernen und dabei die Zusammenhänge verlieren. Reduziert heißt reduziert. Der zweite ist der eben genannte Vollständigkeitsfehler: die Abfrage nur auf der Startseite auswerten. Legen Sie das in Ihre Basisstile, dann gilt es überall.
10:58 Und der dritte betrifft eine Lücke, die nur in Anwendungen mit Animationsbibliotheken auftritt: Bewegung über Skript steuern und die Einstellung dort nicht abfragen. Die Medienabfrage lässt sich auch aus dem Code auslesen — tun Sie das, sonst wirkt Ihre schöne CSS-Lösung an genau den aufwendigsten Animationen vorbei.
High-Contrast- und Forced-Colors-Modi
11:17 Jetzt ein Modus, den viele Entwickler noch nie gesehen haben — weil er im eigenen Betriebssystem nicht aktiv ist. Dabei ersetzt er die komplette Palette. Was bleibt dann von Ihrer Gestaltung übrig? In erzwungenen Farbmodi ersetzt das Betriebssystem Ihre Palette durch eine eigene, kontraststarke — meist Schwarz, Weiß und wenige Systemfarben.
11:38 Menschen nutzen das, weil sie sonst nicht lesen können. Und jetzt kommt die Konsequenz: Anwendungen, die Zustände nur über Hintergrundfarben oder Hintergrundbilder codieren, verlieren dort ihre Information komplett. Der aktive Tab sieht aus wie die anderen. Prüfen lässt sich das mit einer eigenen Medienabfrage. Und die Korrektur ist erfreulich: Sie besteht meist darin, Rahmen und Systemfarben zuzulassen — nicht darin, etwas zu überschreiben. Weniger tun statt mehr.
12:07 Oben der aktive Tab, erkennbar an seiner Hintergrundfarbe. Im erzwungenen Modus verschwindet diese Hintergrundfarbe — und damit die einzige Information darüber, welcher Tab aktiv ist. Unten die Ergänzung: Innerhalb der Abfrage für den erzwungenen Modus bekommt der aktive Tab einen Rahmen in einer Systemfarbe. Ein Rahmen überlebt, weil er zu den Elementen gehört, die der Modus erhält.
12:30 Und die Systemfarbe passt sich automatisch dem an, was der Nutzer eingestellt hat — Sie geben also keine konkrete Farbe vor, sondern eine Rolle. Vier Zeilen, und die Information bleibt. Der erste Stolperstein ist die Ursache des Problems: Zustände ausschließlich über Hintergrundfarben oder Hintergrundbilder codieren. Das ist übrigens auch außerhalb dieses Modus fragil, siehe Kapitel zwei.
12:53 Der zweite ist eine grobe Übergriffigkeit: die Anpassung pauschal abschalten und damit die Nutzereinstellung aushebeln. Setzen Sie das gezielt und nur dort ein, wo Sie eine Information sonst verlieren würden. Und der dritte ist der Grund, warum dieses Kriterium so oft durchfällt: den Modus nie testen, weil er im eigenen Betriebssystem nicht aktiv ist.
13:14 Es dauert dreißig Sekunden, ihn einzuschalten — und Sie werden überrascht sein.
Zugängliche Icons, SVGs und Diagramme
13:19 Weiter zu Grafiken. Die Grundregel ist einfach — dekoratives ausblenden, bedeutungstragendes benennen. Der häufigste Fehler entsteht ausgerechnet dann, wenn man beide Regeln kennt. Die Unterscheidung ist die halbe Miete. Ein dekoratives Icon wird für assistive Technik ausgeblendet — es trägt nichts bei, und vorgelesen wird es zu Lärm.
13:40 Ein bedeutungstragendes Icon bekommt einen Namen. Bei eingebetteten Vektorgrafiken entscheidet die Rolle darüber, ob der Inhalt überhaupt gelesen wird — das ist eine Feinheit, die viele nicht kennen und die zu sehr merkwürdigen Vorleseergebnissen führt. Und ein Diagramm braucht mehr als einen Alternativtext: eine textliche Zusammenfassung, die die Aussage nennt, und die zugrunde liegenden Daten in zugänglicher Form.
14:05 Die rechte Spalte nennt jeweils das Fehlerbild, und das ist praktisch beim Suchen. Dekoratives Icon nicht ausgeblendet: Es wird sinnlos vorgelesen, oft als kryptischer Dateiname. Bedeutungstragendes Icon ohne Namen: eine Schaltfläche ohne Namen — der Fall aus Modul acht. Und Diagramm ohne Text: eine Grafik ohne Inhalt, aus der niemand etwas entnehmen kann.
14:27 Der Vollständigkeit halber der Hinweis zum Diagramm: Die Datentabelle darf ruhig aufklappbar sein, wie in Modul vier besprochen. Sie muss nur da sein und auffindbar bleiben — und viele sehende Nutzende schätzen sie ebenfalls. Der erste Stolperstein ist der eingangs erwähnte, und er entsteht aus halbem Wissen: das einzige Kind eines Icon-Buttons ausblenden — und damit den Namen verlieren.
14:51 Man hat gelernt, dekorative Icons auszublenden, wendet die Regel an, und die Schaltfläche hat plötzlich gar keinen Inhalt mehr. Die richtige Lösung haben wir in Modul acht gesehen: Icon ausblenden und einen für Screenreader sichtbaren Text ergänzen. Der zweite: eingebettete Vektorgrafik ohne Rolle einbetten und auf gutes Vorlesen hoffen.
15:11 Und der dritte: ein Diagramm mit einem Alternativtext abtun, statt die Daten zugänglich zu machen.
Untertitel, Transkripte und Audiodeskription
15:17 Das letzte inhaltliche Kapitel betrifft Medien. Und es enthält einen Satz, der Ihnen in der Projektplanung helfen wird: Automatisch erzeugte Untertitel sind ein Entwurf, kein Ergebnis. Drei Anforderungen für drei Fälle. Videos brauchen Untertitel. Reine Audioinhalte brauchen ein Transkript. Und wo Bildinformation die Aussage trägt — eine Grafik wird gezeigt, ohne dass jemand sie beschreibt —, braucht es eine Audiodeskription oder eine gleichwertige Textfassung.
15:46 Nun zur automatischen Erzeugung: Sie ist erstaunlich gut geworden und trotzdem nicht fertig. Fachbegriffe und Eigennamen sind zuverlässig falsch — bei einem Buchungsportal wären das Ortsnamen, bei einer Fachschulung die Fachbegriffe. Das ist Nacharbeit, es kostet Zeit, und es gehört eingeplant statt hinterher entdeckt. Rechnen Sie mit etwa der Länge des Videos.
16:09 Die linke Zahlenspalte nennt das Minimum, die rechte das, was praktisch besser ist. Und die rechte Spalte lohnt eine besondere Erwähnung, denn sie nutzt allen. Ein Transkript zum Nachlesen — das nutzen auch Menschen, die schnell nach einer Stelle suchen, statt ein Video zu durchsuchen. Kapitelmarken bei reinen Audioinhalten dasselbe.
16:28 Die letzte Zeile wird oft übersehen: Auch ein stummes Video braucht eine Textalternative, sonst ist es für einen Teil Ihrer Nutzer schlicht nichts. Und wenn Sie Videos in einem Lernkontext einsetzen, ist das Transkript erfahrungsgemäß der meistgenutzte Zusatz überhaupt. Der erste Stolperstein ist der eben besprochene: automatische Untertitel ungeprüft veröffentlichen.
16:50 Das führt zu Untertiteln, die an den entscheidenden Stellen falsch sind — nämlich bei genau den Fachbegriffen, um die es geht. Der zweite ist eine Auslassung, die wenig kostet: Untertitel liefern, aber kein Transkript zum Überfliegen. Wer das Transkript ohnehin für die Untertitel erstellt hat, kann es auch veröffentlichen.
17:08 Und der dritte ist der anspruchsvollste: Bildinformation im Video nicht sprachlich mitführen. Das lässt sich oft vermeiden, indem man beim Sprechen beschreibt, was zu sehen ist — dann braucht es gar keine separate Audiodeskription.
Übung — eine Seite unter fünf Bedingungen prüfen
17:23 Zum Abschluss von Tag zwei prüfen Sie eine Seite unter fünf Bedingungen. Diese Übung eignet sich hervorragend als Dauereinrichtung im Team — sie ist kurz, sie braucht keine Spezialwerkzeuge, und sie findet viel. Sie prüfen eine Fahrtwind-Seite unter fünf Bedingungen: starker Zoom, schmale Breite, erzwungene Farben, reduzierte Bewegung, Graustufen.
17:44 Geübt wird das systematische Verändern der Darstellungsbedingungen und das Priorisieren der Befunde. Erfolgreich sind Sie, wenn zu jeder Bedingung festgehalten ist, welche Information verloren geht, und die Befunde nach Schwere und Häufigkeit priorisiert sind. Ein Hinweis aus der Erfahrung: Die Graustufenprüfung dauert zwei Minuten und findet regelmäßig am meisten.
18:05 Wenn Sie nur eine Sache aus diesem Modul in Ihren Alltag übernehmen, dann diese. Wer früh fertig ist, prüft zusätzlich im dunklen Modus. Fünf Schritte, je Bedingung einer, jeweils mit einer klaren Frage. Bei vierhundert Prozent Zoom: Was wird abgeschnitten oder verschwindet? Bei dreihundertzwanzig Pixeln Breite: Muss horizontal gescrollt werden? Im erzwungenen Farbmodus: Welche Zustände werden unkenntlich?
18:31 Bei reduzierter Bewegung: Gehen Zusammenhänge verloren? Und in Graustufen: Welche Aussage hängt allein an Farbe? Beachten Sie die Fußzeile, sie ist praktischer Rat aus vielen Durchläufen: Führen Sie je Bedingung eine eigene Notizspalte. Sammelnotizen lassen sich hinterher nicht mehr zuordnen — und dann wissen Sie nicht, welche Bedingung den Befund erzeugt hat.
18:54 Der erste Stolperstein macht die Auswertung unmöglich: alle fünf Bedingungen gleichzeitig einschalten. Sie sehen dann eine kaputte Seite und wissen nicht, woran es liegt — und die Reparatur wird zum Raten. Einzeln prüfen, immer. Der zweite ist ein Prüfumfangsfehler: nur die Startseite prüfen. Die interessanten Fälle liegen in Formularen und Fehlerzuständen, wo enge Layouts und farbige Meldungen zusammenkommen.
19:18 Und der dritte betrifft die Verwertbarkeit: Befunde notieren, ohne die betroffene Nutzergruppe zu benennen. Ohne diese Angabe lässt sich später nicht priorisieren — und für die Priorisierung ist genau sie das Argument. Vier Punkte, und damit endet Tag zwei. Kontrast wird gegen den tatsächlichen Hintergrund geprüft, in jedem Zustand — nicht gegen Weiß und nicht nur im Ruhezustand.
19:42 Bei vierhundert Prozent Zoom wird aus dem Desktoplayout faktisch ein mobiles; wer responsiv baut, besteht meist schon. Zielgrößen wachsen über die Trefferfläche, nicht über das Symbol — damit endet die Gestaltungsdiskussion. Und im erzwungenen Farbmodus überleben Rahmen, Hintergrundfarben nicht. Alles in diesem Modul ist messbar. Morgen, an Tag drei, machen wir daraus ein Verfahren — mit Prüfschritten, Werkzeugen und Berichten, die man vorlegen kann.
Lieber mit Trainer? Dieses Modul ist Teil unserer Team-Schulungen — mit Übungen, Ihrem eigenen Code und Fragen, die ein Video nicht beantwortet. Mehr erfahren →