EN 301 549 für Websites: Die 50 wichtigsten Anforderungen

EN 301 549 ist der europäische Standard für digitale Barrierefreiheit und die technische Grundlage des BFSG. Während der Standard WCAG 2.1 Level AA vollständig integriert, geht er in wichtigen Bereichen darüber hinaus. Diese detaillierte Analyse zeigt Ihnen die 50 kritischsten Anforderungen für Websites und wie Sie diese praktisch umsetzen^[1][2].

EN 301 549 im Überblick: Mehr als nur WCAG

Die Struktur von EN 301 549:

• Kapitel 9: Web-Inhalte (= WCAG 2.1 Level A/AA)
• Kapitel 10: Nicht-Web-Dokumente (PDFs, Office-Dateien)
• Kapitel 11: Software und mobile Apps
• Kapitel 12: Dokumentationen und Support
• Kapitel 13: ICT mit Videokommuikation
• Kapitel 5: Hardware und biometrische Systeme

Für Websites ist primär Kapitel 9 relevant, das WCAG 2.1 vollständig übernimmt und durch spezielle EU-Anforderungen ergänzt^[3].

Die 50 kritischsten EN 301 549 Anforderungen für Websites

1. Prinzip: Wahrnehmbar (Perceivable) - 13 Kriterien

1.1 Textalternativen

1.1.1 Nicht-Text-Inhalt (Level A)

• Alle Bilder brauchen Alt-Texte
• Dekorative Bilder: alt="" (leerer Alt-Text)
• Komplexe Grafiken: Längere Beschreibungen
• Praxistipp: Alt-Text sollte Zweck und Inhalt beschreiben, nicht das Aussehen

Implementierung:

<!-- Funktionales Bild -->
<img src="search.webp" alt="Suchen">

<!-- Dekoratives Bild -->
<img src="decoration.webp" alt="">

<!-- Komplexe Grafik -->
<img src="chart.webp" alt="Verkaufszahlen Q4 2024" longdesc="chart-description.html">

1.2 Zeitbasierte Medien

1.2.1 Reine Audio- und Videodateien (Level A)

• Audio-only: Vollständige Transkripte
• Video-only: Audio-Beschreibung oder Transkript
• Praxistipp: Transkripte sollten auf derselben Seite verfügbar sein

1.2.2 Untertitel (aufgezeichnet) (Level A)

• Alle Videos brauchen synchrone Untertitel
• Nicht nur gesprochener Text, auch Geräusche
• Format: WebVTT oder SRT-Dateien

1.2.3 Audiodeskription oder Volltext-Alternative (Level A)

• Videos brauchen Audiodeskription für visuelle Inhalte
• Alternative: Vollständiges Transkript mit Beschreibungen

1.3 Anpassbar

1.3.1 Info und Beziehungen (Level A)

• Semantische HTML-Struktur verwenden
• Überschriften hierarchisch (h1 → h2 → h3)
• Listen, Tabellen und Formulare korrekt auszeichnen

<!-- Korrekte Struktur -->
<h1>Hauptüberschrift</h1>
<h2>Unterüberschrift</h2>
<ul>
  <li>Listenpunkt 1</li>
  <li>Listenpunkt 2</li>
</ul>

<!-- Falsch -->
<div className="heading">Hauptüberschrift</div>
<div className="subheading">Unterüberschrift</div>

1.3.2 Sinnvolle Reihenfolge (Level A)

• Logische Tab-Reihenfolge
• Inhalt muss ohne CSS verständlich bleiben
• Test: CSS deaktivieren und prüfen

1.3.3 Eigenschaften von Sinneswahrnehmungen (Level A)

• Nicht nur "Klick den roten Button"
• Nicht nur "Links im Menü"
• Richtig: "Klick den roten Submit-Button" oder "Links im Hauptnavigationsmenü"

1.4 Unterscheidbar

1.4.1 Nutzung von Farbe (Level A)

• Farbe nie als einziges Unterscheidungsmerkmal
• Zusätzliche Indikatoren: Icons, Text, Muster
• Beispiel: Fehlerfelder nicht nur rot färben, sondern auch mit Icon markieren

1.4.2 Audio-Kontrolle (Level A)

