NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grünes Tor, drei Bedienwege führen zum Ziel: Operabilität

Was bedeutet Operabilität in der digitalen Barrierefreiheit?

Operabilität heißt Bedienbarkeit: Jede Funktion einer Website muss sich mit der Eingabeart nutzen lassen, die ein Mensch zur Verfügung hat. Das kann die Maus sein, aber genauso die Tastatur, ein Schalter, die eigene Stimme oder ein Finger mit Tremor.

Operabel, auf Deutsch bedienbar, ist das zweite der vier Prinzipien der WCAG 2.2. Es bündelt fünf Richtlinien: Tastatur, ausreichend Zeit, Schutz vor Anfällen, Navigation und Eingabemodalitäten.

Wahrnehmen allein reicht nicht. Wer einen Button sieht, ihn aber nicht auslösen kann, steht vor derselben Barriere wie jemand, der ihn gar nicht findet.

Inhalt
NCA Cypress Workshop mit Cypress Ambassador Roland Golla

E2E Tests, die euer Team selbst schreibt

Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.

  1. 1
    Kostenloses Vorgespräch
    Projekt, Stack und Teststand klären
  2. 2
    Workshoptag bei euch
    Setup, Patterns und erste Tests im Team
  3. 3
    Praxistag optional
    Tests im eigenen Projekt und in CI
Roland Golla
Roland Golla
Fullstack Developer
Zum Cypress Workshop arrow_forward

NCA prüft, ob eure Website ohne Maus funktioniert

Bedienbarkeit prüfen wir nicht mit einem Score, sondern mit den Händen. Wir legen die Maus weg, gehen jede Strecke per Tastatur durch, ziehen nichts per Drag and Drop und lassen keinen Timer ablaufen. Was dabei hängen bleibt, schreiben wir als Cypress Test fest, damit es nach dem nächsten Release nicht wiederkommt.

Im Accessibility Audit prüfen wir alle fünf Richtlinien des Prinzips: von der Tastaturnavigation über Zeitlimits bis zu Gesten und Zielgrößen. Die Fehler beheben wir direkt im Frontend, meist mit nativen Elementen aus semantischem HTML statt nachgebauter Widgets. Für Menschen, die per Stimme oder Schalter steuern, prüfen wir zusätzlich die Wege über Sprachsteuerung und alternative Eingabegeräte. Abgesichert wird alles über axe DevTools und Cypress in eurer Pipeline, eingebettet in unsere Arbeit im barrierefreien Webdesign.

Wie Menschen Websites tatsächlich bedienen

Die Maus ist nur eine von vielen Eingabearten. Wer Operabilität ernst nimmt, plant für alle Wege, über die Befehle auf einer Seite ankommen:

  • Tastatur: Menschen mit motorischen Einschränkungen, blinde Nutzer mit Screenreader und viele Power User navigieren mit Tab, Pfeiltasten und Enter.
  • Schalter und Joysticks: Bei starken Lähmungen reicht oft ein einziger Taster, mit dem nacheinander alle Elemente angesteuert werden.
  • Stimme: Sprachsteuerungen lösen Elemente über ihren sichtbaren Namen aus.
  • Touch mit Einschränkungen: Tremor, Spastik oder ein Mundstab machen präzise Gesten unmöglich. Mehrfinger Gesten und Wischbewegungen werden zur Hürde.
  • Augensteuerung: Hier wird ein Element durch längeres Anschauen ausgelöst. Kleine, eng stehende Ziele sind dafür kaum treffbar.

Fast alle diese Hilfsmittel landen technisch bei denselben Ereignissen wie die Tastatur. Deshalb ist volle Tastaturbedienbarkeit die Basis, aber eben nicht das ganze Prinzip.

Fünf Richtlinien decken Tastatur, Zeit, Anfälle, Navigation und Eingabe ab

