WCAG-Standards: Was sie für Websites bedeuten
WCAG ist der Massstab für barrierefreie Websites - und für viele Schweizer Firmen ab jetzt kein Randthema mehr. Ich sehe hier vor allem vier Punkte: WCAG 2.2 AA ist meist das Ziel, in der Schweiz sind rund 1,8 Millionen Menschen betroffen, automatische Tools finden oft nur 30–40 % der Probleme, und ab 01.01.2027 dürften die Regeln in der Schweiz für mehr private Anbieter eine grössere Rolle spielen.
Wenn ich den Artikel auf das Wesentliche herunterbreche, bleibt das:
- WCAG sagt, wie Websites für Menschen mit Behinderungen nutzbar werden
- Für die meisten Websites zählt vor allem Level AA
- Im Alltag geht es meist um Inhalte, Navigation und Formulare
- Typische Punkte sind Alt-Texte, Kontrast, Tastaturbedienung, sichtbarer Fokus und klare Fehlermeldungen
- WCAG 2.2 bringt neue Regeln, zum Beispiel zu Zielgrössen, Fokus und wiederholten Eingaben
- Scanner allein reichen nicht, weil sie nur einen Teil der Barrieren finden
- Gute Prüfungen bestehen aus Tool-Checks, Tastaturtests und Tests mit Screenreadern und echten Nutzenden
Ich würde den Kern so sagen: Barrierefreiheit ist nicht nur eine Frage von Recht und Technik. Sie betrifft auch Reichweite, Usability und Umsatz. Wer Landingpages, Shops oder Formulare betreibt, sollte WCAG früh im Projekt mitdenken statt erst nachträglich zu flicken.
| Bereich | Worauf ich achte | Häufige Fehler |
|---|---|---|
| Inhalte | Alt-Texte, Überschriften, Linktexte, Kontrast | «Hier klicken», zu heller Text, fehlende Struktur |
| Navigation | Tab-Reihenfolge, Fokus, Skip-Link, Tastatur | outline: none, nicht erreichbare Menüs |
| Formulare | Labels, Fehlermeldungen, Feldbezug, Hinweise | Platzhalter statt Label, unklare Fehler |
| Tests | Tools + manuelle Prüfung | Nur Lighthouse laufen lassen |
Damit ist die Richtung klar: Ich würde eine Website heute direkt auf WCAG 2.2 AA ausrichten und nicht erst warten, bis ein Audit Probleme sichtbar macht.
Wie WCAG aufgebaut ist: Prinzipien, Stufen und Versionen
WCAG ist klar gegliedert: in Prinzipien, Richtlinien und testbare Erfolgskriterien. Für Websites heisst das im Alltag vor allem eins: Inhalte müssen lesbar sein, sich gut bedienen lassen und im Code sauber umgesetzt werden.
Die vier POUR-Prinzipien
Die vier Prinzipien sind das Fundament aller WCAG-Anforderungen. Das Akronym dazu lautet POUR:
- Perceivable (Wahrnehmbar): Alternativtexte, Untertitel, Kontrast
- Operable (Bedienbar): Tastaturbedienung, Fokus, keine blinkenden oder flackernden Inhalte
- Understandable (Verständlich): klare Sprache, logische Navigation, präzise Fehlermeldungen
- Robust: semantisches HTML statt generischer
<div>-Strukturen
Diese Prinzipien sind nicht nur Theorie. Sie geben später sehr direkt vor, was bei Inhalten, Navigation und Formularen zählt.
Konformitätsstufen A, AA und AAA
Die Erfolgskriterien sind in drei Stufen eingeteilt:
- A: Basis
- AA: Zielstufe für die meisten Websites
- AAA: Zusatzanforderungen für Spezialfälle
AA ist für die meisten Schweizer Websites die Stufe, auf die man hinarbeitet. Sie deckt den Standard ab, den viele Projekte in der Praxis brauchen.
Was sich von WCAG 2.0 zu 2.2 geändert hat
WCAG 2.2 wurde am 5. Oktober 2023 veröffentlicht und ist rückwärtskompatibel mit den Versionen 2.0 und 2.1. Die grösste Änderung sind 9 zusätzliche Erfolgskriterien. Sie zielen vor allem auf mobile Nutzung, kognitive Einschränkungen und eingeschränkte Feinmotorik.
Was heisst das konkret? Buttons müssen eine Mindestgrösse von 24 × 24 CSS-Pixel haben oder genug Abstand zueinander. Formulare sollen dieselbe Information nicht zweimal abfragen. Und der Fokusindikator muss klar sichtbar sein und genug Kontrast haben.
Dazu kommt noch eine Änderung im Detail: Das Kriterium 4.1.1 (Parsing) wurde entfernt, weil moderne Browser Markup-Fehler heute meist selbst konsistenter behandeln.
Wenn du neu baust, setzt du am besten direkt WCAG 2.2 AA als Ziel. Genau aus diesen Stufen ergeben sich später die Anforderungen, die bei Content, Navigation und Formularen am stärksten ins Gewicht fallen.
sbb-itb-ec9488d
Die WCAG-Anforderungen, die die meisten Business-Websites betreffen
Aus den WCAG-Prinzipien werden im Alltag vor allem drei Bereiche wichtig: Inhalte, Navigation und Formulare.
Inhalte, Bilder, Überschriften und Farbkontrast
Bilder brauchen einen Alternativtext, der den Inhalt beschreibt. Die Ausnahme sind rein dekorative Bilder. Dort gehört alt="" ins Markup, damit Screenreader sie überspringen. Bei Überschriften gilt: Sie müssen logisch aufeinander folgen. Die Optik allein genügt nicht.
Beim Kontrast wird es oft überraschend schnell zum Problem. Normaler Text braucht 4,5:1 Kontrast, grosser Text 3:1. Hellgrauer Text auf weissem Hintergrund fällt hier regelmässig durch. Das wirkt auf den ersten Blick harmlos, ist in der Nutzung aber oft mühsam.
Auch der Linktext spielt eine grosse Rolle. Formulierungen wie «Hier klicken» oder «Mehr lesen» helfen Screenreader-Nutzenden kaum weiter. Klarer ist zum Beispiel: «Jahresbericht 2024 herunterladen».
Bei der Bedienung tauchen viele andere Fehler erst dann auf, wenn man die Seite im Alltag nutzt.
Tastaturbedienung, Fokus und Navigation
Links, Buttons und Formularfelder müssen per Tab erreichbar sein und sich mit Enter oder Leertaste auslösen lassen.
Ein sichtbarer Fokusindikator zeigt, welches Element gerade aktiv ist. Wer im CSS outline: none setzt und keine andere Markierung definiert, macht die Seite für Tastaturnutzende praktisch unbrauchbar. Genau dort merkt man schnell, ob eine Website nur gut aussieht oder auch sauber bedienbar ist.
Skip-Links wie «Zum Inhalt springen» helfen dabei, lange Menüs zu überspringen. Das spart Zeit und macht die Navigation deutlich angenehmer.
Noch heikler wird es bei Eingabefeldern und Fehlermeldungen.
Formulare, Checkout-Strecken und Fehlerbehandlung
Jedes Feld braucht ein im Code verknüpftes Label, also for und id. Platzhaltertexte im Feld selbst reichen nicht aus. Sie verschwinden beim Tippen und werden von Screenreadern nicht zuverlässig vorgelesen.
Fehlermeldungen müssen klar sagen, was falsch ist. Ausserdem müssen sie mit dem Feld verknüpft sein, etwa über aria-describedby oder aria-errormessage. Liegt ein Fehler vor, sollte das Feld zusätzlich mit aria-invalid="true" markiert werden.
Bei mehrstufigen Checkout-Prozessen helfen Fortschrittsanzeigen und klare Anweisungen. Zeitlimits sollte man wenn möglich vermeiden. Wenn sie nötig sind, sollten Nutzerinnen und Nutzer sie anpassen können.
Was Studien und Audits über WCAG-Tests zeigen
WCAG-Tests: Automatisiert vs. Manuell im Vergleich
Wer die WCAG-Anforderungen kennt, landet fast sofort bei der nächsten Frage: Wie testet man das im Alltag? Die kurze Antwort lautet: automatisch und manuell.
Gerade bei Kontrast, Tastaturbedienung und Formularen merkt man schnell, ob eine Website WCAG-tauglich ist. Und genau dort sieht man auch, wo WCAG in der Praxis an seine Grenzen kommt.
Automatisierte Tools versus manuelle Tests
Tools wie WAVE, Lighthouse, axe DevTools oder Pa11y liefern schnelle Resultate. Sie finden fehlende Alternativtexte, zu schwache Kontraste oder doppelte IDs. Das ist hilfreich. Aber es hat einen Haken: Automatisierte Scanner erkennen nur rund 30 bis 40 Prozent aller Barrieren auf einer Website.
Was fehlt? Der Blick auf den Sinn hinter dem Code.
Ein Tool erkennt zum Beispiel oft nicht:
- ob ein Alternativtext den Bildinhalt tatsächlich beschreibt
- ob die Tab-Reihenfolge für Menschen logisch ist
- ob dynamische Inhalte sauber an Screenreader übergeben werden
Genau das prüfen manuelle Tests. Sie schauen auf Logik, Kontext und Bedienbarkeit. Anders gesagt: Der Scanner sieht Muster im Code, der Mensch merkt, ob die Seite im Einsatz auch funktioniert.
Der Vergleich macht den Unterschied gut sichtbar:
| Merkmal | Automatisiert (z. B. Lighthouse, WAVE) | Manuell (Tastatur, Screenreader, Menschen mit assistiven Technologien) |
|---|---|---|
| Abdeckung | Rund 30–40 % der Probleme | Technisch und inhaltlich deutlich umfassender |
| Geschwindigkeit | Sofortige Ergebnisse | Zeitaufwändig, erfordert Fachwissen |
| Was die Methode gut prüft | Technische Struktur, Kontrast, Markup | Logische Tab-Reihenfolge, sinnvolle Alternativtexte, Formular-Usability |
| Grenzen | Versteht keinen Kontext oder die Bedeutung von Inhalten | Höhere Kosten, schwer skalierbar |
Ein einfacher Start: Testen Sie die Website nur mit Tab, Enter und den Pfeiltasten. Alles, was dabei nicht erreichbar ist, ist ein klares Problem - ganz egal, was ein Scanner meldet.
Warum Nutzertests trotzdem wichtig sind
Fachtests allein reichen nicht. Menschen mit assistiven Technologien zeigen oft die grössten Probleme im Alltag. Sie merken, wo Formulare verwirren, wo Anweisungen unklar bleiben oder wo die Navigation zwar technisch läuft, aber in der Praxis mühsam ist.
Das ist vor allem bei Checkout-Strecken und mehrstufigen Prozessen wichtig. Technisch korrekte ARIA-Attribute heissen noch lange nicht, dass ein Ablauf auch verständlich ist. Ein Prozess kann auf dem Papier sauber gebaut sein und sich trotzdem zäh anfühlen.
Darum gehören Audits in jeden grösseren Release, vor allem nach:
- Redesigns
- CMS-Migrationen
- grossen Inhaltsänderungen
WCAG-Testing gehört damit in die laufende Website-Pflege - nicht nur in die Projektphase.
Fazit: Was WCAG für Website-Strategie und Umsetzung bedeutet
WCAG ist der Referenzstandard für digitale Barrierefreiheit. Für die meisten Websites ist Level AA der praktische Maßstab.
In der Praxis heisst das: Barrierefreiheit passiert nicht nebenbei. Sie entsteht dann, wenn Design, Entwicklung, Inhalt und Testing zusammenziehen. Wenn WCAG von Anfang an mitgedacht wird, fallen später weniger Korrekturen an. Das spart Aufwand und führt zu Websites, die stabiler und verlässlicher laufen.
Und es geht um mehr als nur Compliance. Am Ende zählt, wie gut Menschen eine Website nutzen können. Für Schweizer Unternehmen rechnet sich Barrierefreiheit auch geschäftlich: Sie erweitert die Reichweite, verbessert die Usability und stärkt die digitale Qualität.
FAQs
Gilt WCAG auch für KMU in der Schweiz?
Für private KMU in der Schweiz gibt es zurzeit keine allgemeine, ausdrücklich festgelegte Pflicht, Websites nach WCAG umzusetzen.
Trotzdem gewinnen die WCAG an Gewicht. Das BehiG steckt den Rahmen gegen Diskriminierung ab. Und sobald ein Unternehmen im EU-Raum tätig ist, kann auch der EAA ins Spiel kommen. Wer sich früh an WCAG 2.1 AA orientiert, senkt rechtliche Risiken und erreicht online mehr Menschen.
Wie erkenne ich, ob meine Website WCAG 2.2 AA erfüllt?
Prüfen Sie Ihre Website mit einer Mischung aus automatisierten Tests und manuellen Checks. Tools wie Lighthouse, axe DevTools oder WAVE finden technische Mängel wie fehlende Alternativtexte, zu tiefe Farbkontraste oder fehlerhafte Formularbeschriftungen.
Aber hier liegt der Haken: Nicht jede Barriere lässt sich automatisch erkennen. Darum sind manuelle Tests so wichtig. Navigieren Sie Ihre Website nur mit der Tastatur und testen Sie sie mit Screenreadern wie NVDA oder VoiceOver.
Was kostet eine barrierefreie Website?
Die Kosten für eine barrierefreie Website können stark schwanken. Entscheidend sind vor allem die Komplexität des Projekts, der Umfang der Inhalte und der technische Zustand der bestehenden Seite.
Wird auf WCAG-Standards schon früh geachtet, lassen sich spätere, oft teure Korrekturen in vielen Fällen vermeiden. Für eine genaue Kostenschätzung braucht es deshalb immer eine individuelle Analyse der Anforderungen.
Verwandte Blogbeiträge
Das könnte Sie auch interessieren
Mehr Experten-Wissen und praxisnahe Tipps für Ihren digitalen Erfolg.
