Web-Accessibility-Grundlagen: ARIA ohne Rätselraten

#accessibility#html#frontend

Der häufigste ARIA-Fehler is ned, des falsche Attribut zu nehmen - es is, überhaupt zu ARIA zu greifen, wenn a natives HTML-Element das Problem gratis glöst hätt. ARIA (Accessible Rich Internet Applications) gibt's, um benutzerdefinierte Widgets zu beschreibn, für die HTML koa eingbautes Element hot, ned um a <div> auszubessern, des für an <button> einspringt. Die erste Regel von ARIA, direkt von den Spezifikations-Autoren, lautet: Nutz ARIA ned, wennst ned muasst.

Des Div-Button-Problem

Des taucht in Komponentenbibliotheken dauernd auf:

<div class="button" onclick="submitForm()">Submit</div>

Optisch is es a Button. Für an Screenreader is es a unbeschriftetes, nicht interaktives Stückl Text - ned mit Tab fokussierbar, ned ois Button angsagt, ned mit Enter oda Leertaste aktivierbar. Du kannst des olles mit ARIA und JavaScript nachrüsten:

<div
  class="button"
  role="button"
  tabindex="0"
  onclick="submitForm()"
  onkeydown="if (event.key === 'Enter' || event.key === ' ') submitForm()"
>
  Submit
</div>

Oda du nimmst das Element, des des olles scho kann:

<button onclick="submitForm()">Submit</button>

Tastaturunterstützung, Fokus-Handling, der zugängliche Nama, die richtige Rolle - olles gratis, olles konsistent in jedem Browser und Screenreader, null JavaScript nötig. Des is das Muster zum Verinnerlichn: Greif zuerst zu <button>, <a href>, <input>, <select> und Co., und verlass die native Semantik von HTML nur, wennst was baust, wofür HTML wirklich koa Element hot, wia a Tab-Panel oda a Combobox mit Autovervollständigung.

Wann ARIA seinen Platz verdient: Beschriftung

Sogar bei nativen Elementen brauchn monche Dinge zusätzlichen Kontext, den sichtbarer Text ned vermittelt. A Button nur mit Icon is der klassische Foi:

<button aria-label="Close dialog">
  <svg><!-- X icon --></svg>
</button>

Ohne aria-label sogt a Screenreader nur "Button" an - technisch fokussierbar und aktivierbar, aber der Nutzer hot koa Ahnung, wos er tut. aria-label liefert an zugänglichen Namen, wenn's koan sichtbaren Text gibt, der als Nama dienen könnt. Wenn's sichtbaren Text in da Nähe gibt, aber ned im Button söba, zeigt aria-labelledby per ID drauf, statt ihn zu duplizieren:

<h2 id="billing-heading">Billing Address</h2>
<button aria-labelledby="billing-heading">Edit</button>

Des wird als "Bearbeiten, Rechnungsadresse" angsagt - nützlicher ois a nacktes "Bearbeiten", wenn a Seitn fünf identische Bearbeiten-Buttons für fünf verschiedene Abschnitte hot.

Zustand bei benutzerdefinierten Widgets beschreibn

Do macht ARIA echte, tragende Orbeit: Benutzerdefinierte Komponenten miassn Zustandsänderungen ansagn, die native Elemente automatisch erledigen. A einklappbarer Abschnitt:

<button aria-expanded="false" aria-controls="panel-1" id="toggle-1">
  Show details
</button>
<div id="panel-1" hidden>
  ...
</div>

const toggle = document.getElementById('toggle-1');
const panel = document.getElementById('panel-1');

toggle.addEventListener('click', () => {
  const isExpanded = toggle.getAttribute('aria-expanded') === 'true';
  toggle.setAttribute('aria-expanded', String(!isExpanded));
  panel.hidden = isExpanded;
});

aria-expanded muass in JavaScript synchron mit dem tatsächlich sichtbaren Zustand gehoitn wern - ARIA-Attribute tun von söba nie wos, sie sand rein informativ für Hilfstechnologien. Setz aria-expanded="false" und aktualisier es nie, und a Screenreader-Nutzer kriagt für immer gsogt, das Panel is eingeklappt, a nachdem er's aufgmacht hot.

Live-Regionen für dynamische Updates

Wenn si Inhalt ändert ohne Seitnnavigation oda Fokuswechsel - a Formularvalidierungsfehler taucht auf, a "Gespeichert"-Toast, Suchergebnisse aktualisieren si -, sehn sehende Nutzer des passiern, aber a Screenreader hot koan Grund, wos außerhoib vom aktuellen Fokus vom Nutzer anzusagn, außer du sagst's ihm.

<div aria-live="polite" id="save-status"></div>

document.getElementById('save-status').textContent = 'Changes saved.';

aria-live="polite" sogt der Hilfstechnologie, die Änderung anzusagn, sobois der Nutzer mit dem, wos er grod tut, pausiert - passend für Statusmeldungen. Nutz aria-live="assertive" nur für Dinge, die wirklich unterbrechen miassn, wia a Sitzungsablauf-Warnung; übertreibst du, wird a Seitn mit Screenreader anstrengend zum Nutzn, weil jedes kleine Update abschneidet, wos grod glesn wurde.

Die Regel, die am meisten Bugs fängt

Wennst nur oane Gewohnheit mitnimmst: Frag dich nach jedem hinzugfügten role- oda aria-*-Attribut, wöches native Element die Notwendigkeit erspart hätt. role="button" auf am <div> → hätt <button> sei soin. role="navigation" auf am generischen Wrapper → hätt <nav> sei soin. aria-required="true" auf am Textfeld → hätt das required-Attribut sei soin, des dasselbe an die Hilfstechnologie vermittelt und a no gratis Browser-Validierung dazugibt.

Dann, für das ARIA, des du behoitst: Lass es oamoi durch an Screenreader laufn. VoiceOver kummt mit jedem Mac (Cmd+F5 zum Umschaltn) und NVDA is unter Windows gratis. Fünf Minuten, dei eigene Oberfläche mit Tastatur und Ohr zu bedienen, fangt mehr echte Probleme ab, ois die ARIA-Spezifikation von vorn bis hinten zu lesn - du bemerkst sofort an unbeschrifteten Icon-Button oda a Live-Region, de nie feuert, weil du derjenige bist, den die Stille verwirrt.

Fazit

ARIA ergänzt HTMLs Semantik für Fälle, die HTML ned abdeckt - es ersetzt ned, von vornherein das richtige Element zu nehmen. Fang mit nativem HTML o, füg aria-label/aria-labelledby dazu, wo der zugängliche Nama aus sichtbarem Text ned offensichtlich is, nutz Zustandsattribute wia aria-expanded nur, wennst sie a mit da Realität synchron hoitst, und heb Live-Regionen für Updates auf, die ein Nutzer wirklich außerhoib vom aktuellen Fokus hörn muass.