So beheben Sie die 6 häufigsten WCAG-Verstöße auf jeder Website

Öffnen Sie jetzt eine der Top-Millionen-Websites, und mit einer Wahrscheinlichkeit von 96 von 100 finden Sie einen WCAG-Verstoß, den ein automatischer Scanner in Sekunden erkennen kann. Auf einer Million Startseiten wurden 56.114.377 unterschiedliche Barrierefreiheitsfehler festgestellt – durchschnittlich 56,1 Fehler pro Seite. Besonders bemerkenswert ist, dass 96% aller erkannten Fehler in nur sechs Kategorien fallen und dass diese sechs häufigsten Fehlertypen in den letzten sieben Jahren unverändert geblieben sind. Das bedeutet: Wenn man eine Handvoll gut verstandener Probleme behebt, verbessert sich die Barrierefreiheit im gesamten Web drastisch – und es beginnt mit Ihrer Website.

Warum dieselben sechs Fehler immer wieder auftreten

Man könnte sich fragen, wie es in einer Zeit hochentwickelter Entwicklungstools und zunehmender rechtlicher Prüfung möglich ist, dass dieselben Fehler Jahr für Jahr in großem Maßstab bestehen bleiben. Die Antwort ist systemisch. Diese Fehlerdichte spiegelt wider, wie tief mangelnde Barrierefreiheit in Webentwicklungspraktiken eingebaut ist. Template-Probleme vervielfältigen sich über jede Seite. Komponentenfehler wiederholen sich auf ganzen Websites. Ohne gezielte Aufmerksamkeit für Barrierefreiheit erzeugen Standard-Entwicklungs-Workflows systematisch nicht barrierefreie Ergebnisse.

Hinzu kommt ein trügerisches Gefühl von Fortschritt, das durch Automatisierung entsteht. Automatisierte Tests erfassen nur 30–40% potenzieller WCAG-Verstöße. Websites, die automatisierte Tests bestehen, können dennoch erhebliche Probleme bei Tastaturnavigation, Screenreadern oder kognitiver Barrierefreiheit haben. Das bedeutet, dass selbst der kleine Prozentsatz an Websites, die auf dem Papier konform erscheinen, in der Praxis wahrscheinlich hinterherhinkt.

Die rechtlichen Risiken sind real und steigen. Laut Seyfarth Shaw wurden 2024 8.800 ADA-Title-III-Bundesklagen eingereicht, von denen etwa 2.452 speziell auf Web-Barrierefreiheit abzielten. E‑Commerce-Websites tragen ein überproportionales Risiko – 77% der Klagen zur Web-Barrierefreiheit richten sich gegen den Online-Handel. Compliance ist kein „Nice-to-have“ mehr. Es ist ein Thema der Geschäftskontinuität.

Die ermutigende Kehrseite? Diese Konzentration hat praktische Auswirkungen. Organisationen können den Großteil ihrer Barrierefreiheitsprobleme angehen, indem sie sich auf eine Handvoll Problemtypen konzentrieren. Umfassende WCAG-Konformität erfordert Aufmerksamkeit für alle 78 Kriterien, aber die wirkungsvollsten Verbesserungen ergeben sich aus der Behebung dieser häufigen Fehler. Gehen wir also jeden einzelnen durch – mit praktischen Lösungen, die Sie noch heute umsetzen können.

Fehler Nr. 1 – Text mit zu geringem Kontrast (WCAG 1.4.3)

Text mit zu geringem Kontrast – Text, der sich farblich nicht ausreichend von seinem Hintergrund abhebt – erscheint auf 83,6% der untersuchten Startseiten. Dies ist der häufigste WCAG-Verstoß und betrifft mehr als vier von fünf Websites. WCAG 1.4.3 (Mindestkontrast) ist gnadenlos eindeutig: Normaler Text muss ein Kontrastverhältnis von mindestens 4,5:1 gegenüber seinem Hintergrund erreichen, und großer Text (18pt oder 14pt fett) muss mindestens 3:1 erreichen.

