Die Web Content Accessibility Guidelines sind der technische Maßstab, an dem digitale Barrierefreiheit gemessen wird — in Europa über die harmonisierte Norm EN 301 549. Diese Kategorie erklärt die Erfolgskriterien so, dass sie im Alltag anwendbar werden: Kontrastwerte und Textgrößen, Tastaturbedienbarkeit und sichtbarer Fokus, Zielgrößen für Bedienelemente, Bewegung und Autoplay, Formularfehler und Statusmeldungen, semantische Struktur und Namen von Bedienelementen. Wir gehen auf die Unterschiede zwischen den Konformitätsstufen ein, auf die Neuerungen von WCAG 2.2 und darauf, welche Prüfungen sich automatisieren lassen und welche zwingend manuell bleiben. Jeder Beitrag nennt konkrete Prüfschritte statt allgemeiner Appelle. Dazu kommt eine Einordnung der Werkzeuge: Was automatische Prüfungen zuverlässig finden, wo sie falsche Treffer erzeugen und warum eine Bewertung ohne manuelle Prüfung unvollständig bleibt.
Auf dieser Seite finden Sie alle Beiträge zum Thema „WCAG & Standards“. Die neuesten Beiträge stehen oben.
Unter jedem Titel steht ein kurzer Text zum Inhalt. Klicken Sie auf einen Beitrag. Dann lesen Sie den ganzen Text.
Über der Liste stehen auch die anderen Themen. Unten führt ein Link zurück zu allen Beiträgen.
Leere Links und Buttons zählen zu den häufigsten WCAG-Befunden. Reparaturmuster für Icon-Buttons, Bild-Links und „mehr“-Links, geprüft über die Linkliste.
Erfolgskriterium 1.4.13 verlangt drei Dinge zugleich: ausblendbar, überfahrbar, beständig. Der Beitrag zerlegt den Wortlaut und zeigt den Prüfweg im BITV-Test.
Was der erzwungene Kontrastmodus mit Ihrem Design macht, welche Eigenschaften wegfallen und wie Sie forced-colors, Systemfarben und Fokusstile sauber aufsetzen.
ATAG 2.0 prüft das Werkzeug statt nur die Website: Teil A die Redaktionsoberfläche, Teil B die Leitplanken, die barrierefreie Inhalte wahrscheinlich machen.
Am 10. September 2026 hat das W3C einen neuen WCAG-3-Working-Draft veröffentlicht. Was sich geändert hat, warum WCAG 2.2 AA der Maßstab bleibt und was Teams heute tun.
Barrierefreie Anmeldung nach WCAG 2.2 (SC 3.3.8): Passwort-Manager, Magic-Link, Passkeys und CAPTCHA-Alternativen mit Objekterkennung und Audio-Option.
Wann KI-Chatbots und Voice-Assistenten unter das BFSG fallen und wie Conversational UI mit ARIA-Live-Regions, Fokus-Management und Textpfad WCAG-konform wird.
Barrierefreie Routenwechsel in Single-Page-Apps: Fokus auf die neue Überschrift, Seitentitel pflegen und View-Wechsel per Live-Region ankündigen (WCAG 2.4.3).
Diagramme barrierefrei gestalten: Muster statt nur Farbe, ausreichende Kontraste, Textalternativen nach WCAG 1.1.1 und ein Tabellen-Fallback für Charts.
Barrierefreie Fehler- und Statusmeldungen nach WCAG 4.1.3: ARIA Live Regions, role=alert, role=status und aria-describedby für Formulare und dynamische Inhalte.
Modale Dialoge barrierefrei umsetzen: role=dialog, aria-modal, Fokus-Falle, ESC, Fokusrückgabe und inerter Hintergrund nach WCAG 2.4.3 und ARIA Dialog Pattern.
Datentabellen barrierefrei umsetzen: th mit scope, caption, headers und id für komplexe Tabellen, Layout- gegen Datentabellen, responsiv nach WCAG 1.3.1.
Untertitel, Transkripte und Audiodeskription nach WCAG-Richtlinie 1.2 und BFSG: Was Video- und Audioinhalte 2026 barrierefrei macht - praxisnah erklärt.
Alt-Texte nach WCAG 1.1.1 richtig schreiben: informative, dekorative und komplexe Bilder, Diagramme und Infografiken mit Langbeschreibung zugänglich machen.
WAI-ARIA in der Praxis: Rollen vs. natives HTML, Zustände wie aria-expanded und aria-selected, Live-Regions mit polite und assertive sowie häufige Fehler.
Barrierefreie Formulare nach WCAG 2.2: programmatische Labels, Pflichtfeld-Kennzeichnung, Fehlermeldungen mit aria-describedby sowie Fokus-Management.