- Home
- Das Projekt
- Projektpartner
- Presse und Publikationen
- Veranstaltungen
- Downloads
- Kontakt
- Nachricht
- Intern

Stellen Sie sich Tom vor. Tom tippt gern live. Er hat einen leichten Tremor in der Hand. Die Quote kippt. Er hat zehn Sekunden. Der Button ist klein. Der Fokus springt. Die Zeit rennt. Am Ende platziert er die Wette nicht. Ärger. Verlust. Und das nur, weil die Oberfläche nicht für ihn gebaut ist.
Barrierefreiheit löst genau solche Fälle. Sie macht das Produkt nicht „schöner“, sondern nutzbar. Für mehr Menschen. In Stress. Auf kleinen Screens. Mit Hilfstechnik. Und ja: Ein inklusives Interface spart Support‑Zeit, senkt Abbrüche und schafft Vertrauen. Wer spielt, soll nicht kämpfen – weder mit Texten noch mit Buttons.
Barrierefreiheit heißt: Inhalte sind wahrnehmbar, bedienbar, verständlich und robust. Nicht nur für Menschen ohne Einschränkung. Auch bei wenig Licht. Mit Screenreader. Mit Tastatur. Mit kognitiver Last. Im Live‑Modus.
Die Basis dafür sind die WCAG 2.2 Richtlinien. Sie sind der Standard für Web‑Zugänglichkeit. Doch Regeln allein reichen nicht. In der Praxis zählt, wie sich eine Wette in zehn Sekunden mit Tastatur machen lässt. Wie sich ein KYC‑Formular ohne Maus ausfüllen lässt. Wie ein Fehler klar klingt und zugleich lesbar ist.
Merksatz: „Schön“ ist nett. „Bedienbar“ bringt Umsatz. Und schützt vor Frust.
In der EU setzt der European Accessibility Act den Ton. Er stellt Regeln für digitale Dienste auf. Glücksspiel‑Anbieter, Zahlungs‑Drittanbieter, Geräte‑Shops und App‑Stores sind Teil der Kette. Wer jetzt baut, sollte sich daran ausrichten, um nicht später teuer zu sanieren.
Als technischer Maßstab gilt EN 301 549. Er übersetzt Accessibility in prüfbare Punkte für Web, Software und Apps. Für Teams ist das ein guter Prüf‑Spiegel: Von Farben bis Fokus, von Medien bis Authentifizierung.
In Deutschland verweist der Staat auf die BITV 2.0 in Deutschland. Sie gilt für die öffentliche Hand. Für private Anbieter ist sie ein De‑facto‑Standard. Wer hier sauber arbeitet, senkt rechtliche Risiken und gewinnt Reputations‑Vorteile. Markt und Nutzer danken es.
1) Sehbehinderung: Ein User mit schwacher Sicht prüft Quoten. Grau auf hellgrau ist kaum lesbar. Lösung: Hoher Kontrast (mind. 4.5:1), flexible Schriftgröße, stabile Lesereihenfolge. Testen Sie mit einem Kontrast-Checker. Bei Live‑Updates darf der Fokus nicht springen, Screenreader brauchen klare Labels und Reihenfolge.
2) Motorische Einschränkungen: Ein User klickt oft neben den Button. Lösung: Große Klick‑Ziele, klare Abstände, Schutz vor Fehlklick (z. B. „Rückgängig“), Tastatur‑Flows mit sichtbarem Fokus. Rollen und Muster gemäß WAI-ARIA Muster helfen bei Menüs, Dialogen und Tabs.
3) Kognitive Barrieren: Ein Formular mit vielen Feldern überfordert. Lösung: Einfache Sprache, Infos in kleinen Schritten, klare Hilfe direkt im Feld, konsistente Reihenfolge. Keine Fach‑Jargon‑Wände. Eine kurze Zusammenfassung vor dem Abschicken hilft.
4) Gehörlosigkeit/Schwerhörigkeit: Ein Live‑Stream setzt auf Ton‑Signale. Lösung: Untertitel mit Zeitstempel, visuelle Hinweise bei Quoten‑Änderung und Gewinnen. Keine Info nur per Ton.
5) Photosensitive Epilepsie: Schnelles Blinken oder starke Animation kann gefährlich sein. Lösung: „Bewegung reduzieren“ respektieren, Animationen optional, keine schnellen Flashes. Belohnungen als ruhige Motion oder statisch zeigen.
6) Farbenblindheit: Nur rot/grün für Status? Das ist riskant. Lösung: Immer auch Symbole oder Text einsetzen. Quoten‑Anstieg/‑Fall nicht nur mit Farbe zeigen, sondern mit Pfeilen oder Icons plus Ton/Screenreader‑Hinweis.
Kurz notiert: Auto‑Play und starkes Blinken sind nicht nur schlechtes UX. Für manche Nutzer sind sie gesundheitlich heikel. Bieten Sie klare Optionen, und schalten Sie aggressive Effekte ab Werk aus.
Gute Muster sparen Zeit und Fehler. Sichtbarer Fokus für alle interaktiven Elemente. Logische Tab‑Reihenfolge. Klarer Zustand für Hover, Fokus, Aktiv. Leserichtung in DOM und Screenreader passt zur visuellen Richtung.
Setzen Sie sinnvolle ARIA‑Rollen nur dann, wenn nativ nicht reicht. Status‑Meldungen (z. B. Wett‑Slip aktualisiert) kommen über „aria‑live“ in ruhiger Priorität. Fehler sind konkret: „Die IBAN hat 19 Zeichen. Ihre Eingabe hat 17.“ statt „Ungültig“. Mehr dazu liefert die UX-Best Practices zur Barrierefreiheit der Nielsen Norman Group.
Captchas? Nutzen Sie barrierefreie Alternativen. Besser: Risiko‑Modelle im Hintergrund. Wenn Captcha nötig ist, bieten Sie Audio‑Varianten und einen klaren Support‑Pfad. Microcopy führt mit einfachen Worten durch jeden Schritt.
Kurz notiert: „Fitts’sches Gesetz“ heißt: Kleine Ziele sind schwer zu treffen. Machen Sie den „Wette platzieren“‑Button groß, mit genug Rand. Das senkt Fehlklicks sofort.
KYC ist oft der Härtetest. Erlauben Sie Upload per Klick, nicht nur Drag‑and‑Drop. Beschreiben Sie erlaubte Formate in Klartext. Zeigen Sie Upload‑Status in Text und Icon. Modale sind fokus‑sicher: Fokus geht rein und kommt auch wieder raus. Zeitlimits? Machen Sie sie verlängerbar. Ein Fortschrittsbalken zeigt, wie weit der Nutzer ist.
Bei Zahlungen gilt: Kein Fokus‑Verlust, wenn sich der Preis oder die Gebühr ändert. Screenreader hören klare Rückmeldungen: „Zahlung angenommen. Referenz: 1234.“ 2FA muss auch ohne Smartphone‑App gehen, z. B. per SMS oder FIDO‑Key mit Screenreader‑Support.
Öffentliche Stellen zeigen gute Muster. Ein Blick ins Service-Design für alle hilft, Formulare und Fehlertexte alltagstauglich zu bauen.
RG‑Funktionen müssen alle erreichen können. Limits, Reality‑Checks, Pausen, Selbstsperre – alles per Tastatur, per Screenreader, ohne versteckte Menüs. Sprache ist klar: „Du hast heute 50 € gesetzt. Möchtest du eine Pause? 5, 15 oder 60 Minuten?“
Hilfs‑Infos sollten leicht zu finden sein, nicht nur im Footer. Gute Ressourcen bietet Responsible-Gambling-Ressourcen. Und technische Leitplanken nennen die technische Standards der UK Gambling Commission.
Viele Nutzer kommen nur über das Smartphone. Testen Sie mit VoiceOver (iOS) und TalkBack (Android). Respektieren Sie Dynamic Type. Nutzen Sie klare Labels und sinnvolle Reihenfolge. Prüfen Sie „Bewegung reduzieren“ und haptisches Feedback. Apple listet die iOS-Features gut auf.
Für Android gilt Ähnliches. Prüfen Sie die Android-Features. Denken Sie an Gesten‑Alternativen: Jeder Swipe braucht eine zweite Bedien‑Art, z. B. Buttons. Scrollende Ticker? Machen Sie sie pausierbar.
Automatisierte Prüfungen (z. B. axe, Lighthouse) fangen typische Fehler ab: Kontrast, Alternativ‑Texte, Rollen. Doch echte Qualität kommt mit manuellen Tests: Tastatur‑Only, Screenreader (NVDA/JAWS/VoiceOver), reduziertes Motion, Zoomen auf 200 %.
Lernen und prüfen gehen Hand in Hand. Gute Test- und Lernressourcen liefert Deque University. Für Team‑Know‑how sind Zertifizierungen & Standards der IAAP hilfreich. Messen Sie reale Flows: „Wette platzieren“, „Einzahlen“, „Auszahlen“. KPIs: Fehlversuche, Abbrüche, Support‑Tickets, Zeit bis Abschluss.
Priorisieren Sie nach Risiko und Häufigkeit. Live‑Wette hat Vorrang vor seltenen Einstellungen. Fixen Sie zuerst Hürden, die den Abschluss blockieren. Dann optimieren Sie Komfort.
| Sehen (niedrige Sicht) | Live‑Quoten, Wett‑Slip | Kontrast ≥ 4.5:1, flexible Schrift, stabile DOM‑Reihenfolge | 1.4.3, 1.4.4 | Kontrast‑Checker, Zoom 200 %, Screenreader | Hoch; Lesefehler, Abbrüche |
| Blind (Screenreader) | Navigation, Dialoge, Status | ARIA‑Rollen, aria‑live, sinnvolle Landmarken | 1.3.1, 4.1.2 | NVDA/JAWS/VoiceOver, Tastatur‑Only | Hoch; Time‑to‑Task, Support‑Tickets |
| Hören | Live‑Streams, Gewinn‑Signale | Untertitel, visuelle Hinweise, kein Ton‑Only | 1.2.x | Untertitel‑Check, Stumm‑Test | Mittel; Fehl‑Feedback |
| Motorik | Buttons, Slider, Formulare | Große Hit‑Zonen, Fokus‑States, Undo | 2.1.1, 2.5.5 | Tastatur‑Only, Fitts‑Abstände | Hoch; Fehlklick‑Quote |
| Kognition | KYC, Zahlungen, RG | Einfache Sprache, Schritt‑für‑Schritt, klare Hilfe | 3.1.x, 3.3.x | Usability‑Test, Lesbarkeits‑Check | Hoch; Form‑Abbrüche |
| Epilepsie | Banner, Jackpots, Animation | Bewegung reduzieren, keine schnellen Flashes | 2.3.x | Visuell prüfen, Motion‑Einstellung | Mittel; Beschwerden |
| Farbenblindheit | Status, Quoten hoch/runter | Symbol + Text, nicht nur Farbe | 1.4.1 | Grayscale‑Test, Nutzer‑Test | Hoch; Fehlinterpretation |
| Sprache | RG‑Hinweise, Fehlertexte | Klartext, kurze Sätze, Beispiele | 3.1.5 | Content‑Review, A/B‑Test | Mittel; Verständnis |
| Mobile Nutzung | Live‑Wette, Kasse | Dynamic Type, Touch‑Ziele, Gesten‑Alternativen | 1.4.4, 2.5.x | Geräte‑Tests, VoiceOver/TalkBack | Hoch; Conversion |
| Stress/Tempo | In‑Play, Quoten‑Sprung | Stabile UI, Undo, klare Rückmeldungen | 2.2.1, 3.2.2 | Time‑Box‑Tests, Heuristik | Hoch; Fehlbedienung |
Mehr Kriterien im WCAG Überblick.
Sportwetten haben harte Zeitfenster. Quoten springen. Ein falscher Fokus‑Sprung ist hier fatal. Anzeigen Sie Änderungen ruhig, aber klar. Keine DOM‑Sprünge. Und geben Sie ein kurzes Zeitfenster für „Rückgängig“.
Im Live‑Casino sind es eher Banner, Animationen und akustische Effekte. Sparen Sie mit Effekten. Bieten Sie einen Reduzieren‑Schalter. Gewinne feiern? Gern – aber mit Text und ruhiger Animation, nicht nur mit Sound.
Achten Sie auf klare RG‑Seiten, eine einfache Sprache und eine sichtbare Accessibility‑Erklärung. Testen Sie die Tab‑Reihenfolge. Prüfen Sie Kontrast. Probieren Sie Screenreader kurz aus. Gibt es eine Demo oder Gast‑Modus? Das sind gute Zeichen.
Hilfreich ist eine kuratierte Übersicht, die genau darauf schaut: Tastaturnutzung, Kontrast, Labels, RG‑Funktionen, mobile Qualität. Eine Liste zu mobilen Angeboten finden Sie bei apps de casino online (externer Link, Spanisch). So sehen Sie, wie Anbieter ihre Apps umsetzen und wo mobile Hürden liegen.
Welche WCAG‑Kriterien sind für Glücksspiel besonders kritisch?
Vor allem 1.4.3 (Kontrast), 2.1.1 (Tastatur), 2.2.1 (Zeit), 2.3.x (Flashes), 3.3.x (Fehlerhilfe) und 4.1.2 (Name, Rolle, Wert). Sie decken Lesen, Bedienen, Tempo, Sicherheit und Status ab.
Wie teste ich Live‑Wetten auf Barrierefreiheit?
Nutzen Sie Tastatur‑Only, Screenreader, Zoom 200 %, „Bewegung reduzieren“ und echte Geräte. Beobachten Sie, ob Fokus springt, ob Updates lesbar sind und ob ein Undo möglich ist.
Gibt es eine rechtliche Pflicht in der EU für private Glücksspiel‑Anbieter?
Es gibt wachsenden Druck durch den EAA und Markt‑Standards wie EN 301 549. Zudem drohen Reputations‑Schäden und rechtliche Risiken, wenn Nutzer ausgeschlossen werden.
Zählt Responsible Gambling wirklich zur Barrierefreiheit?
Ja. RG‑Funktionen müssen alle erreichen und verstehen. Sonst helfen sie nicht. Gute Hinweise und Beispiele bietet die RNIB – Design for Everyone für sehfreundliches Design.
Barrierefreiheit macht Glücksspiel‑Plattformen fairer, klarer und schneller. Sie stärkt Conversion, hält Nutzer länger, senkt Support und schützt vor Risiken. Wer heute inklusiv baut, spart morgen teure Nacharbeit. Und das Wichtigste: Alle können sicher und selbstbestimmt spielen – ohne Hürden.
Dieser Leitfaden entstand in einer Redaktion mit Fokus auf UX und Barrierefreiheit. Wir prüfen Produkte, sprechen mit Nutzerinnen und Nutzern und testen mit Hilfs‑technik. Unser Ziel: klare, einfache, nutzbare Lösungen – auch unter Zeitdruck.