Kontrastfehler entstehen oft durch Designentscheidungen, die Ästhetik über Lesbarkeit stellen. Hellgrauer Text auf weißem Hintergrund wirkt auf Designer mit perfektem Sehvermögen anspruchsvoll. Für Nutzer mit Sehbeeinträchtigung, ältere Nutzer oder alle, die auf einem Bildschirm mit Blendung lesen, ist er unleserlich. Sekundäre Beschriftungen, Formular-Platzhalter, Footer-Text und deaktivierte Button-Zustände sind die üblichen Übeltäter – sie werden so gestaltet, dass sie dezent wirken, und sind am Ende für einen erheblichen Teil Ihres Publikums unsichtbar.

Die Lösung ist fast immer eine CSS-Anpassung. Prüfen Sie Ihre Farbkombinationen mit einem Kontrast-Checker wie dem Kontrast-Tool von WebAIM oder dem Accessibility-Panel der Browser-DevTools und passen Sie dann Vorder- oder Hintergrundfarbe an, bis der Test bestanden wird. Hier ist ein häufiges Muster, das durchfällt, und wie man es korrigiert:

/* Failing — ratio approximately 2.3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Passing — ratio approximately 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

Für Platzhaltertext gilt: WCAG behandelt ihn als echten Text – nicht als dekorativen Hinweis – daher muss auch er die Schwelle von 4,5:1 erfüllen. Verlassen Sie sich nicht ausschließlich auf Platzhaltertext, um Anweisungen zu vermitteln; kombinieren Sie ihn immer mit einem sichtbaren <label>-Element. Wenn Sie Bilder mit Text verwenden, können Sie den Kontrast nicht mit CSS beheben – Sie müssen diese Bilder neu erzeugen. Das ist ein weiterer Grund, Live-HTML-Text gegenüber in Grafiken eingebettetem Text zu bevorzugen.

Fehler Nr. 2 – Fehlender Alternativtext für Bilder (WCAG 1.1.1)

Bilder ohne Alternativtext erscheinen auf 58,2% der Startseiten. Wenn Bilder keinen Alt-Text haben, stoßen Screenreader-Nutzer entweder auf Stille oder auf bedeutungslose Dateinamen, wo eigentlich aussagekräftige Inhalte sein sollten. Dieses Problem ist nicht neu. Alt-Text ist seit WCAG 1.0 im Jahr 1999 eine grundlegende Anforderung an Barrierefreiheit. Fünfundzwanzig Jahre später gelingt es den meisten Websites immer noch nicht, ihn konsequent umzusetzen.

Der Grund für die Persistenz ist eine Lücke im Workflow, nicht im Wissen. Diese Fehlerquote weist auf systematische Lücken in Content-Workflows hin. Autorinnen und Autoren sowie Redakteurinnen und Redakteure wissen oft nicht, dass Alt-Text erforderlich ist. Content-Management-Systeme fordern ihn nicht immer an. Die Qualitätssicherung erkennt das Fehlen nicht. Die Lösung hat daher zwei Ebenen: eine technische und eine prozessuale.

Auf der technischen Seite benötigt jedes aussagekräftige Bild ein alt-Attribut, das dieselben Informationen vermittelt wie das Bild selbst. Dekorative Bilder – rein visuelle Elemente ohne Informationsgehalt – sollten ein leeres alt="" erhalten, damit Screenreader sie vollständig überspringen. Diese Unterscheidung ist genauso wichtig wie das Hinzufügen des Attributs an sich. Ein großer Prozentsatz der Bilder hat fehlenden oder ungenauen Alt-Text. Einige aussagekräftige Bilder haben überhaupt keine Beschreibung, während dekorative Bilder oft wie bedeutungsvolle Inhalte behandelt werden. Beide Probleme verletzen die WCAG-Konformität für wahrnehmbare Inhalte.

<!-- Meaningful image: describe what it conveys -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />

<!-- Decorative image: empty alt, no role needed -->
<img src='wave-divider.svg' alt='' />

<!-- Linked image: describe the destination, not the image -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='View pricing plans' />
</a>

Auf der Prozessebene sollten Sie Ihre CMS-Templates so aktualisieren, dass das Alt-Feld für Inhaltsbilder verpflichtend ist, und alle schulen, die Assets hochladen. Automatisierte Tools wie Accsible können Bilder mit fehlendem oder leerem Alt-Text auf der gesamten Website erkennen und Ihrem Team eine prüfbare Liste liefern, die systematisch abgearbeitet werden kann.

Fehler Nr. 3 – Fehlende Formularfeld-Beschriftungen (WCAG 1.3.1, 3.3.2)

48,6% der Websites haben fehlende Formularfeld-Beschriftungen. Dieser Fehler ist besonders gravierend, weil Formulare der Ort sind, an dem Nutzer tatsächlich etwas tun – sich anmelden, einkaufen, Kontakt aufnehmen, Supportanfragen einreichen. Viele Formulare haben keine barrierefreien Beschriftungen, verlassen sich ausschließlich auf Platzhalter, machen Anweisungen und Fehlermeldungen nicht zugänglich oder unterstützen keine reine Tastaturnutzung. Da Formulare für die meisten digitalen Erlebnisse essenziell sind, schaffen diese Fehler erhebliche Nutzungsbarrieren.

Der häufigste Fehler ist die Verwendung von Platzhaltertext als Ersatz für ein <label>. Platzhalter verschwinden, sobald ein Nutzer zu tippen beginnt. Menschen mit Beeinträchtigungen des Kurzzeitgedächtnisses – oder einfach jemand, der mitten im Formular abgelenkt wird – wissen dann nicht mehr, wofür das Feld gedacht war. Screenreader gehen unterschiedlich mit Platzhaltern um, und keine dieser Varianten ist so zuverlässig wie eine korrekte Label-Verknüpfung.

Das richtige Muster ist die Verwendung eines <label>-Elements, das über passende for- und id-Attribute mit seinem Eingabefeld verknüpft ist. Wenn aus Designgründen kein sichtbares Label möglich ist, verwenden Sie aria-label oder aria-labelledby – greifen Sie aber nicht zu ARIA, wenn Sie einfach ein <label> nutzen könnten.

<!-- Correct: explicit label association -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Wrong: placeholder only -->
<input type='email' placeholder='Email address' />

<!-- Acceptable when label must be visually hidden -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' />

Fehlermeldungen müssen ebenfalls programmatisch verknüpft sein. Wenn ein Formular validiert und einen Fehler findet, sollte die Meldung mit dem Feld über aria-describedby verbunden werden, und idealerweise sollte der Fokus auf das erste ungültige Feld gesetzt werden. Formularvalidierungsfehler sollten effizient, intuitiv und barrierefrei sein – der Fehler muss klar identifiziert werden, der schnelle Zugriff auf das problematische Element muss möglich sein, und der Nutzer muss den Fehler leicht beheben und das Formular erneut absenden können.

Fehler Nr. 4 – Leere Links und Buttons (WCAG 2.4.4, 4.1.2)

44,6% der Websites haben leere Hyperlinks. Leere Buttons wurden auf fast 30% der Seiten gefunden, und diese Zahl ist im Vergleich zum Vorjahr gestiegen. Das bedeutet, dass blinde oder sehbehinderte Nutzer den Zweck von Buttons wie Senden, Zurücksetzen, Filtern oder Suchen nicht verstehen. Zusammen gehören leere Links und Buttons zu den frustrierendsten Erfahrungen für Screenreader-Nutzer – auf interaktive Elemente ohne Namen zu stoßen, ist wie an einer Tür zu ziehen, deren Griff keine Beschriftung hat und bei der man nicht weiß, wohin sie führt.

Leere Links treten am häufigsten auf, wenn ein Icon oder Bild das einzige Kindelement eines <a>-Tags ist und kein Textäquivalent bereitgestellt wird. Leere Buttons entstehen, wenn reine Icon-Buttons – Hamburger-Menüs, Schließen-Icons, Social-Share-Buttons – keinen zugänglichen Namen haben. Beides lässt sich leicht beheben.

<!-- Empty link — fails -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Fixed with aria-label -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- Empty button — fails -->
<button><svg>...</svg></button>

<!-- Fixed with visually hidden text -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Close menu</span>
</button>

Beachten Sie das aria-hidden='true' beim SVG in jedem korrigierten Beispiel. Wenn Sie eine Textalternative über aria-label oder visuell versteckten Text bereitstellen, sollten Sie das SVG aus dem Accessibility-Tree ausblenden – andernfalls könnten Screenreader sowohl das Label als auch den eigenen Titel oder die Beschreibung des SVGs ansagen, was zu einer verwirrenden Doppelansage führt. Mehrdeutiger Linktext – Formulierungen wie „hier klicken“, „mehr lesen“ oder „weitere Informationen“ – ist ein verwandter Fehler. Andere Hyperlink-Probleme wie mehrdeutiger Linktext wurden auf fast 14% der Startseiten gefunden, ein Anstieg gegenüber dem Vorjahr. Hyperlinks mit aussagekräftigem Text sind wichtig, damit Nutzer wissen, wohin ein Link sie führt. Der zugängliche Name jedes Links sollte auch aus dem Kontext gerissen sinnvoll sein, da Screenreader-Nutzer häufig navigieren, indem sie sich eine Liste aller Links auf einer Seite anzeigen lassen.

Fehler Nr. 5 – Fehlende Dokumentensprache (WCAG 3.1.1)

Dieser Punkt mag im Vergleich zu Kontrast oder Alt-Text geringfügig erscheinen, aber etwa 16% der Seiten haben keine festgelegte Dokumentensprache – und die Auswirkungen auf Screenreader-Nutzer sind unmittelbar und irritierend. Wenn ein Screenreader-Nutzer das entsprechende Sprachpaket installiert hat, wird der Inhalt korrekt vorgelesen. Andernfalls klingt es wie ein schlechter Akzent und ist möglicherweise nicht verständlich.

Die Lösung ist ein einziges HTML-Attribut – buchstäblich eine Codezeile – und es gibt keinen Grund, es wegzulassen. Fügen Sie dem <html>-Element das lang-Attribut mit dem entsprechenden BCP‑47-Sprachcode hinzu. Wenn Abschnitte Ihrer Seite in einer anderen Sprache als die Seite insgesamt verfasst sind, fügen Sie diesen spezifischen Elementen ebenfalls ein lang-Attribut hinzu.

<!-- Missing: no lang attribute -->
<html>

<!-- Correct: English page -->
<html lang='en'>

<!-- Correct: French page -->
<html lang='fr'>

<!-- Inline language switch within a page -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p>

Wenn Sie ein CMS oder einen Static Site Generator verwenden, sollte das lang-Attribut in Ihrem Basistemplate gesetzt werden. Überprüfen Sie Ihr Template einmal, korrigieren Sie es einmal, und jede Seite Ihrer Website ist sofort verbessert. Dies ist vielleicht die Maßnahme mit dem höchsten Aufwand-Nutzen-Verhältnis auf dieser gesamten Liste – eine einzige Template-Änderung beseitigt das Problem auf Ihrer gesamten Domain.

Fehler Nr. 6 – Nicht barrierefreie Tastaturnavigation und Fokusverwaltung (WCAG 2.1.1, 2.4.7)

Bei der Tastaturzugänglichkeit ist die Lücke zwischen automatisierten Tests und der tatsächlichen Nutzbarkeit am größten. Automatisierte Tools können einige Tastaturfehler erkennen – etwa interaktive Elemente, die aus nicht-semantischen Tags gebaut sind – aber sie können Tab-Reihenfolge, Fokusfallen oder die Erfahrung, ein Dropdown-Menü nur mit Pfeiltasten zu bedienen, nicht simulieren. Websites entfernen häufig die standardmäßigen Fokusindikatoren, ohne Alternativen bereitzustellen, was die Tastaturnavigation nahezu unmöglich macht. Das betrifft nicht nur Nutzer mit motorischen Beeinträchtigungen, sondern alle, die die Tastatur bevorzugen, Power-User und Menschen, die Schaltgeräte verwenden.

Die häufigsten Tastaturfehler sind: benutzerdefinierte interaktive Komponenten, die aus <div>- oder <span>-Tags gebaut sind und nie Fokus erhalten; CSS-Regeln, die den Standard-Fokusring des Browsers mit outline: none oder outline: 0 entfernen, ohne ihn durch etwas ebenso Sichtbares zu ersetzen; Modaldialoge, die den Fokus nicht einschließen (sodass Tastaturnutzer hinter das Overlay tabben können); sowie Karussells oder Akkordeons, die ohne Maus nicht bedienbar sind.

<!-- Keyboard-inaccessible custom button — fails -->
<div class='btn' onclick='doSomething()'>Submit</div>

<!-- Correct: use a real button -->
<button type='button' onclick='doSomething()'>Submit</button>

<!-- Removing focus styles — fails WCAG 2.4.7 -->
* {
  outline: none; /* never do this globally */
}