Unter dem Prinzip Bedienbar fassen die WCAG 2.2 fünf Richtlinien zusammen. Jede deckt eine eigene Art von Barriere ab.

  • 2.1 Per Tastatur zugänglich: Alles ist ohne Maus erreichbar (2.1.1, A), der Fokus bleibt nirgends gefangen (2.1.2, A), und Kürzel aus einzelnen Buchstaben lassen sich abschalten (2.1.4, A).
  • 2.2 Ausreichend Zeit: Zeitlimits lassen sich verlängern oder abschalten (2.2.1, A). Bewegte, blinkende oder sich selbst aktualisierende Inhalte lassen sich pausieren (2.2.2, A).
  • 2.3 Anfälle vermeiden: Nichts blitzt öfter als dreimal pro Sekunde (2.3.1, A). Das schützt Menschen mit photosensitiver Epilepsie.
  • 2.4 Navigierbar: Sprunglinks, aussagekräftige Seitentitel und Linktexte, eine sinnvolle Fokusreihenfolge, ein sichtbarer Fokus (2.4.7, AA) und, neu in 2.2, ein Fokus, der nicht von Sticky Elementen verdeckt wird (2.4.11, AA).
  • 2.5 Eingabemodalitäten: Komplexe Gesten haben eine einfache Alternative (2.5.1, A), Aktionen lösen erst beim Loslassen aus (2.5.2, A), Schütteln oder Neigen ist nie der einzige Weg (2.5.4, A). Neu in 2.2: Ziehbewegungen brauchen eine Alternative (2.5.7, AA) und Klickziele sind mindestens 24 mal 24 CSS Pixel groß (2.5.8, AA).

Die Tastatur Kriterien behandeln wir ausführlich auf der Seite zur Tastaturnavigation. Hier geht es um das Zusammenspiel aller fünf Richtlinien.

Vom Mausklick zur Bedienung über jeden Kanal

Bedienbarkeit wächst in Schritten. Viele Seiten bleiben auf der ersten Stufe stehen, weil im Alltag fast alle mit Maus oder Finger testen. Die Tabelle zeigt, was jede Stufe ausmacht und womit ihr sie prüft.

Bedienbarkeit in vier Ausbaustufen

Stufe Woran ihr sie erkennt Prüfmittel
1 Maus und Touch Alles funktioniert per Klick und Tippen, andere Wege sind nie getestet Manueller Klicktest
2 Tastatur vollständig Jede Funktion per Tab und Enter erreichbar, Fokus immer sichtbar, keine Fokusfalle Tastatur, Browser DevTools
3 Alle Eingabewege Zeitlimits verlängerbar, Slider pausierbar, Gesten und Drag and Drop mit Alternative, Ziele ab 24 Pixel Screenreader, Sprachsteuerung, Bildschirmlupe
4 Dauerhaft geprüft Bedienwege laufen als automatisierte Tests bei jedem Pull Request Cypress, axe, GitHub Actions oder GitLab CI

Zeitlimits, Gesten und Drag and Drop im Code lösen

Erst beim Loslassen auslösen. Wer auf mousedown oder pointerdown reagiert, löst Aktionen schon beim ersten Kontakt aus. Menschen mit Tremor haben dann keine Chance, einen Fehlgriff abzubrechen. Das click Event feuert erst beim Loslassen und funktioniert auch mit Tastatur.

Code: 
          
// Falsch: löst beim ersten Kontakt aus
deleteButton.addEventListener('pointerdown', deleteItem)

// Richtig: löst beim Loslassen aus, auch per Enter und Leertaste
deleteButton.addEventListener('click', deleteItem)

Drag and Drop braucht eine Alternative. Seit WCAG 2.2 muss jede Ziehbewegung auch mit einfachen Klicks gehen. Bei sortierbaren Listen reichen zwei Buttons pro Eintrag.

Code: 
          
<li draggable="true">
  Rechnung März
  <button type="button" class="move-up" aria-label="Rechnung März nach oben">↑</button>
  <button type="button" class="move-down" aria-label="Rechnung März nach unten">↓</button>
</li>

Automatische Bewegung pausierbar machen. Ein Slider, der länger als fünf Sekunden läuft, braucht einen Pause Button. Wer reduzierte Bewegung eingestellt hat, sollte gar nicht erst automatisch weiterblättern.

Code: 
          
<button type="button" class="slider-toggle" aria-pressed="false">Slider anhalten</button>

<script>
  const toggle = document.querySelector('.slider-toggle')
  const reduced = window.matchMedia('(prefers-reduced-motion: reduce)').matches
  let timer = reduced ? null : setInterval(nextSlide, 6000)

  toggle.addEventListener('click', () => {
    const paused = toggle.getAttribute('aria-pressed') === 'true'
    toggle.setAttribute('aria-pressed', String(!paused))
    if (paused) { timer = setInterval(nextSlide, 6000) } else { clearInterval(timer) }
  })
</script>

Bedienwege automatisch prüfen. Dieser Cypress Test stellt sicher, dass der Slider anhaltbar ist und jede sortierbare Zeile ihre Buttons hat.

Code: 
          