• Audio länger als 3 Sekunden muss kontrollierbar sein
• Automatisch abspielende Sounds vermeiden
• Umsetzung: Play/Pause-Buttons bereitstellen

1.4.3 Kontrast (Minimum) (Level AA)

• Normaler Text: Mindestens 4.5:1 Kontrastverhältnis
• Großer Text (18pt+): Mindestens 3:1
• Prüftools: WebAIM Contrast Checker, Colour Contrast Analyser

1.4.4 Text in Bildern (Level AA)

• Text als echten Text implementieren, nicht als Bild
• Ausnahmen: Logos, dekorative Elemente
• Vorteil: Suchmaschinenoptimierung + Accessibility

1.4.5 Größe von Bildern (Level AA)

• Text muss bis 200% vergrößerbar sein ohne Funktionsverlust
• Responsive Design ist hier kritisch
• Test: Browser-Zoom auf 200% testen

2. Prinzip: Bedienbar (Operable) - 20 Kriterien

2.1 Tastatur-zugänglich

2.1.1 Tastatur (Level A)

• Alle Funktionen per Tastatur erreichbar
• Tab, Enter, Pfeiltasten, Escape müssen funktionieren
• Keine "Maus-Only"-Bereiche

2.1.2 Keine Tastaturfalle (Level A)

• Nutzer dürfen nicht in Bereichen "gefangen" werden
• Escape-Wege für alle interaktiven Elemente
• Modal-Dialoge: ESC zum Schließen

2.1.4 Tastaturkürzel (Level A, WCAG 2.1 neu)

• Einzelzeichen-Shortcuts abschaltbar oder änderbar
• Problem: Versehentliche Aktivierung durch Spracherkennungs-Software

2.2 Ausreichend Zeit

2.2.1 Zeitbegrenzungen anpassbar (Level A)

• Warnung vor Zeitablauf (mindestens 20 Sekunden vorher)
• Verlängerung möglich (mindestens 10x)
• Alternative: Ausschalten der Zeitbegrenzung

2.2.2 Pausieren, Stoppen, Ausblenden (Level A)

• Auto-spielende Inhalte (>5 Sek) kontrollierbar
• Slider, Karussells: Pause-Button erforderlich
• Blinkende Elemente: Stopp-Funktion

2.3 Anfälle vermeiden

2.3.1 Grenzwert von drei Blitzen (Level A)

• Maximal 3 Blitze pro Sekunde
• Kritisch: Animationen, Übergänge, Videos
• Test: Photosensitive Epilepsy Analysis Tool (PEAT)

2.4 Navigierbar

2.4.1 Blöcke überspringen (Level A)

• Skip-Links für Hauptinhalt, Navigation, Fußbereich
• Implementierung: Unsichtbar, aber per Tab erreichbar

<a href="#main-content" className="skip-link">Zum Hauptinhalt springen</a>
<nav>...</nav>
<main id="main-content">...</main>

2.4.2 Seitentitel (Level A)

• Eindeutige, beschreibende Titel für jede Seite
• Format: "Seitenname - Website-Name"
• Dynamisch: Bei SPAs Title bei Navigation ändern

2.4.3 Fokus-Reihenfolge (Level A)

• Logische Tab-Reihenfolge: Links nach rechts, oben nach unten
• Ausnahmen vermeiden: tabindex Werte > 0 meiden

2.4.4 Linkzweck (im Kontext) (Level A)

• "Hier klicken" vermeiden
• Bessere Alternative: "Mehr über unsere Dienstleistungen erfahren"
• Kontextuelle Links mit aria-label ergänzen

2.4.5 Mehrere Wege (Level AA)

• Mindestens 2 Wege zu jeder Seite: Navigation + Sitemap/Suche
• Breadcrumbs für tiefe Hierarchien

2.4.6 Überschriften und Labels (Level AA)

• Beschreibende Überschriften für alle Abschnitte
• Labels für alle Formularfelder
• Nicht: "Eingabefeld 1", sondern "E-Mail-Adresse"

2.4.7 Fokus sichtbar (Level AA)

• Sichtbare Fokus-Indikatoren für alle interaktiven Elemente
• Mindestens: 2px Rahmen, deutlicher Kontrast
• Nie: outline: none ohne Alternative

2.5 Eingabemodalitäten (WCAG 2.1 neu)

