Die Revised 508 Standards: WCAG 2.0 AA, Software, Hardware und Dokumentation

Problem in der Praxis

Anbieter, die nach europäischen Vorgaben entwickeln, orientieren sich oft an neueren WCAG-Fassungen. Für Section 508 ist WCAG 2.0 Level A und AA der rechtliche Bezugspunkt. Hinzu kommen die Regeln für Nicht-Web-Software und Dokumente, die WCAG-Begriffe wie "Web page" durch "software" oder "document" ersetzen. Wer nur seine Webanwendung prüft, übersieht Desktop-Clients, PDF-Handbücher und Hardware-Bedienteile.

CISO-Einordnung

• Elektronische Inhalte (E205): öffentlich zugängliche Inhalte immer; nicht öffentliche Inhalte, wenn sie amtliche Kommunikation einer der in E205.3 genannten Kategorien sind (etwa Notfallmeldungen, Formulare und Vorlagen, Schulungsmaterial, als Webseite gestaltete Intranet-Inhalte); nach Bundesarchivrecht von NARA verwahrte Unterlagen sind ausgenommen, solange sie nicht öffentlich zugänglich sind. Maßstab: WCAG 2.0 Level A und AA; bei Nicht-Web-Dokumenten ohne die vier genannten Kriterien.
• Software (E207): wenn sie Informationen überträgt oder eine Benutzeroberfläche hat, Kapitel 5 und WCAG 2.0 Level A und AA für Benutzeroberflächen und Inhalte; Ausnahmen für Software, die selbst unterstützende Technologie ist und die Barrierefreiheitsdienste der Plattform unterstützt; für Nicht-Web-Software ohne die vier Kriterien und ohne die Konformitätsanforderung "Complete Processes", dafür E207.3.
• Hardware (E206): Kapitel 4, wenn sie Informationen überträgt oder eine Benutzeroberfläche hat.
• Support (E208): Kapitel 6 für Support-Dokumentation und -Dienste, die eine Behörde bereitstellt.
• Funktionale Leistungskriterien (E204): für Funktionen, die Kapitel 4 und 5 nicht abdecken.
• Zugang zu allen Funktionen (E203): direkt oder über unterstützende Technologien; Behörden ermitteln die Bedürfnisse von Nutzern mit Behinderungen.

Die WCAG 2.0 sind ein Werk des W3C und sind durch Verweis einbezogen; dieser Artikel nennt nur Nummern und Kurztitel der Ausnahmen.

Umsetzungsperspektive

• Alle Bestandteile eines Angebots einordnen: Web, Nicht-Web-Software, Dokumente, Hardware, Support.
• Gegen WCAG 2.0 Level A und AA prüfen, mit den Sonderregeln für Nicht-Web-Software und -Dokumente.
• Kapitel 4 und 6 für Hardware und Dokumentation einbeziehen.
• Ergebnisse so dokumentieren, dass sie in einen Accessibility Conformance Report einfließen können (s508-003).

Typische Fehler

1. Nur die Webanwendung wird geprüft, Desktop-Clients und PDF-Dokumente nicht.
2. Eine neuere WCAG-Fassung wird angegeben, ohne die Zuordnung zu WCAG 2.0 darzustellen.
3. Die Ausnahmen für Nicht-Web-Inhalte werden auf Webinhalte übertragen.
4. Support-Dokumentation wird nicht barrierefrei bereitgestellt.
5. Hardware-Bedienteile werden übersehen.

Risiken und Trade-offs

Eine Ausrichtung an neueren WCAG-Fassungen kann WCAG 2.0 mit abdecken, verlangt aber eine nachvollziehbare Zuordnung. Vollständige Prüfung aller Bestandteile ist aufwendig, vermeidet aber Lücken, die in der Bewertung durch die Behörde auffallen.

Entscheidungspunkte

• Welche Bestandteile hat das Angebot, und welche Kapitel gelten?
• Wie wird gegen WCAG 2.0 Level A und AA geprüft?
• Wer verantwortet die Barrierefreiheit von Dokumentation und Support?

Praktische Empfehlungen

1. Ordnen Sie alle Angebotsbestandteile den Abschnitten E205 bis E208 zu.
2. Prüfen Sie gegen WCAG 2.0 Level A und AA mit den Nicht-Web-Sonderregeln.
3. Beziehen Sie Hardware und Support-Dokumentation ein.
4. Dokumentieren Sie Prüfmethoden und Ergebnisse nachvollziehbar.
5. Stellen Sie die Zuordnung zu neueren WCAG-Fassungen transparent dar.

Relevante Normreferenzen

• 36 CFR Part 1194, Anhang A (E203 bis E208) und Anhang C (Kapitel 3 bis 6) (eCFR, Stand 07.10.2026).
• WCAG 2.0 (W3C), durch Verweis einbezogen (nur Bezug).