describe('Bedienbarkeit', () => {
  beforeEach(() => cy.visit('/'))

  it('Slider lässt sich anhalten', () => {
    cy.get('.slider-toggle')
      .click()
      .should('have.attr', 'aria-pressed', 'true')
  })

  it('jede ziehbare Zeile hat eine Klick Alternative', () => {
    cy.get('[draggable=true]').each(($row) => {
      cy.wrap($row).find('button.move-up, button.move-down').should('have.length', 2)
    })
  })
})

Sechs Hürden zwischen Absicht und Aktion

  1. Session Timeout ohne Warnung. Das Formular ist halb ausgefüllt, die Sitzung läuft ab, alles ist weg. Eine Warnung mit Verlängern Button vor Ablauf löst das.
  2. Autoplay ohne Stopp. Slider, Ticker und Hintergrundvideos laufen endlos. Wer langsam liest oder sich leicht ablenken lässt, verliert den Faden.
  3. Nur Wischen. Galerien oder Karten, die sich nur per Wischgeste oder mit zwei Fingern steuern lassen.
  4. Sortieren nur per Ziehen. Kanban Boards und Listen ohne Buttons für oben und unten.
  5. Winzige Ziele. Schließen Kreuze mit 12 Pixeln oder Icon Links, die dicht nebeneinander stehen.
  6. Fokus hinter Sticky Elementen. Cookie Banner oder fixe Header verdecken genau das Element, das gerade den Fokus hat.

The focus indicator is to keyboard users what the mouse cursor is to mouse users.

Sara Soueidan, Accessibility Engineerin und UI Designerin – A guide to designing accessible, WCAG conformant focus indicators, sarasoueidan.com

Ein Tag ohne Maus sagt mehr als jede Checkliste

Der ehrlichste Test für Bedienbarkeit ist simpel: Maus abziehen, Trackpad ignorieren und eine echte Aufgabe erledigen, etwa eine Bestellung oder eine Terminbuchung. Danach dieselbe Aufgabe am Smartphone mit nur einem Finger und ohne Wischen. Die Stellen, an denen ihr hängen bleibt, sind fast immer die Stellen, an denen auch eure Nutzer aufgeben.

Operabilität greift in viele andere Themen. Ohne sinnvolle logische Reihenfolge springt der Fokus quer über die Seite. Ohne korrekte Zustände nach dem Prinzip Name, Rolle, Zustand wissen Screenreader Nutzer nicht, ob ein Menü offen ist. Formulare brauchen die Grundlagen barrierefreier Formulare, Bot Schutz ein bedienbares CAPTCHA.

Einen Überblick über alle vier Prinzipien gibt die Seite zu den POUR Prinzipien. Die rechtliche Einordnung findet ihr beim BFSG, den Weg zu passenden Werkzeugen bei den Accessibility Testing Tools.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zur Operabilität

Bedienbarkeit, Zeitlimits, Gesten und Zielgrößen: die wichtigsten Antworten für Entwicklung und Konzeption.

Was bedeutet Operabilität in der Barrierefreiheit 2026?

Operabilität bedeutet Bedienbarkeit. Alle Funktionen einer Website müssen sich mit unterschiedlichen Eingabearten nutzen lassen, also mit Tastatur, Touch, Stimme oder Schaltern. In den WCAG 2.2 ist Bedienbar das zweite von vier Prinzipien. Es umfasst 2026 fünf Richtlinien: Tastatur, ausreichend Zeit, Anfälle, Navigation und Eingabemodalitäten.

Welche WCAG Kriterien gehören 2026 zum Prinzip Bedienbar?

Zum Prinzip gehören die Richtlinien 2.1 bis 2.5 der WCAG 2.2. Auf Stufe A und AA sind das unter anderem Tastaturbedienung, keine Fokusfalle, verlängerbare Zeitlimits, pausierbare Bewegung, keine Blitze, Sprunglinks, sichtbarer Fokus, einfache Alternativen zu Gesten und Ziehbewegungen sowie eine Mindestgröße für Klickziele.

Was ist neu bei der Bedienbarkeit in WCAG 2.2 und was gilt 2026?

WCAG 2.2 hat beim Prinzip Bedienbar drei neue Kriterien auf Stufe AA eingeführt: Fokus nicht verdeckt, Ziehbewegungen und Zielgröße Minimum. Für 2026 heißt das konkret: Sticky Header und Banner dürfen den Fokus nicht verdecken, jede Drag and Drop Funktion braucht eine Klick Alternative und Klickziele brauchen mindestens 24 mal 24 Pixel.