2.5.1 Zeigergesten (Level A)

• Alternative für komplexe Gesten (Pinch, Swipe etc.)
• Einfache Klicks/Taps müssen ausreichen

2.5.2 Zeigerabbruch (Level A)

• Aktion erst bei mouseup/touchend, nicht bei mousedown
• Abbruch möglich: Maus/Finger wegbewegen vor Loslassen

2.5.3 Label im Namen (Level A)

• Accessible Name muss sichtbaren Text enthalten
• Button mit "Senden" → aria-label darf nicht nur "Submit" sein

2.5.4 Bewegungsaktivierung (Level A)

• Alternative zu Bewegungs-/Schüttel-Gesten
• Deaktivierbar: Für Nutzer mit Bewegungseinschränkungen

3. Prinzip: Verständlich (Understandable) - 12 Kriterien

3.1 Lesbar

3.1.1 Sprache der Seite (Level A)

• HTML-lang-Attribut korrekt setzen
• <html lang="de"> für deutsche Inhalte

3.1.2 Sprache von Teilen (Level AA)

• Sprachwechsel markieren: <span lang="en">Hello World</span>
• Wichtig für mehrsprachige Inhalte

3.2 Vorhersagbar

3.2.1 Bei Fokussierung (Level A)

• Keine Kontextänderung nur durch Fokussierung
• Beispiel: Dropdown öffnet nicht automatisch bei Tab

3.2.2 Bei Eingabe (Level A)

• Kontextänderung nur nach expliziter Nutzeraktion
• Select-Boxen: Nicht automatisch submitten

3.2.3 Konsistente Navigation (Level AA)

• Navigation in gleicher Reihenfolge auf allen Seiten
• Konsistente Labels und Bezeichnungen

3.2.4 Konsistente Erkennung (Level AA)

• Gleiche Funktionen haben gleiche Bezeichnungen
• "Suchen"-Button überall gleich benennen

3.3 Eingabehilfe

3.3.1 Fehlererkennung (Level A)

• Automatische Fehleridentifikation bei Formular-Submit
• Fehlermeldungen in Textform, nicht nur farblich

3.3.2 Labels oder Anweisungen (Level A)

• Jedes Eingabefeld braucht ein Label
• Pflichtfelder als solche markieren
• Format-Vorgaben erklären ("TT.MM.JJJJ")

<label htmlFor="email">E-Mail-Adresse (Pflichtfeld)</label>
<input type="email" id="email" required aria-describedby="email-help">
<div id="email-help">Format: name@beispiel.de</div>

3.3.3 Fehlerkorrektur (Level AA)

• Korrektur-Vorschläge bei erkannten Fehlern
• Bestätigung vor unwiderruflichen Aktionen (Löschung, Kauf)

3.3.4 Fehlervermeidung (rechtlich) (Level AA)

• Prüfung + Korrektur vor rechtlich bindenden Aktionen
• Widerrufsmöglichkeit innerhalb angemessener Zeit

4. Prinzip: Robust (Robust) - 5 Kriterien

4.1 Kompatibel

4.1.1 Parsing (Level A)

• Valides HTML: Keine Syntaxfehler, eindeutige IDs
• W3C Markup Validator verwenden

4.1.2 Name, Rolle, Wert (Level A)

• Programmatisch bestimmbare Elemente und Zustände
• ARIA-Labels für Custom Components
• Beispiel: <div role="button" aria-pressed="false">Toggle</div>

4.1.3 Status-Nachrichten (Level AA, WCAG 2.1 neu)

• Wichtige Status-Änderungen für Screenreader verfügbar
• aria-live, aria-atomic für dynamische Inhalte

<div id="status" aria-live="polite"></div>
<script>
// Status-Nachricht setzen
document.getElementById('status').textContent = 'Artikel zum Warenkorb hinzugefügt';
</script>

EN 301 549 Zusatz-Anforderungen über WCAG hinaus

Dokumenten-Accessibility (Kapitel 10)

Betrifft: PDF-Downloads, Office-Dokumente auf Ihrer Website

Anforderungen:

• Strukturierte PDFs: Überschriften, Listen, Tabellen semantisch
• Alt-Texte für Bilder in PDFs
• Leserichtung definiert und korrekt
• Formularfelder in PDFs beschriftet

