Lieber Gunnar,

ich habe mir diese Antwort nocheinmal durchgesehen, um zu prüfen, was eine zugängliche Bedienung alles erfordert. Nun bin ich mir nicht mehr so sicher, ob Deine Vorschläge unbedingt die besten sind.

:-P

Nun, das Markup. Es ist so gut wie nicht vorhanden. Nur leere Tabellenzellen. Aber was sollten die auch für Inhalt haben?

Der Inhalt könnte in einem Button bestehen, der als Eingabewerkzeug dafür dient, dass der Spieler, der gerade an der Reihe ist, dieses Feld belegen möchte.

Also: Ein Button in jedes Tabellenfeld. Nur einer. Und der wird nach Betätigen durch den Inhalt ersetzt, der das Symbol des jeweiligen Spielers repräsentiert, also den Buchstaben x oder o.

Dazu fragen wir uns, was denn die Gundfunktionalität ist: Ganz einfach die Auswahl von Kreuz oder Kreis in jedem Feld.

Nein. Das ist nicht die Grundfunktionalität. Diese besteht in der Auswahl eines der noch freien Felder. Der Benutzer wählt keinesfalls zwischen Kreuz und Kreis! Das würde sich mit der Spielmechanik stören, da dann eine Mehrfacheingabe denkbar wäre, welche gegen die Spielregel verstößt, dass die Spieler im Wechsel jeweils ein Feld für sich in Anspruch nehmen.

Eine solche Auswahl müsste man aufwendig wieder kompensieren, damit der aktuelle Spieler nur "sein" Symbol benutzen kann. Daher frage ich mich wozu eine solche Wahl überhaupt einen Sinn haben soll. Dann doch gleich einen Button, der das Feld auswählt. Die Spielmechanik definiert ja das Symbol des Spielers ohnehin schon.

Jede Zelle hat initial keinen Wert und kann durch Nutzerinteraktion mit ❌ (×, x) oder ⭕ (○, o) befüllt werden.

Fast. Sie enthält einen Button. Nach Betätigen dieses Buttons wird dieser ersetzt. Siehe oben.

Aber das passende UI-Element zur Auswahl ist ein Drop-Down-Menü. Das Innere der Tabellenzellen wäre

Finde ich nicht. Siehe oben. Ein Button sollte genügen. Er ist ja "von Natur aus interaktiv". :-P

Das kann sogar ein Blinder bedienen. (Und das ist wörtlich gemeint. ♿️ Deswegen auch das aria-label-Attribut.)

Von einem Button hätte ich jetzt auch nichts anderes erwartet. Dieser sollte ebenso zuverlässig von einem Blinden bedient werden können.

Das Aussehen können wir ja verbessern. Aussehen heißt CSS.

Also kann man die Zelle weiterhin mit der passenden Klasse versehen. Diese sorgt für ein visuelles Ersetzen des Buchstabens "x" oder "o" und macht daraus das "schönere" Symbol "❌" oder "⭕".

Hier (erst!!) kommt nun JavaScript ins Spiel.

Finde ich nicht. JavaScript sollte das Spielfeld bereits erstellen. JavaScript kann einen Button ins Dokument pflanzen, der das Erstellen des Spielfeldes verursacht. Ohne JavaScript sollte ja auch keine Tabelle zu sehen sein.

Der nächste Spieler ist am Zug.

Um die nun nicht benötigten option-Elemente auszublenden, erhält das Stylesheet noch eine Ergänzung:

Findest Du nicht, dass mein Vorschlag mit nur einem Button hier ebenso zugänglich aber technisch simpler und von daher sinnvoller ist?

Bei Ausfall von JavaScript oder CSS funktioniert die Grundfunktionalität immer noch – und zwar auch, wenn CSS ausfällt, JavaScript aber ausgeführt wird. Dann sieht das Feld wieder ungestylt aus, das JavaScript sorgt aber schon dafür, dass in den disableten selects nicht erneut auswählt werden kann.

