@@Felix Riesterer

Im Kern möchtest Du das Tutorial um den sehr wesentlichen und wichtigen Punkt der Zugänglichkeit erweitern.

Wenn du mit „Zugänglichkeit“ Barrierefreiheit meinst: Nicht nur. Die fällt dabei so ganz nebenbei mit ab.

Wenn du mit „Zugänglichkeit“ meinst, dass Inhalte im Web ohne Voraussetzungen präsentiert werden sollten – das meine ich. Grundfunktionalität für alle anbieten, progressive enhancement draufsetzen.

Da das Web von Natur aus sowohl responsiv als auch barrierefrei ist – solange man dem nicht mit CSS oder JavaScript entgegenwirkt –, ist die Grundfunktionalität (bei richtig gewähltem Markup) barrierefrei. Beim Erweitern gilt es darauf zu achten, dass man die Barrierefreiheit erhält (im Sinne von „nicht zerstört“, nicht im Sinne von „bekommt“).

Da möchte ich Dir widersprechen. Insbesondere "das alles" sollte nicht hinein, sondern meiner Meinung nach nur der an passender Stelle auf ein anderes Tutorial verweisende mahnende Hinweis, dass die gerade erarbeitete Lösung keinerlei Acht darauf gibt, ob das Spiel Barrieren für die Zugänglichkeit enthält, und wie man diese entfernen könnte.

Da möchte ich dir widersprechen. Grundsätzlich. Ein Artikel muss in sich richtig sein und nicht auf notwendige Berichtigungen verlinken müssen.

Ein JavaScript-Tutorial sollte unbedingt den Grundgedanken vermitteln, dass JavaScript als progressive enhancement anzusehen ist, weil es eben nicht immer zur Verfügung steht (und damit sind nicht nur JavaScript-Ausschalter gemeint).

Barrierefreiheit sollte man nicht erst später dazu tun. Zum einem wird eben das dann meist nicht gemacht, zum anderen ist das viel aufwändiger als Barrierefreiheit von Anfang an in die Entwicklung mit einfließen zu lassen. Deshalb gehört das zum Inhalt eines Anfängertutorials, nicht in einen anderen Artikel verbannt, der von vielen gar nicht gelesen wird.

Léonie Watson zeigt in ARIA, accessibility APIs & coding like you give a damn! (Video, Folien), wie aufwändig es ist, aus einem beliebigen Element (in der jetzigen Version des Tic-Tac-Toe wäre das td) ein UI-Element zu machen, das nicht nur mit der Maus, sondern auch per Tastatursteuerung bedienbar ist, und assistive Technologie (wie Screenreader) dem Nutzer auch mitgeteilt, dass es sich dabei um ein UI-Element mit einer bestimmten Funktion handelt. Heydon Pickering zeigt im Artikel Reinventing The Hyperlink dasselbe für Links. Fazit: Nicht machen, sondern die richtigen HTML-Elemente verwenden.

In dem Fall nicht leere Tabellenzellen <td></td> mit click-Handler, sondern Tabellenzellen mit Button darin. Die Beschriftung der Buttons wäre die Position des jeweiligen Spielfeldes:

<td>
  <button id="button-top-left">Feld oben links</button>
</td>

So, wie ich das Problem des typsicheren Vergleichs nur angerissen habe, könnte man das auch mit dem Problem der Barrieren/Zugänglichkeit machen. Aber eben nur das: anreißen. Die Ausführlichkeit in Deinem Posting empfinde ich als für das Tutorial völlig überdimensioniert.

Du hast insofern recht, dass der Umfang des in meinen gezeigten Beispielen progressive enhancements nicht in ein Anfänger-Tutorial gehört. Insbesondere nicht die Animation, die sowieso nur zu sehen ist, wenn kein JavaScript ausgeführt wird. Der Grundgedanke von progressive enhancement gehört aber wie gesagt rein!

Das kann auch so aussehen, dass man die ursprünglich im HTML vorhandenen select-Felder im DOM durch die eben angesprochenen Buttons ersetzt:

if (document.querySelector)
{
	document.documentElement.classList.add('js');
	
	var ticTacToeElement = document.querySelector('#tic-tac-toe');
	var tdElements = ticTacToeElement.querySelectorAll('td');
	
	for (var i = 0, labelElement; i < tdElements.length; i++)
	{
		labelElement = tdElements[i].querySelector('label');
		tdElements[i].innerHTML = '<button id="button-' + labelElement.getAttribute('for') + '">' + labelElement.innerHTML + '</button>';
	}
}

Den Buttons wird Text- und Hintergrundfarbe und Rahmen genommen und bei :focus eine Hintergrundfarbe gegeben (könnte man auch zusätzlich auch bei :hover tun) — das sieht dann so aus (unfertig).

Im gleichen Schritt kommt natürlich noch die Eventverarbeitung und die Spiellogik hinzu. Beim Drücken auf einen Button wird dieser aus dem DOM entfernt und das Feld mit ❌ (×, x) bzw. ⭕ (○, o) markiert. Bis auf das Entfernen des Buttons hast du ja schon alles. Oh wait, diese Änderung müsste AT dem Nutzer auch bekanntgeben; da wäre wohl noch ein ARIA-Attribut fällig.

So hat man dann einen Artikel, der auf progressive enhancement und Barrierefreiheit eingeht und deren Wichtigkeit verdeutlicht, ohne dabei den Rahmen zu sprengen.

Warum nimmst Du nicht Dein Posting und arbeitest es zu einem zweiten Teil für das Anfänger-Tutorial um, der sich auf das bereits erarbeitete Wissen und Können stützt, um es fortzuführen?

Wo ich das alles schon mal aufgeschrieben habe, könnte ich das tun und zeigen, wie man anstelle des in diesem Posting dargestellten einstufigen progressive enhancements ein mehrstufiges machen kann. Aber wäre das so wichtig?

Wichtig ist mir, dass der Grundlagenartikel schon bereits progressive enhancement vemittelt.

LLAP 🖖