Ist Operabilität 2026 nach BFSG Pflicht?

Ja, indirekt. Das BFSG verweist auf harmonisierte Normen, die sich an den WCAG Kriterien der Stufen A und AA orientieren. Die Kriterien des Prinzips Bedienbar gehören dazu. Für Onlineshops, Buchungsstrecken und Bankdienste, die unter das BFSG fallen, ist Bedienbarkeit damit 2026 eine konkrete Anforderung. Die rechtliche Bewertung im Einzelfall gehört zu Juristen.

Wie teste ich die Bedienbarkeit meiner Website 2026 am schnellsten?

Legt die Maus weg und erledigt eine echte Aufgabe nur mit der Tastatur. Achtet auf sichtbaren Fokus, Fokusfallen und unerreichbare Elemente. Prüft danach am Smartphone, ob alles ohne Wischen und Mehrfinger Gesten geht. Für dauerhafte Sicherheit schreibt ihr die wichtigsten Bedienwege als Cypress Tests und lasst sie bei jedem Pull Request laufen.

Reicht Tastaturbedienbarkeit für eine bedienbare Website?

Nein. Tastaturbedienung ist die wichtigste Basis, aber nur eine von fünf Richtlinien. Eine Seite kann komplett per Tastatur bedienbar sein und trotzdem an Zeitlimits ohne Verlängerung, endlos laufenden Slidern, zu kleinen Touch Zielen oder fehlenden Alternativen zu Drag and Drop scheitern. Erst alle fünf Richtlinien zusammen ergeben echte Bedienbarkeit.

Wie lang darf ein Zeitlimit sein?

Die WCAG schreiben keine feste Länge vor. Nutzer müssen ein Zeitlimit aber abschalten, anpassen oder verlängern können. Üblich ist eine Warnung mindestens 20 Sekunden vor Ablauf, bei der ein einfacher Klick oder Tastendruck die Zeit verlängert. Ausnahmen gelten für Echtzeit Ereignisse wie Auktionen und für Limits über 20 Stunden.

Was bedeutet Pointer Cancellation?

Pointer Cancellation ist das Kriterium 2.5.2. Eine Aktion darf nicht schon beim Herunterdrücken ausgelöst werden, sondern erst beim Loslassen. So können Nutzer einen Fehlgriff abbrechen, indem sie den Finger oder Zeiger vom Element wegziehen. In der Praxis reicht es meist, das click Event statt mousedown oder pointerdown zu verwenden.

Wie groß müssen Buttons und Links sein?

Nach WCAG 2.2 Kriterium 2.5.8 müssen Klickziele mindestens 24 mal 24 CSS Pixel groß sein oder genug Abstand zu Nachbarn haben. Ausnahmen gelten etwa für Links im Fließtext. Für komfortable Touch Bedienung empfehlen sich eher 44 Pixel, wie es die AAA Stufe vorsieht. Größere Ziele helfen auch bei Augensteuerung und Sprachsteuerung.

Warum sind blinkende Inhalte gefährlich?

Inhalte, die öfter als dreimal pro Sekunde blitzen, können bei Menschen mit photosensitiver Epilepsie Anfälle auslösen. Das Kriterium 2.3.1 verbietet solche Blitze deshalb auf Stufe A. Betroffen sind etwa animierte Banner, Videos mit Stroboskop Effekten oder schnelle Übergänge. Im Zweifel hilft der Verzicht auf schnelle Helligkeitswechsel.

Was hat Operabilität mit Sprachsteuerung zu tun?

Sprachsteuerungen wie Voice Control oder Voice Access lösen Elemente über ihren Namen oder über eingeblendete Nummern aus. Technisch nutzen sie oft dieselben Wege wie die Tastatur. Eine Seite, die per Tastatur sauber bedienbar ist und sichtbare Beschriftungen als zugängliche Namen nutzt, funktioniert deshalb meist auch per Stimme gut.

Kann ein Overlay Tool die Bedienbarkeit verbessern?

Nein. Overlay Widgets legen eine Schicht über die Seite, ändern aber nicht den Code darunter. Fehlende Tastaturbedienung, Fokusfallen oder Drag and Drop ohne Alternative bleiben bestehen. Manche Overlays verschlechtern die Bedienung sogar, weil sie eigene Tastenkürzel einführen. Nachhaltige Bedienbarkeit entsteht nur durch Änderungen im Frontend selbst.