Ich finde nicht, dass eine JavaScript-freie Lösung in ein JavaScript-Tutorial sollte. Meiner Meinung nach darf man für ein JavaScript-Spiel diejenigen User ausschließen, für die JavaScript nicht verfügbar ist. Deshalb auch mein Votum für den initialen Button, der das Spiel erst erstellt, sodass ohne JavaScript auch nichts vom Spielfeld angezeigt wird.

Wenn der Spieler am Zug ist, der die Kreuze macht, werden die Kreuz-Radiobuttons enablet; die Kreis-Radiobuttons disablet. Für den anderen Spieler entsprechend andersrum.

Gefällt mir nicht. Aber siehe oben.

Die Label lassen wir das gesamte Feld ausfüllen, damit die Spieler überall im Feld clicken können.

Ein Button benötigt kein Label. Das macht die Sache für mich attraktiver umzusetzen. Da hätte ich dann Lust, das Tutorial in der von mir vorgeschlagenen Weise zu überarbeiten.

Auch diese Lösung funktioniert, wenn JavaScript interpretiert wird, CSS aber nicht.

Auch mein jetziger Vorschlag passt zu dieser Aussage. Buttons werden durch die Buchstaben "x" oder "o" ersetzt. Mit CSS wird es schöner, ohne CSS bleibt es aber sinnvoll dargestellt.

An der Stelle käme dann wieder die Erkennung des Spielendes hinzu, um die wir uns in diesem Posting nicht kümmern wollen.

Nun möchte ich doch diskutieren, wie man das Spielende sinnvoll darstellt. Auf jeden Fall sollte man die betreffenden Buchstaben in strong- oder zumindest em-Elemente verlagern, damit aus semantischer Sicht klar wird, welche Felder nun zum Spielentscheid beigetragen haben. Natürlich passiert bei einem Unentschieden hier nichts.

Die Anzeige, wer nun gewonnen hat, ist momentan nur durch generierten Inhalt über eine Klasse gelöst. Wie schon erörtert wird solcher Inhalt von Screen-Readern nicht vorgelesen, also ist die momentane Lösung nicht zugänglich. Besser wäre eine Art Beschriftung. Da fällt mir spontan das caption-Element ein. Wie fändest Du das? Dieses Element könnte auch während des Spiels eine Meldung enthalten, wer gerade am Zug sei. Würde sich das blind bedienen lassen? Bei Spielende kann der Inhalt dieses caption-Elements gerne die Tabelle überlagernd dargestellt werden.

Kümmern wir uns lieber um die grundsätzliche Frage: Sollte das alles in einem Tutorial für Anfänger stehen?

Ja, unbedingt!! Wie sonst sollen Anfänger das Prinzip von progressive enhancement verinnerlichen, wenn es ihnen in Tutorials nicht so vorgemacht wird? Kein Anfänger wird nach einem solchen JavaScript-Tutorial noch ein zweites lesen, denn die Lösung „funzt“ ja. Nur dass sie eben nicht funktioniert.

In kleinen und sinnvollen Dosen sehe ich das ein. Wenn Dir meine Vorschläge als ausreichend erscheinen, würde ich den Artikel entsprechend überarbeiten. Dabei werde ich dann die Vorüberlegungen etwas ausführlicher im Hinblick auf Zugänglichkeit gestalten, um die Erkenntnisse dieses Threads zur Zufriedenheit aller im Tutorial einzubringen.

Wollen wir die nächste Generation von Entwicklern heranzüchten, die das dreiundzwölfzigste JavaScript-Framework entwickeln, ohne die geringste Ahnung von HTML zu haben? Was man dem erzeugten Code auch ansieht und das Ergebnis zu Lasten von UX und Barrierefreiheit, also zu Lasten der Nutzer geht?

Kann ich sie davon abhalten? Das Framework werden sie ohnehin entwickeln. Nur vielleicht kein unzugängliches Tic-Tac-Toe mehr. Und wenn man daran sehen und verstehen - also nachvollziehen! - kann, wie man von Anfang an die Zugänglichkeit im Blick behält, dann finden wir beide doch noch unsere Positionen bestärkt.

Was meinst Du?

Liebe Grüße,

Felix Riesterer.