Barrierefreiheit entsteht in der täglichen Arbeit: in Komponenten, Redaktionsvorlagen, Dokumenten und Testroutinen. Diese Kategorie sammelt Beiträge aus der Umsetzung — barrierefreie Navigationen, Dialoge und Karussells, Alternativtexte und Bildbeschreibungen, Untertitel und Transkripte, Tabellen und Datenvisualisierungen, PDF-Dokumente sowie native Apps. Dazu kommen Themen wie Screenreader-Tests, assistive Technologien, leichte Sprache und die Einbindung von Menschen mit Behinderungen in die Prüfung. Ebenso behandeln wir die organisatorische Seite: Schulung von Redaktion und Entwicklung, Abnahmekriterien in Ausschreibungen, Dokumentation von Prüfergebnissen und der Umgang mit Altbeständen, die nicht auf einmal überarbeitet werden können. Ebenso geht es darum, Prüfergebnisse so festzuhalten, dass sie bei der nächsten Änderung noch nachvollziehbar sind und nicht mit dem Projektende verloren gehen.
Auf dieser Seite finden Sie alle Beiträge zum Thema „Praxis & Umsetzung“. 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.
Was Barrierefreiheitsprüfungen in KI-generiertem Code finden: vier typische Muster von div-Schaltfläche bis Fokusrahmen und wie die Prüfung in den Ablauf kommt.
Leichte Sprache beauftragen: Textauswahl, Briefing, Prüfung durch mindestens 2 Menschen mit Lernschwierigkeiten und Einbau nach DIN SPEC 33429 und BITV 2.0.
Countdown-Leiste, Warenkorb-Timer und Gutschein-Pop-up: welches Element unter WCAG 2.2.1 oder 2.2.2 fällt und was Shops vor dem Aktionsstart prüfen sollten.
Drei Viertel der Menschen ab 65 sind online, 76 Prozent davon kaufen dort ein. Welche WCAG-Kriterien diese Kundschaft ausbremsen und in welcher Reihenfolge man sie behebt.
Ein Fehler in der Produktvorlage steht auf jeder Artikelseite. So werden Variantenwahl, Galerie, Preiszeile und Warenkorb-Meldung barrierefrei.
Seit 19. Juni 2026 gilt die Widerrufsfunktion nach § 356a BGB. Wie sie und der Kündigungsbutton mit Tastatur, Screenreader und Zoom funktionieren.
Wie eine Testrunde mit blinden, sehbehinderten und motorisch eingeschränkten Teilnehmenden organisiert wird: Rekrutierung, Einwilligung, Aufgabenskript, Protokoll und der Weg in den Maßnahmenplan.
§ 4 BITV 2.0 verlangt DGS auf der Startseite öffentlicher Stellen. Was Anlage 2 vorgibt, wie der Player aussehen muss und wie Sie die Einbindung prüfen.
Ein WCAG-Prüfbericht listet Befunde, aber keine Reihenfolge. So wird daraus ein Maßnahmenplan mit Wellen, klaren Rollen und belegter Nachkontrolle.
Kartenmodule bringen eigene Barrieren mit. Wie eine Standortsuche ohne Maus, ohne Farbunterscheidung und mit Screenreader ans Ziel führt: Liste.
Sprachsteuerung scheitert, wenn der zugängliche Name den sichtbaren Text nicht enthält. Wie Erfolgskriterium 2.5.3 wirkt und wie Sie den Bedienweg prüfen.
Automatische Scans enden an der Anmeldemaske. Wie ein WCAG-Audit den geschützten Bereich mitprüft: Prüfumfang, Testkonten, Sitzungsablauf, Screenreader.
Auto-rotierende Karussells ohne Pause verstoßen gegen WCAG 2.2.2 und sperren Tastatur- und Screenreader-Nutzer aus. So machen Pause und ARIA Slider zugänglich.
96 Prozent der automatisch erkannten WCAG-Fehler entfallen auf sechs Muster - alle in Bausteinen. Fokus, Tastatur und ARIA einmal in der Komponente lösen, statt auf jeder Seite.
Einfache Sprache von Leichter Sprache abgrenzen, Verständnisbarrieren ohne Zusatzbudget senken und mehr Menschen erreichen - ein Baustein der BFSG-Konformität.
Selbstgebaute Datepicker scheitern an Tastatur, Fokus und Zielgröße. So wird die Terminbuchung nach WCAG 2.2 für Screenreader- und Tastaturnutzer bedienbar.
Parallax, Auto-Slider und schnelle Transitions können Schwindel auslösen. Wie prefers-reduced-motion und Pause-Mechanik Animationen WCAG-2.2-konform machen.
Alt-Texte, sprechende Linktexte, semantische Struktur und Kontrast erfüllen WCAG und stärken zugleich die Auffindbarkeit - Barrierefreiheit und SEO als ein Hebel.
Das BFSG erfasst seit 2025 auch native Apps. Was iOS- und Android-Apps für WCAG 2.1 AA und EN 301 549 erfüllen müssen: Labels, Touch-Ziele, Kontrast, Fokus.
Barrierefreiheit ist ein laufender Prozess: Alt-Texte, Linktexte, Überschriften und barrierefreie PDFs im Team schulen und Wieder-Verbarrieren vermeiden.
Barrierefreie Navigation nach WCAG 2.2: Skip-Links, zugängliche Menüs mit ARIA, aria-current, Landmarks und sichtbares Fokusmanagement in der Praxis.
Das Barrierefreiheitsstärkungsgesetz ist seit Juni 2025 in Kraft. Wer betroffen ist, welche Fristen gelten und welche ersten Schritte jetzt nötig sind.
WCAG 2.2 bringt neun neue Erfolgskriterien. Focus Not Obscured, Dragging Movements, Target Size und Redundant Entry praxisnah erklärt und im Alltag umgesetzt.
Barrierefreier Checkout: zugängliche Zahlungsformulare, verständliche Fehlermeldungen, Adressfelder und Fortschrittsanzeigen für Onlineshops nach WCAG 2.2 AA.
Screenreader-Optimierung für Websites: ARIA-Landmarks, Rollen, Live-Regionen, semantisches HTML und Tests mit Screenreadern auf Windows, macOS und dem Telefon.
WCAG-Kontrastanforderungen verstehen und umsetzen: Messwerkzeuge, dunkler Modus, Fokusindikatoren und Non-Text-Kontrast für barrierefreie Websites und Shops.
Barrierefreiheit früh verankern statt teuer nachrüsten: Kostenvorteil der Shift-Left-Strategie, klare Rollen, Design-Tokens und Definition of Done fürs BFSG.
Tastaturnavigation für barrierefreie Websites: Tab-Reihenfolge, Fokusmanagement, Skip-Links, Tastaturfallen und eigene Bedienelemente ohne Maus nutzbar machen.
Barrierefreie PDFs erstellen: Tagged PDFs, Lesereihenfolge, Alt-Texte, Tabellen und Formulare nach dem PDF/UA-Standard prüfen, umsetzen und im Alltag halten.
Barrierefreiheitstests für Websites: Automatisierte und manuelle Prüfmethoden, Tastatur- und Screenreader-Tests und das professionelle WCAG-Audit im Überblick.