<!-- Better: style focus visibly while preserving aesthetics -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Die Pseudoklasse :focus-visible ist hier Ihr bester Freund. Sie zeigt Fokus-Stile an, wenn ein Nutzer per Tastatur navigiert, blendet sie aber bei Mausklicks aus – so erhalten Sie eine saubere Optik, ohne die Barrierefreiheit zu opfern. Für Modals und Drawer verwenden Sie ein Fokus-Fang-Utility, das die Tab-Navigation auf den Dialog beschränkt, solange er geöffnet ist, und den Fokus beim Schließen auf das auslösende Element zurücksetzt. Pop-ups erscheinen häufig ohne korrekte Fokusverwaltung, ohne Beschriftungen oder ohne Unterstützung für Tastaturnavigation. Dies führt zu erheblichen Störungen, insbesondere in kritischen Nutzerflüssen wie Anmeldungen, Logins und Checkout-Prozessen.

Über einzelne Komponenten hinaus sollten Sie einen Skip-Link hinzufügen – einen visuell versteckten Link, der beim Fokus sichtbar wird und Tastaturnutzern ermöglicht, wiederkehrende Navigation zu überspringen und direkt zum Hauptinhalt zu springen. Skip-Links, mit denen Nutzer wiederkehrende Navigation umgehen können, fehlen auf der Mehrheit der Websites. Es sind drei Zeilen HTML und ein kleines CSS-Snippet, und sie machen einen enormen Unterschied für alle, die eine inhaltsreiche Seite per Tastatur bedienen.

