Accessibility in Go: Software für alle zugänglich machen

Wenn Code sagt: „Ich höre dich“

Stellen Sie sich vor, Sie verlieren für einen Tag Ihr Sehvermögen. Ihr Lieblingsmessenger in Go verstummt plötzlich. Schaltflächen werden nicht angesagt, Formulare können nicht ausgefüllt werden und Validierungsfehler sind nur rote Rechtecke. Unangenehm, oder? Für Millionen von Menschen mit Behinderungen ist dies jedoch kein Experiment, sondern Realität.

Accessibility (oder a11y – von „a“ + 11 Buchstaben + „y“) bedeutet nicht, „ein Häkchen um des Häkchens willen zu setzen“. Es geht darum, dass Ihr Go-Dienst nicht für 15% der Weltbevölkerung das Licht ausschaltet. In diesem Artikel zeigen wir, wie Sie Barrierefreiheit in Go-Projekte ohne Fanatismus, aber mit echtem Nutzen integrieren. Los geht's!

Warum Accessibility in Go keine Option, sondern ein Standard ist

Go ist eine Backend-Sprache, aber das bedeutet nicht, dass sie nicht an der Erstellung einer barrierefreien Oberfläche beteiligt ist. Wenn Sie APIs für das Frontend schreiben, HTML auf dem Server generieren oder CLI-Tools erstellen – Sie beeinflussen bereits die Barrierefreiheit. Die schlechte Nachricht: Viele Go-Entwickler denken, „a11y ist die Aufgabe der Frontend-Entwickler“. Die gute Nachricht: Sie können das an einem Abend ändern.

Was ist Web-Accessibility aus der Sicht von Go?

Web-Accessibility (Web-Barrierefreiheit) ist die Fähigkeit einer Website oder Anwendung, von Menschen mit unterschiedlichen Einschränkungen genutzt zu werden: Sehen, Hören, Motorik, kognitive Fähigkeiten. Im Kontext von Go bedeutet dies:

\n
• Korrektes HTML-Markup, das vom Server generiert wird (z. B. über html/template);
\n
• Korrekte ARIA-Attribute für dynamische Inhalte;
\n
• Logische Navigation mit der Tastatur;
\n
• Verständliche Fehlermeldungen (nicht „Error 500“, sondern „Datei konnte nicht gespeichert werden: nicht genügend Speicherplatz“).
\n

Und ja, Go ist die ideale Sprache dafür. Seine strenge Typisierung und integrierten Tools ermöglichen es, Vorlagen im laufenden Betrieb zu überprüfen. Aber der Reihe nach.

Semantisches Markup: Das Fundament der Barrierefreiheit in Go

Wenn Sie HTML über html/template generieren, sind Sie der Architekt der Oberfläche. Wenn Ihr Code für jede Schaltfläche ein <div> ausspuckt, verstehen Screenreader nicht, um welches Element es sich handelt. Wenn Sie jedoch <button> verwenden, sagen sie: „Schaltfläche. Klicken Sie, um das Formular abzusenden“.

Beispiel: Ein barrierefreies Formular in Go

Angenommen, Sie schreiben ein Registrierungsformular. Schlechte Variante:

// Schlecht: keine Semantik\ntmpl := `<div class="form">\n    <div>Name</div>\n    <input type="text" id="name">\n    <div class="error">{{.NameError}}</div>\n</div>`\n

Gute Variante – mit <label> und aria-describedby:

// Gut: semantisches Markup + ARIA\ntmpl := `<form>\n    <label for="name">Name</label>\n    <input type="text" id="name" aria-describedby="name-error">\n    <span id="name-error" role="alert">{{if .NameError}}{{.NameError}}{{end}}</span>\n</form>`\n

Was hat sich geändert? Der Screenreader weiß jetzt: Dies ist ein Formular, das Eingabefeld ist mit einem Label verknüpft und der Fehler ist ein Alert. Der Benutzer hört: „Name. Text bearbeiten. Fehler: Feld ist erforderlich“.

ARIA-Attribute: Wenn HTML nicht ausreicht

Manchmal reichen die Standard-Tags nicht aus. Zum Beispiel, wenn Sie Tabs mit Go + HTMX erstellen. Ohne ARIA klingen sie wie „Link, Link, Link...“. Mit ARIA hingegen wie „Tab 1, ausgewählt. Tab 2. Tab 3“.

Wie man ARIA in Go-Vorlagen hinzufügt

ARIA-Attribute werden wie normale Attribute in HTML übergeben. Hier ist ein Beispiel für Tabs:

<div role="tablist" aria-label="Profileinstellungen">\n    <button role="tab" aria-selected="{{if eq .Tab "profile"}}true{{else}}false{{end}}" \n            aria-controls="panel-profile" id="tab-profile">Profil</button>\n    <button role="tab" aria-selected="{{if eq .Tab "security"}}true{{else}}false{{end}}" \n            aria-controls="panel-security" id="tab-security">Sicherheit</button>\n</div>`\n