Praktische Umsetzung:

<!-- PDF-Link mit Warnung -->
<a href="document.pdf" aria-describedby="pdf-info">
  Broschüre herunterladen
</a>
<span id="pdf-info">(PDF, 2MB, barrierefrei)</span>

Biometrische Systeme (Kapitel 5)

Betrifft: Login-Systeme mit Face-ID, Fingerprint etc.

Anforderungen:

• Alternative Authentifizierung ohne Biometrie
• Gleichwertige Sicherheit bei Alternativen
• Opt-out möglich: Nutzer können Biometrie deaktivieren

Videotelefonie-Integration (Kapitel 13)

Betrifft: WebRTC, Zoom-Integration, Video-Chat

Anforderungen:

• Text-Alternativen zu Video-Kommunikation
• Untertitel-Funktionen eingebaut
• Audio-Qualität für Hörgeräte optimiert

Compliance-Checkliste: Ihre 50-Punkte-Prüfung

Sofort prüfbar (automatisiert):

• Alt-Texte: Alle <img> haben alt-Attribute
• Überschriften: Hierarchische h1-h6 Struktur
• HTML-Validität: Keine Syntax-Fehler
• Farbkontraste: Mindestens 4.5:1 für normalen Text
• Fokus-Indikatoren: Sichtbar bei Tab-Navigation
• Labels: Alle Formularfelder haben Labels
• Sprache: html lang-Attribut gesetzt
• Titel: Jede Seite hat eindeutigen Titel

Tools für automatisierte Tests:

• axe-core: Browser-Extension oder JavaScript-Library
• WAVE: Web Accessibility Evaluation Tool
• Pa11y: Command-Line-Tool für CI/CD-Integration

Manuelle Prüfung erforderlich:

• Tastatur-Navigation: Alle Funktionen erreichbar
• Skip-Links: Funktionieren und sind sinnvoll
• Alt-Text-Qualität: Beschreibungen sind aussagekräftig
• Überschriften-Logik: Struktur ergibt inhaltlich Sinn
• Link-Texte: Zweck im Kontext erkennbar
• Fehlermeldungen: Verständlich und hilfreich
• Zeitbegrenzungen: Angemessen oder deaktivierbar
• Bewegte Inhalte: Kontrollen verfügbar

Experten-Testing empfohlen:

• Screenreader-Tests: NVDA, JAWS, VoiceOver
• Voice-Control-Tests: Dragon NaturallySpeaking
• Switch-Navigation: Für motorisch eingeschränkte Nutzer
• Cognitive Load: Verständlichkeit für Menschen mit Lernschwierigkeiten

Häufige Implementierungsfehler vermeiden

Top 10 der häufigsten EN 301 549 Verstöße:

1. Alt-Texte fehlen oder sind schlecht (85% der Websites)
2. Farbkontraste zu niedrig (78% der Websites)
3. Keine Tastatur-Navigation (71% der Websites)
4. Überschriften-Hierarchie falsch (68% der Websites)
5. Formulare ohne Labels (62% der Websites)
6. Skip-Links fehlen (59% der Websites)
7. Focus-Indikatoren unsichtbar (54% der Websites)
8. Links ohne aussagekräftigen Text (51% der Websites)
9. Zeitbegrenzungen ohne Kontrolle (43% der Websites)
10. Status-Nachrichten nicht verfügbar (38% der Websites)

Anti-Pattern vermeiden:

❌ Falsch:

<div className="heading">Überschrift</div>
<span onclick="submit()">Klick hier</span>
<input type="text"> <!-- Ohne Label -->
<img src="photo.jpg"> <!-- Ohne Alt -->

✅ Richtig:

<h2>Überschrift</h2>
<button type="submit">Formular absenden</button>
<label htmlFor="name">Name:</label>
<input type="text" id="name">
<img src="photo.jpg" alt="Produktfoto: Rotes T-Shirt">

Testing-Strategie für EN 301 549 Compliance

3-Stufen-Testing-Pyramide:

Stufe 1: Automated Testing (80% der Prüfungen)

• Täglich: axe-core in CI/CD-Pipeline
• Wöchentlich: WAVE-Tool über komplette Website
• Monatlich: Pa11y-Scans für Regressionstests

