Barrierefreiheit-Links

Austin Gil hat den ersten Teil einer fünfteiligen Serie über „HTML-Formulare richtig“ gestartet, beginnend mit Semantik. Er richtet sich an die „Wir bauen unsere Frontends mit JavaScript“-Fraktion. Der erste Codeblock ist ein Beispiel für eine Ajax-Formularübermittlung, bei der die übermittelten Daten über die JavaScript-API FormData gesammelt werden.

Warum ist das so wichtig? Nun, kein <form>-Tag, kein FormData. Wofür sonst ein Formular verwenden (abgesehen von der Enter-Tasten-Übermittlung)?

„Aber Austin, ich baue eine SPA. Wenn der Benutzer das Formular überhaupt sieht, bedeutet das, dass JavaScript aktiviert sein MUSS.“ Und da hätten Sie Recht. Wenn es sich jedoch um ein wichtiges Formular handelt, sollten Sie möglicherweise eine Welt ohne JavaScript in Betracht ziehen. Der Tag könnte kommen, an dem Sie SSR implementieren möchten.

Server-Side Rendering (SSR) wird immer einfacher zu implementieren, da seine Vorteile immer offensichtlicher werden. Google sagt uns, dass eine client-seitig gerenderte Seite eine wochenlange Warteschlange hat, um indiziert und bei Änderungen neu indiziert zu werden. Ganz zu schweigen davon, dass SSR mit ziemlicher Sicherheit viel schneller geladen wird.

Oscar Braunerts Inclusive Inputs ist eine gute Lektüre im Anschluss, da sie mit Formular-HTML beginnt, das fast richtig ist, aber schmerzhaft nicht richtig. (Hinweis: Die Verbindung von Label/Input fehlt). Dann geht er auf interessante Muster ein, wie z. B. die barrierefreie Auszeichnung von Pflichtfeldern und Feldern mit Fehlern. Zum Beispiel

<div class="form-group">
  <label for="password">
    Password
    <span class="required" aria-hidden="true">*</span>
    <span class="sr-only">required</span>
  </label>
  <input 
    type="password"
    id="password"
    name="password"
    aria-describedby="desc_pw"
  >
  <p class="aside" id="desc_pw">Your password needs to have at least eight characters.</p>
</div>

Amber Wilson beschäftigt sich mit zugänglichen HTML-Elementen mit dem Twist, dass sie jegliche ARIA-Nutzung vermeidet.

Sie wissen vielleicht, dass ARIA-Rollen oft mit HTML-Elementen verwendet werden. Ich habe hier nicht darüber geschrieben, da es gut ist zu sehen, wie HTML, das ohne ARIA geschrieben wurde, trotzdem zugänglich sein kann.

Ein Lob für <dl>.

Sarah Higley beschäftigt sich zwar mit ARIA in Rollen und Beziehungen, warnt uns aber, von Anfang an sehr vorsichtig zu sein.

[…] ein angehender Barrierefreiheits-Praktiker könnte sich dabei ertappen, wie er mit ernsteren Rollen wie menu, listbox oder sogar treegrid experimentiert. Dies sind verlockende, mächtige Muster, die es Ihnen ermöglichen, Erlebnisse zu schaffen, die nicht nur mit reinem HTML unterstützt werden. Leider sind sie auch zerbrechlich; selbst kleine Fehler bei der Verwendung dieser Rollen können einen Benutzer auf eine sehr schlechte Reise schicken.

Reden Sie mit Ihren Kindern über ARIA, bevor es zu spät ist.

Idealerweise verwenden Sie ARIA gar nicht. Aber wenn die Barrierefreiheit so stark beeinträchtigt ist, dass sie auf DOM-Ebene nicht behoben werden kann, gibt Sarah einige Tricks preis. Zum Beispiel verwendet man role="presentation", um die Standardrolle eines Elements im Wesentlichen zu entfernen (wenn sie im Weg ist).

Wo wir gerade von ARIA sprechen und davon, es nicht zu verwenden, es sei denn, es ist notwendig: Eines der Dinge, die man mit ARIA tun kann, ist die Beschriftung von Steuerelementen. Adrian Roselli hat Gedanken dazu, wie man das am besten macht.

Hier ist die Priorität, die ich befolge, wenn ich einem Steuerelement einen zugänglichen Namen zuweise:
1. Native HTML-Techniken
2. aria-labelledby, das auf vorhandenen sichtbaren Text verweist
3. Sichtbar ausgeblendeter Inhalt, der noch auf der Seite vorhanden ist
4. aria-label