<!-- Place this as the very first element inside <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Then in your CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Ein Hinweis zu ARIA: Vorsichtig einsetzen

Viele Teams greifen zu ARIA-Attributen (Accessible Rich Internet Applications), um Barrierefreiheitslücken schnell zu schließen. Die Daten deuten darauf hin, dass dies häufiger nach hinten losgeht, als dass es hilft. Etwa 79% der ausgewerteten Startseiten verwendeten ARIA, ein Anstieg gegenüber dem Vorjahr. Startseiten mit ARIA hatten mehr als doppelt so viele Fehler wie Seiten ohne ARIA. ARIA selbst ist nicht das Problem – meist ist es der Missbrauch oder die falsche Verwendung von ARIA. Viele gutmeinende Entwickler glauben, Inhalte barrierefreier zu machen, indem sie ARIA hinzufügen, verschlechtern sie damit aber oft.

Das Leitprinzip ist einfach: Verwenden Sie zuerst semantisches HTML. Ein <button> ist besser als ein <div role='button'>. Ein <nav> ist besser als ein <div role='navigation'>. Native HTML-Elemente bringen integriertes Tastaturverhalten, Fokusverwaltung und implizite ARIA-Rollen mit, die Sie bei benutzerdefiniertem Markup manuell nachbilden müssten – und genau bei dieser manuellen Nachbildung schleichen sich Fehler ein. Reservieren Sie ARIA für Fälle, in denen HTML die benötigte Semantik wirklich nicht ausdrücken kann, etwa bei Live-Regionen, komplexen zusammengesetzten Widgets oder dynamischen Zustandsänderungen.