Stufe 2: Manual Expert Review (15% der Prüfungen)

• Vierteljährlich: Accessibility-Experte prüft kritische User-Flows
• Focus: Komplexe Interaktionen, ARIA-Implementierungen
• Deliverable: Detaillierter Report mit Prioritäten

Stufe 3: User Testing (5% der Prüfungen)

• Halbjährlich: Tests mit echten Nutzern mit Behinderungen
• Verschiedene Nutzergruppen: Blind, sehbehindert, motorisch eingeschränkt
• Outcome: Qualitative Insights und Usability-Verbesserungen

EN 301 549 Konformitätserklärung

Nach erfolgreicher Umsetzung müssen Sie eine Konformitätserklärung veröffentlichen:

Pflichtinhalte der Erklärung:

1. Geltungsbereich: Welche Teile Ihrer Website sind konform
2. Standards: "EN 301 549 v3.2.1 (entspricht WCAG 2.1 Level AA)"
3. Testmethoden: Automated + Manual + User Testing
4. Bekannte Probleme: Aktuell noch nicht behobene Barrieren
5. Kontakt: Ansprechpartner für Accessibility-Feedback
6. Feedback-Verfahren: Wie Nutzer Barrieren melden können

Beispiel-Template:

Konformitätserklärung Barrierefreiheit

Diese Website entspricht den Anforderungen der EN 301 549 v3.2.1, 
die WCAG 2.1 Level AA Standards integriert.

Letzte Prüfung: [Datum]
Nächste Prüfung: [Datum + 6 Monate]

Kontakt für Accessibility-Fragen: 
barrierefrei@[ihr-unternehmen].de

Häufig gestellte Fragen zu EN 301 549

Was ist der Unterschied zwischen EN 301 549 und WCAG 2.1?

EN 301 549 enthält alle WCAG 2.1 Level A/AA Kriterien, ergänzt diese aber um EU-spezifische Anforderungen für Biometrie, Dokumente und Hardware-Integration.

Muss ich WCAG 2.2 für BFSG-Compliance implementieren?

Nein, BFSG bezieht sich explizit auf EN 301 549, welches auf WCAG 2.1 basiert. WCAG 2.2 ist empfehlenswert, aber nicht verpflichtend.

Sind PDF-Downloads auf meiner Website betroffen?

Ja, alle herunterladbaren Dokumente müssen nach Kapitel 10 der EN 301 549 barrierefrei sein.

Wie oft muss ich meine Website gegen EN 301 549 testen?

Automatisierte Tests täglich, manuelle Experten-Reviews vierteljährlich, Nutzer-Tests halbjährlich.

Kann ich mit einem Overlay-Tool EN 301 549 konform werden?

Nein, Overlay-Tools können nur einen Bruchteil der Anforderungen erfüllen und verursachen oft neue Barrieren.

Was passiert bei dynamischen Inhalten (SPAs, AJAX)?

Diese müssen besonders sorgfältig implementiert werden mit aria-live-Regions für Status-Updates und korrektem Fokus-Management.

Gilt EN 301 549 auch für mobile Apps?

Ja, Kapitel 11 der EN 301 549 behandelt Software und Apps. Native Apps haben teilweise andere Anforderungen als Websites.

Wie dokumentiere ich meine EN 301 549 Compliance?

Mit einer öffentlichen Konformitätserklärung, regelmäßigen Test-Reports und einem Feedback-Verfahren für Nutzer.

Fazit: EN 301 549 als Chancen begreifen

EN 301 549 ist mehr als ein regulatorisches Hindernis - es ist ein Rahmenwerk für inclusive User Experience, das Ihnen hilft, neue Zielgruppen zu erschließen und Ihre Website für alle Nutzer zu verbessern.

Die 50 wichtigsten Anforderungen mögen zunächst überwältigend erscheinen, aber mit systematischem Vorgehen und den richtigen Tools ist EN 301 549 Compliance in 8-12 Wochen erreichbar.

Weiterführende Artikel:

• BFSG 2025: Der ultimative Compliance-Guide für KMU
• WCAG 2.1 vs 2.2 vs 2.3: Welcher Standard gilt 2025?
• Overlay-Mythos entlarvt: Warum AccessiBe & Co. nicht helfen