Wer die WinHero App zum ersten Mal auf dem Smartphone öffnet, sieht eine saubere, kontrastreiche Oberfläche. Schwarze Schrift auf hellem Grund, klar abgegrenzte Schaltflächen, deutlich lesbare Beträge. Genau dieser erste Eindruck führt in die Irre. Kontrast ist eine Eigenschaft, die sich messen lässt, und die WCAG 2.2 nennt konkrete Werte: 4,5:1 für normalen Text, 3:1 für große Schrift und Bedienelemente. Ein Canvas-Slot kann diese Zahlen einhalten und trotzdem unlesbar werden, sobald jemand die Systemeinstellungen für hohen Kontrast aktiviert oder die Schrift im Betriebssystem vergrößert. Der Grund liegt in der Rendering-Technik, nicht im Design.
Die WinHero Web-App läuft im Browser, und dort treffen zwei Welten aufeinander. Lobby, Menüs und Dialoge sind HTML-Elemente. Sie übernehmen prefers-contrast, die erzwungenen Farbmodi von Windows und Android und die Schriftgrößen des Systems, weil der Browser sie als Text versteht und neu layoutet. Die eigentlichen Spielrunden laufen dagegen in einem Canvas. Was dort gezeichnet wird, ist für den Browser eine Bitmap: ein Bild mit festen Pixeln. Keine Systemeinstellung greift hinein, kein Screenreader liest einzelne Werte vor, und der einzige Ausweg für Betroffene bleibt der Browser-Zoom, der die gesamte Fläche vergrößert und dabei oft Inhalte abschneidet.
Diese Trennung ist keine Randnotiz für Accessibility-Beauftragte. Sie entscheidet, welche Teile der WinHero App tatsächlich anpassbar sind und welche nur so aussehen. Die folgende Prüfliste geht Punkt für Punkt durch, wo Kontrast endet, wo Zoom anfängt und warum die HTML-Lobby architektonisch die zugänglichere Oberfläche bleibt.
Kontrast als Grundlage: WCAG-Anforderungen an Schrift und Flächen in Spieloberflächen
Wer Spieloberflächen nach WCAG 2.2 prüft, kommt an zwei Zahlen nicht vorbei: 4,5:1 für normalen Text und 3:1 für große Schrift sowie für grafische Bedienelemente und Zustandsanzeigen. Diese Werte gelten relativ, nicht absolut. Ein Kontrast von 4,5:1 zwischen Textfarbe und Hintergrund ist die Untergrenze, nicht das Ziel. In Slots mit animierten Walzen, Glow-Effekten und Halbtransparenzen verschiebt sich das Verhältnis oft frame-genau, weil der Hintergrund hinter dem Text nicht statisch ist.
Die Formel dahinter ist simpel: (L1 + 0,05) / (L2 + 0,05), wobei L1 die relative Luminanz der helleren und L2 die der dunkleren Farbe ist. Der Haken liegt in der Messung. Ein Gewinnbetrag in Gold auf dunkelrotem Grund mag im Stillbild 5,2:1 erreichen. Sobald ein Partikel-Overlay darüberläuft oder die Ziffern ausfaden, fällt der Wert unter 3:1, und die Information ist für viele Nutzer faktisch weg. Prüfwerkzeuge, die nur Screenshots auswerten, übersehen genau diese Dynamik.
Reiner Farbkontrast hat eine zweite Grenze: Er sagt nichts über Form, Größe und Abstand. Zwei Farben mit 4,5:1 können für Menschen mit Rot-Grün-Schwäche trotzdem kaum trennbar sein, wenn nur der Farbton unterscheidet. WCAG deckt das über 1.4.1 (Farbe nicht als einziges Mittel) ab, nicht über 1.4.3. In Spieloberflächen heißt das konkret: Gewinn und Verlust brauchen zusätzlich ein Symbol, eine Textmarke oder eine Positionsänderung, nicht nur Grün gegen Rot.
Schriftgröße und Zeilenabstand als zweite Säule
Kontrast ohne lesbare Typografie bleibt Theorie. WCAG 2.2 setzt in 1.4.4 die Skalierung auf 200 Prozent ohne Informationsverlust voraus und in 1.4.12 Textabstände von mindestens 1,5-fachem Zeilenabstand, 0,12 em Absatzabstand und 0,16 em Buchstabenabstand, ohne dass Inhalte abgeschnitten werden. Für Spieloberflächen mit festen Layoutrastern ist das die eigentliche Hürde.
- Kontrast 4,5:1 für Fließtext und Kontostände, 3:1 für Überschriften ab etwa 18,66 px fett oder 24 px normal.
- 3:1 auch für Rahmen, Fokusringe, Walzenmarker und Buttons, sofern sie Zustand oder Funktion tragen.
- Textabstände nach 1.4.12 prüfen: Zeilenabstand 1,5, Absatzabstand 2 em, Buchstabenabstand 0,12 em, Wortabstand 0,16 em.
- Farbe nie als einziges Unterscheidungsmerkmal, Gewinn und Verlust zusätzlich mit Symbol oder Text.
- Kontrast bei Animation messen, nicht im Standbild: Overlays, Fades und Partikel verändern die Luminanz.
Wer diese fünf Punkte als Checkliste nimmt, hat eine belastbare Basis. Was sie nicht abdeckt, ist die Frage, ob die Oberfläche Systemeinstellungen überhaupt annimmt. Genau dort entscheidet sich, ob Kontrastarbeit im Rendering ankommt oder verpufft.
Canvas-Rendering in der WinHero Web-App: Warum der Browser System-Kontrasteinstellungen ignoriert
Der entscheidende Unterschied liegt nicht im Design, sondern im Rendering-Pfad. Ein Canvas-Element ist im DOM ein einzelner rechteckiger Kasten. Alles, was hineingezeichnet wird, landet als Pixel in einer Bitmap. Der Browser kennt weder die Textknoten noch deren Farbwerte, Schriftgrößen oder Layering. Folge: Eine Regel wie @media (prefers-contrast: more) kann den Inhalt nicht umfärben, weil es keinen adressierbaren Inhalt gibt. Dasselbe gilt für erzwungene Kontrastmodi des Betriebssystems, etwa den Kontrastmodus unter Windows oder die Erhöhung des Kontrasts in den Bedienungshilfen von iOS und iPadOS. Diese Einstellungen wirken auf gerenderte Text- und UI-Elemente, nicht auf Pixelflächen.
Ein HTML-Absatz verhält sich anders. Erbt der Browser eine Systemvorgabe für Vorder- und Hintergrundfarbe, ersetzt er die per CSS gesetzten Werte und berechnet den Kontrast neu. Text bleibt Text: skalierbar, selektierbar, für Screenreader lesbar. Bei Canvas endet diese Kette. Was als Graustufe mit 2,1:1 gezeichnet wurde, bleibt bei 2,1:1, auch wenn der Nutzer systemweit höchsten Kontrast eingestellt hat.
| Ebene | Canvas-Inhalt | HTML-Inhalt |
|---|---|---|
| prefers-contrast | wirkungslos | greift, Farben überschreibbar |
| Erzwungener Kontrastmodus | keine Anwendung | Systemfarben werden erzwungen |
| Screenreader-Zugriff | nur über ARIA-Fallback möglich | native Textknoten |
| Textskalierung | nur als Ganzes (Bitmap) | unabhängig vom Layout |
Für die WinHero Web-App heißt das konkret: Die Spieloberflächen der Slots laufen im Canvas, die Lobby und die Kontoansichten dagegen in HTML. Ein Nutzer mit kontrastreicher Systemeinstellung sieht in der Lobby klare, dunkel umrandete Schaltflächen, wechselt er in ein Spiel, fällt die Oberfläche auf das ursprüngliche Farbschema zurück. Die Erwartung, dass eine einmal gesetzte Kontrasteinstellung durchgehend gilt, wird an dieser Stelle gebrochen. Das ist kein Fehler im Sinne eines Bugs, sondern eine Eigenschaft des Rendering-Modells.
Praktisch prüfbar ist das in wenigen Minuten: Kontrastmodus im Betriebssystem aktivieren, die Web-App über https://winhero-online.de/app/ im Safari-Browser oder in Chrome öffnen und zwischen Lobby und Spiel wechseln. Bleibt die Spielansicht unverändert, bestätigt das die Bitmap-These. Wer zusätzlich die Entwicklerwerkzeuge öffnet, sieht im Canvas-Bereich keinen Textbaum, nur ein einzelnes Element mit Breite und Höhe. Genau dort endet jede Kontrastanpassung, die auf CSS oder Systemvorgaben setzt.
Zoom statt Kontrast: Wie sehbeeinträchtigte Nutzer in Canvas-Slots doch lesbare Oberflächen erreichen
Wer den Kontrastmodus seines Betriebssystems aktiviert hat und dann einen Canvas-Slot in der WinHero Web-App öffnet, sieht keinen Unterschied. Die Einstellung greift ins Leere, weil der Spielinhalt als Pixelgrafik im Canvas landet und nicht als DOM-Struktur, an der ein erzwungener Kontrast ansetzen könnte. Genau hier endet die Kontrast-Diskussion und die Zoom-Diskussion beginnt. Wer trotzdem lesen will, bleibt auf die Skalierung des Browsers angewiesen.
Der Browser-Zoom ist kein Notbehelf, sondern im Canvas der einzige Hebel, der die gerenderte Oberfläche tatsächlich vergrößert. Bei 150 Prozent Zoom verdoppeln sich die dargestellten Flächen nahezu, Schriftzüge in Guthabenanzeigen, Einsatzfeldern und Auszahlungstabellen werden wieder unterscheidbar. Bei 200 Prozent bricht das Layout in Canvas-Slots jedoch häufig: Feste Koordinaten und vordefinierte Bitmap-Größen führen dazu, dass Bedienelemente aus dem sichtbaren Bereich rutschen oder überlappen. Nutzer müssen dann zwischen lesbarer Schrift und erreichbaren Buttons abwägen.
- Zoomstufe 125 bis 150 Prozent: meist stabil, Schrift wird lesbar, Layout bleibt intakt.
- Zoomstufe 175 bis 200 Prozent: erhöhte Lesbarkeit, aber zunehmend abgeschnittene Randbereiche.
- Zoomstufe über 200 Prozent: Canvas-Slots werden praktisch unbedienbar, da Interaktionspunkte verschwinden.
Ein weiterer Punkt, den Skeptiker zu Recht anführen: Der Browser-Zoom skaliert die gesamte Seite, nicht nur den Spielbereich. Die umgebende Navigation der WinHero Web-App wächst mit, Menüs werden sperrig, das Informationsverhältnis auf dem Bildschirm kippt. Auf einem Smartphone mit 6,1 Zoll Display bleibt bei 175 Prozent Zoom oft nur ein schmaler Streifen für das eigentliche Spiel. Auf einem Tablet oder iPad fällt dieser Effekt deutlich milder aus, weil schlicht mehr Pixel zur Verfügung stehen.
Für Entwickler heißt das: Wer Canvas-Slots baut, muss die Skalierung von Anfang an mitdenken. Ein festes internes Koordinatensystem, das proportional mitskaliert, verhindert abgeschnittene Elemente bei hohen Zoomstufen. Ein zweiter, kontrastreicher Farbmodus innerhalb des Canvas, umschaltbar über eine eigene Schaltfläche, ersetzt die Systemeinstellung, die hier nicht greift. Ohne diese beiden Vorkehrungen bleibt sehbeeinträchtigten Nutzern nur der Zoom als einziger Weg zu lesbaren Oberflächen, und der stößt schnell an seine Grenzen.
Die Sitzungsverwaltung der WinHero Web-App profitiert indirekt davon: Wer häufig zwischen Zoomstufen wechselt, verliert keine laufende Session, solange die Anmeldung serverseitig stabil bleibt. Der eigentliche Engpass liegt nicht im Login, sondern in der Spieloberfläche selbst.
HTML-Lobby versus Canvas-Slot: Warum die Lobby-Ansichten der WinHero App barrierefreier sind
Die WinHero Web-App ist keine monolithische Oberfläche. Lobby, Kategorien, Filter und Kontobereiche sind als HTML-DOM aufgebaut, die eigentlichen Spielrunden laufen in Canvas-Flächen. Genau diese Trennung entscheidet über Barrierefreiheit, und sie fällt eindeutig zugunsten der Lobby aus.
Skalierbarkeit: HTML-Text skaliert mit der im Browser gesetzten Schriftgröße, bricht um und bleibt im Fluss. Ein Slot im Canvas rendert eine feste Bitmap mit intern definierten Koordinaten; beim Browser-Zoom wird das gesamte Bild vergrößert, inklusive unscharfer Kanten und abgeschnittener Randbereiche. Wer 200 Prozent Zoom braucht, verliert in Canvas-Slots regelmäßig Teile der Einsatz- und Guthabenanzeige. In der HTML-Lobby verschiebt sich das Layout, ohne Inhalte zu verlieren.
Screenreader-Zugriff: HTML-Elemente liefern Rollen, Namen und Zustände. Ein Button in der Lobby wird als Button angesagt, ein Filter als ausgewählt oder nicht ausgewählt. Canvas bietet dem Screenreader eine einzige Fläche ohne innere Struktur. Was im Slot steht, ist für assistive Technik nicht lesbar, solange der Entwickler keine parallele Textbeschreibung pflegt. Die Lobby ist damit die einzige Ansicht der WinHero App, in der Navigation ohne Sichtkontrolle zuverlässig funktioniert.
Kontrastanpassung: Die Lobby übernimmt Systemvorgaben. prefers-contrast, der erzwungene Kontrastmodus von Windows und die Farbfilter von iOS greifen bei HTML-Elementen, weil der Browser die Darstellung neu berechnet. Canvas-Inhalte bleiben davon unberührt. Ein Spieler, der auf einen kontrastreichen Modus angewiesen ist, sieht in der Lobby angepasste Schrift und Flächen, im Slot exakt dieselben Farben wie zuvor.
Prüfschritte für die Praxis:
- Lobby mit 200 Prozent Zoom öffnen und prüfen, ob Guthaben, Einsatzlimits und Verantwortungsfunktionen vollständig sichtbar bleiben.
- Screenreader aktivieren (VoiceOver auf iPhone und iPad, TalkBack auf Android) und die Lobby per Wischgeste durchlaufen. Werden alle Bedienelemente benannt?
- Erzwungenen Kontrastmodus einschalten und zwischen Lobby und Slot wechseln. Der Unterschied zeigt die Grenze des Renderings.
- Im Slot prüfen, ob Einsatz und Guthaben zusätzlich als HTML-Text außerhalb der Canvas-Fläche stehen.
Das Ergebnis ist unbequem für die Produktkommunikation: Die architektonisch zugänglichere Oberfläche der WinHero App ist der langweilige Teil, die Lobby. Die spektakulären Slots sind es nicht. Betreiber GEFATA CORPORATION S.R.L. mit Sitz in Costa Rica müsste die Spielinhalte doppelt ausgeben, als Canvas und als semantisches HTML-Overlay, um diesen Abstand zu schließen. Solange das nicht geschieht, bleibt der Hinweis auf „barrierefreie Spieleoberflächen” eine Aussage über die Lobby und nicht über das Spiel.
Plattformunterschiede und Praxis: WinHero App iOS, WinHero App Android und der WinHero App Download
Die WinHero App ist eine Web-App für iOS, und genau daraus folgt der entscheidende Praxispunkt: Es gibt keinen App-Store-Download, über den eine native Anpassung an System-Kontraste nachgereicht würde. iOS-Nutzer installieren die Web-App über „Zum Startbildschirm” im Safari-Browser. Die Oberfläche läuft damit im WebKit-Rendering, und was dort als Bitmap auf der Canvas-Fläche liegt, bleibt von den Bedienungshilfen des iPhone oder iPad weitgehend unberührt. Nutzer richten den mobilen Zugang über winhero-online.de ein und sollten vor dem ersten Einsatz die Schriftgröße in iOS-Einstellungen unter Bedienungshilfen sowie den Seitenzoom in Safari prüfen, nicht nur den Kontrastmodus.
Android-Nutzer laden eine Installationsdatei direkt vom Anbieter herunter. Der Anbieter bietet einen Android-Download an, weil die App nicht verfügbar ist in App Store und Google Play. Für die Lesbarkeit heißt das: Der APK-Download bringt keine Kontrastvorteile, und fremde APK-Seiten stellen Gefahren für die Gerätesicherheit dar, unabhängig von der Darstellungsfrage. Wer die Datei von Drittquellen bezieht, riskiert manipulierte Pakete und hat zusätzlich keine Gewissheit, welche Rendering-Version tatsächlich läuft. Prüfschritte vor der Installation: Quelle ausschließlich über den offiziellen Kanal, Dateigröße und Versionsnummer gegen die Anbieterangabe abgleichen, danach in den Android-Einstellungen für Bedienungshilfen den erzwungenen Kontrastmodus testen. Bei Canvas-Slots wird sich dort wenig ändern, in der HTML-Lobby dagegen schon.
Der Betreiber sitzt in Costa Rica, GEFATA CORPORATION S.R.L. betreibt das mobile Portfolio von WinHero. Das ist für die Barrierefreiheit insofern relevant, als die Durchsetzung von Zugänglichkeitsstandards nicht über eine europäische Store-Zertifizierung läuft, sondern allein über die Web-Oberfläche. Wer verbindliche Prüfungen will, muss sie selbst durchführen. Eine kurze Checkliste für den Einsatz:
- Browser-Zoom auf 150 und 200 Prozent setzen und prüfen, ob Beschriftungen in Spieldialogen noch vollständig sichtbar bleiben.
- System-Kontrastmodus aktivieren und vergleichen, ob sich Lobby und Slot unterschiedlich verhalten.
- Screenreader-Test in der Lobby: Werden Guthaben, Einsatz und Gewinn als Text vorgelesen oder nur als Grafik erkannt?
- Zeilenabstand und Schriftgröße in den Anzeigeeinstellungen des Geräts erhöhen, nicht nur den Kontrast.
- Vor jedem Download die Versionsangabe des Anbieters mit der installierten Datei abgleichen.
Entwickler sollten den Canvas-Bereich mit einem Mindestkontrast von 4,5:1 für Text und 3:1 für große Schrift und UI-Elemente auslegen und zusätzlich eine skalierbare Textalternative anbieten, die auf prefers-contrast reagiert. Die WinHero Web-App läuft über den Safari-Browser, dort lassen sich Zoomstufen und Textgrößen zuverlässig testen. Bleibt der Canvas starr, ist die HTML-Lobby die belastbarere Oberfläche, und das sollte in der Sitzungsverwaltung dokumentiert sein, damit Supportfälle nachvollziehbar bleiben.
Ein nüchterner Prüfplan für den Alltag: Öffnen Sie die Web-App über den Safari-Browser auf iPhone oder iPad und zoomen Sie auf 200 Prozent. Bleiben Beschriftungen, Guthaben und Einsatzhöhen lesbar, ohne dass Sie horizontal schieben müssen? Wechseln Sie danach in den Systemeinstellungen auf einen erhöhten Kontrast und beobachten Sie, ob sich die Lobby mitzieht. Die HTML-Bereiche reagieren in der Regel, die Canvas-Slots nicht. Genau dieser Unterschied ist der aussagekräftigste Einzeltest, den ein Nutzer ohne Messwerkzeug durchführen kann. Wer auf Android unterwegs ist und den WinHero App Download über die Installationsdatei des Anbieters erwägt, sollte zusätzlich die Schriftgröße im System auf die größte Stufe stellen und prüfen, ob die Sitzungsverwaltung und das Willkommensbonus-Fenster noch vollständig sichtbar bleiben. Fremde APK-Seiten sind dabei tabu, denn manipulierte Pakete gefährden die Gerätesicherheit und lassen sich nicht auf den Betreiber GEFATA CORPORATION S.R.L. mit Sitz in Costa Rica zurückführen.
Für Entwickler lohnt sich eine kurze Checkliste vor jedem Release: Kontrastverhältnisse der Lobby-Elemente gegen 4,5:1 für Fließtext und 3:1 für große Schrift und Bedienelemente messen, den Fokusrahmen bei Tastaturbedienung sichtbar halten, Zeilenabstand und Schriftgröße skalierbar ausliefern und für Canvas-Inhalte mindestens eine alternative Textdarstellung der zentralen Werte bereitstellen. Wer die Spielhöhe, das Guthaben und den Status einer Runde auch als HTML-Element ausgibt, verliert nichts an Gestaltung und gewinnt Screenreader-Zugriff. Bleibt am Ende die Frage, ob eine Oberfläche ohne Zoom überhaupt bedienbar ist: Lautet die Antwort nein, ist das kein Randfall, sondern ein Befund, der vor der Veröffentlichung behoben gehört.