Barrierefreiheit in Ihren Workflow integrieren

Bestehende Verstöße zu beheben ist notwendig, aber zu verhindern, dass neue entstehen, unterscheidet reife Barrierefreiheitsprogramme von einmaligen Compliance-Sprints. Barrierefreiheit ist keine einmalige Korrektur. Jede Content-Aktualisierung, jede Designänderung oder jeder Code-Release kann neue Probleme einführen. Die sechs in diesem Leitfaden behandelten Fehlerkategorien sind meist Template-Ebene-Probleme – wenn Sie Header, Footer und gemeinsame Komponenten korrigieren, beseitigen Sie das Problem gleichzeitig auf Hunderten von Seiten.

Integrieren Sie automatisierte Scans in Ihre CI/CD-Pipeline, damit Verstöße erkannt werden, bevor sie in die Produktion gelangen. Tools wie axe-core können in Unit-Tests und End-to-End-Test-Suites eingebettet werden. Kombinieren Sie das mit regelmäßigen manuellen Tastaturdurchläufen und Screenreader-Tests – VoiceOver auf macOS und iOS, NVDA auf Windows – denn automatisierte Tests können häufige Barrierefreiheitsfehler erkennen, aber manuelle Tests helfen, die Lücken zu schließen. Für Teams, die einen schnelleren Einstieg benötigen, kann ein Barrierefreiheits-Overlay-Widget wie Accsible eine bedeutende Klasse von Problemen auf der Rendering-Ebene sichtbar machen und beheben, während langfristige Code-Anpassungen geplant und ausgerollt werden.

