Loading Spinner

Verwendung

Ein Loading Spinner (Lade-Animation) signalisiert Nutzenden, dass ein Prozess läuft und sie auf das Ergebnis warten müssen. Ziel ist die Vermeidung von Verwirrung oder Ungeduld durch ein sichtbares Feedback, dass die Anwendung aktiv arbeitet und nicht eingefroren ist.

Wann soll ein Loading Spinner eingesetzt werden?

Typische Einsatzszenarien sind:

• Das Warten auf den Abschluss einer Datenabfrage wie z. B. bei der Anwendung eines Filters auf eine große Datenmenge.
• Die Verarbeitung von Eingaben wie z. B. das Hochladen von Dateien oder das Absenden von Formularen.
• Das Rendering komplexer Benutzeroberflächen oder großer Inhalte.
• Wenn Aktionen ohne sichtbares Feedback länger benötigen und Nutzerinteraktionen blockiert sind.
• Wenn die Dauer der Verarbeitung nicht genau abschätzbar ist.

Ladezeiten unter einer halben Sekunde benötigen keine optische Rückmeldung, weil Nutzende diese als unmittelbar und sofort empfinden.

Inhaltliche Anforderungen

• Ein Loading Spinner sollte erscheinen, wenn ein länger dauernder Prozess startet, und selbständig wieder verschwinden, wenn dieser abgeschlossen ist.
• Loading Spinner ohne begleitenden Text und auf leerem Hintergrund können Nutzende verunsichern. Daher muss neben dem Spinner eine kurze Info stehen, die sich dynamisch an den aktuellen Zustand anpasst, z. B. „Wird geladen…“ oder spezifischer „Ihre Daten werden abgerufen…“.
• Auf jeder Maske soll es immer nur eine einzige Funktionalität mit einer potentiellen Lade-Animation geben; in der Regel ist dies der Submit-Button.

Technische Anforderungen

• Animationen müssen ressourcenschonend implementiert sein, d. h. CSS-Animationen sollten bevorzugt vor JavaScript-Lösungen verwendet werden.
• Für den Fall dass Animationen deaktiviert sind (prefers-reduced-motion), müssen Loading Spinner auch ohne CSS-Animation über ein statisches Icon erkennbar sein.
• Loading Spinner müssen korrekt an das Lade- oder Fehlerhandling des Frontend-Frameworks gekoppelt sein.

Fehler-Zustände

Lade-Animationen erhalten selbst keinen eigenen Fehler-Zustand – sollte ein Vorgang scheitern, dann geht das auslösende Element in seinen ursprünglichen Zustand zurück und es wird eine entsprechende Globale Meldung (Toast) mit einer Beschreibung des Fehlers und, wenn möglich, mit Hinweisen zur Abhilfe angezeigt.

Situationsabhängige Alternativen

• Sog. “Skeleton Screens” mit Platzhalter-Inhalten statt eines abstrakten Spinners.
• Sog. “Progress Bar“ bei absehbarer Ladezeit oder realistischer Prozentschätzung.

Design

Barrierefreiheit

Relevante BITV-Anforderungen

• 1.1.1 Nicht-Text-Inhalt
• 2.3.3 Animation durch Interaktionen (Level AAA)
• 4.1.2 Name, Rolle, Wert
• 4.1.3 Statusmeldungen

Die Anforderungen an die Barrierefreiheit unterscheiden sich je nach Einsatzzweck der Lade-Animation:

• Kurzzeitige Einblendungen einer Animation sollten idealerweise vor Hilfsmitteln wie Screenreadern verborgen werden. Die Ausgabe einer textlichen Erklärung dauert unter Umständen länger als die verbleibende Anzeigedauer und würde damit im Ernstfall einen falschen, weil veralteten Zustand der Anwendung ausgeben.
• Absehbar länger andauernde Lade-Prozesse müssen an Hilfsmittel kommunizieren, dass entweder
  a. ein durch den Nutzenden ausgelöster Vorgang unbestimmter Dauer stattfindet mit einem generischen Hinweis, oder
  b. wenn eine realistische Vorhersage der Dauer möglich ist, dann den aktuellen Zustand mit der voraussichtlichen Restlaufzeit des Prozesses als sichtbaren Text.

Die Ladeanimation selbst ist nicht per Tastatur fokussierbar. Es muss aber sichergestellt werden, dass der aktuelle Fokus nicht verloren geht, während Inhalte geladen oder geändert werden.

WAI-ARIA

Bei der Vergabe von Attributen muss unterschieden werden, ob der Prozess im Hintergrund abläuft und Nutzende weiterhin mit der Anwendung interagieren können, oder ob dieser weitere Aktionen blockiert:

Im ersten Fall erhält der Container des Loading Spinner die Attribute role="status" und aria-live="polite".

<div role="status" aria-live="polite">
  <span class="ds-loading-spinner" aria-hidden="true">
    <span class="spinner"></span>
  </span>
  <p>Änderungen werden durchgeführt</p>
</div>

Im zweiten Fall von blockierenden Prozessen erhält dieser die Attribute role="alert" sowie aria-live="assertive".

<div role="alert" aria-live="assertive">
  <span class="ds-loading-spinner" aria-hidden="true">
    <span class="spinner"></span>
  </span>
  <p>Daten werden geladen</p>
</div>

Deaktivierung der auslösenden Option

Buttons mit Lade-Animation dürfen nach dem Auslösen nicht mit Attributen wie disabled oder aria-busy versehen werden, da hierdurch das Element seinen Fokus verlieren und aus der Tastaturreihenfolge entfernt würde, und zudem die enthaltene Information über den Zustand im Screenreader nicht mehr ausgegeben würde.
Stattdessen verwendet die Komponente aria-disabled, was die Interaktivität weiterhin sicherstellt, aber den Zustand für Screenreader eindeutig kommuniziert.

Statische Alternative

Optional: Für den Fall dass Nutzende Animationen deaktiviert haben (Einstellung „Bewegung reduzieren“ und das entsprechende CSS-Media Query prefers-reduced-motion), sollten Loading Spinner auch ohne CSS-Animation über ein statisches Icon erkennbar sein.