Und schließlich sollten Sie den größten Hebel in Ihrem Codebestand angehen: Ihre Templates. Die meisten Websites verwenden Templates – einen Header, Footer, eine Navigation und ein Seitenlayout, die sich auf jeder Seite wiederholen. Probleme in diesen Templates vervielfältigen sich über Ihre gesamte Website. Beheben Sie sie zuerst, um die größte Wirkung zu erzielen. Ein einziges korrigiertes Basistemplate kann 10.000 WCAG-Verstöße mit einem Deployment auf null reduzieren.

Wesentliche Erkenntnisse

• Sechs Fehlertypen dominieren die Landschaft. Text mit zu geringem Kontrast, fehlender Alt-Text, nicht beschriftete Formulareingaben, leere Links und Buttons, fehlende Dokumentensprache und fehlerhafte Tastaturnavigation machen den überwiegenden Teil der WCAG-Verstöße aus. Die Behebung dieser sechs Kategorien liefert im Verhältnis zum Aufwand überproportional große Ergebnisse.
• Die meisten Korrekturen sind CSS- oder Einzeilen-HTML-Änderungen. Das Hinzufügen von lang='en' zu Ihrem <html>-Tag, das Ersetzen von outline: none durch :focus-visible-Stile und das Verknüpfen von Labels mit Eingabefeldern sind Aufgaben von Stunden, nicht von Monaten – und doch beseitigen sie Fehler, die jeden Nutzer mit Behinderung betreffen, der Ihre Website besucht.
• Templates sind der Ort mit dem größten Hebel für Korrekturen. Barrierefreiheitsfehler in gemeinsamen Komponenten und Seitentemplates replizieren sich über Ihre gesamte Website. Prüfen Sie zuerst Header, Footer, Navigation und Formulare – wenn Sie sie dort beheben, beheben Sie sie überall.
• ARIA ist ein Mittel der letzten Wahl, nicht die erste Reaktion. Websites, die stark auf ARIA setzen, ohne eine solide Grundlage in semantischem HTML zu haben, weisen tendenziell deutlich mehr Barrierefreiheitsfehler auf, nicht weniger. Bevorzugen Sie nach Möglichkeit native HTML-Elemente.
• Automatisierte Scans erfassen weniger als die Hälfte der tatsächlichen Probleme. Ergänzen Sie Ihre Tools durch manuelle Tastaturdurchläufe und Screenreader-Tests, um die Fehler zu finden, die kein Scanner aufdeckt – darunter Fokusfallen, Probleme mit der logischen Tab-Reihenfolge und dynamische Inhalte, die Zustandsänderungen nicht ankündigen.