Was ist ein Accessibility Conformance Report (ACR)?

Was ist ein Accessibility Conformance Report (ACR)?

Ein Accessibility Conformance Report (ACR) ist ein Dokument, das deklariert, in welchem Umfang ein digitales Produkt (Website, Web-App, Mobile-App, Software, Hardware) Barrierefreiheits-Standards erfüllt — primär WCAG (Web Content Accessibility Guidelines) und Section 508 des US Rehabilitation Act. ACRs werden typischerweise mit dem VPAT (Voluntary Product Accessibility Template) erstellt, das vom Information Technology Industry Council (ITI) publiziert wird und ein standardisiertes Format zum Reporting gegen jedes WCAG-Erfolgskriterium bietet.

Ein ACR ist keine Zertifizierung oder ein Audit — es ist eine Vendor-Selbstattestierung. Der Vendor listet jedes anwendbare WCAG-Kriterium und reportet, ob das Produkt Supports, Partially Supports, Does Not Support oder Not Applicable. Ehrliche ACRs enthalten erklärende Notizen zu Edge Cases und bekannten Issues. Marketing-getriebene ACRs claimen volle Unterstützung ohne Evidenz — und brechen üblicherweise unter echten Audits zusammen.

Warum ACRs existieren

Drei Treiber:

• US-Bundes-Beschaffung. Section 508 verlangt von Bundesbehörden, barrierefreie Technologie zu kaufen. ACRs sind der Standard-Weg, wie Vendoren Konformität während der Beschaffung demonstrieren — von GSA Schedule 70 und den meisten Behörden-RFPs verlangt.
• Hochschul- und Großunternehmens-Beschaffung. Universitäten und Fortune-500-Käufer verlangen zunehmend ACRs als Teil ihrer RFP-Antworten. Beschaffungsteams nutzen sie als Filter.
• EU EAA (European Accessibility Act). Wirksam ab Juni 2025, verlangt der EAA Barrierefreiheits-Statements für viele in der EU verkaufte digitale Produkte. Vendoren mit ACRs sind vor-positioniert, die Anforderungen des EAA mit minimalem Zusatzaufwand zu erfüllen.

Was ein ACR enthält (VPAT-2.x-Format)

Das aktuelle VPAT-2.5-Format (neueste Stand 2026) deckt vier Standards in einem Dokument ab:

• WCAG 2.1 (Levels A und AA). 50+ Erfolgskriterien über die vier POUR-Prinzipien (Perceivable, Operable, Understandable, Robust).
• Revised Section 508. US-Bundes-Beschaffungs-Standard, seit 2018 mit WCAG 2.0 harmonisiert.
• EN 301 549. Europäischer Standard für ICT-Barrierefreiheit, unter dem EAA verpflichtend.
• WCAG 2.2 (in VPAT 2.5+). Neuere Erfolgskriterien (Target-Size, Focus-Appearance, etc.).

Für jedes Kriterium listet der ACR:

1. Konformitäts-Level (Supports / Partially Supports / Does Not Support / Not Applicable).
2. Anmerkungen und Erklärungen — konkrete Details zu was getestet wurde, bekannte Issues, Workarounds und Roadmap für nicht unterstützte Kriterien.

Wie man einen glaubwürdigen ACR schreibt

Teste, bevor du schreibst

Der größte Fehler: ACR aus Feature-Dokumentation schreiben, ohne tatsächlich zu testen. Bevor irgendein Kriterium "Supports" bekommt, automatisierte Scanner (axe, WAVE) UND manuelles Screen-Reader-Testing (NVDA auf Windows, VoiceOver auf Mac/iOS, TalkBack auf Android) durchführen. Dokumentiere, was du getestet hast, auf welchen Plattformen, mit welchen Assistive Technologies.

Sei ehrlich über "Partially Supports"

Fast jedes echte Produkt unterstützt viele Kriterien teilweise. Häufige ehrliche Partial-Support-Szenarien: "Tastaturnavigation funktioniert für die Haupt-Flows, aber das Dropdown-Widget auf der Settings-Seite trappt den Fokus" oder "Alt-Text ist für Produktbilder vorgesehen, aber auto-generierte Charts haben keine beschreibenden Text-Alternativen". Diese ehrlich zu dokumentieren baut Käufer-Vertrauen auf; sie zu verstecken kommt im Audit des Käufers raus und tötet den Deal.

Mit jedem Major-Release aktualisieren

Ein 18 Monate alter ACR-Snapshot ist schlimmer als kein ACR — er führt Käufer aktiv über den aktuellen Zustand in die Irre. Mit jedem Major-UI-Release re-testen und re-publishen.

Hol dir ein externes Audit für High-Stakes-Deals

Für große Regierungs- oder Hochschul-Verträge können Käufer drittauditierte ACRs verlangen. Spezialfirmen (Deque, Level Access, TPGi) auditieren dein Produkt gegen WCAG und produzieren einen auditierten ACR. Teurer, aber glaubwürdiger.

Häufige ACR-Fehler

• "Supports" ohne Testing claimen. Sales-getriebene ACRs, die sagen, alles funktioniert, failen Käufer-Audits und schädigen den Ruf.
• Veraltete VPAT-Version. Käufer erwarten VPAT 2.4 oder 2.5; eine 2.0 von 2018 einzureichen wirkt nachlässig.
• Keine Anmerkungen. Nur "Supports" ohne Erklärung zu listen liefert keine nützliche Information. Käufer wollen wissen, was getestet wurde und wie.
• ACR als Marketing behandeln. Ein ACR ist Beschaffungs-Dokumentation, kein Sales-Sheet. Ehrlich, technisch, evidenz-basiert.
• Vergessen zu aktualisieren. Veraltete ACRs sind schlimmer als fehlende ACRs — sie repräsentieren den aktuellen Zustand aktiv falsch.
• Plattformen mischen. Wenn dein Produkt eine Web-App + iOS-App + Android-App + Desktop-App hat, kann jede einen eigenen ACR brauchen (oder einen klar segmentierten kombinierten).

FAQ: Accessibility Conformance Reports

Ist ein ACR dasselbe wie ein VPAT?

Eng verwandt, aber technisch unterschiedlich. Das VPAT ist die Vorlage (ein leeres Formular). Der ACR ist das ausgefüllte Dokument (ein vollständiges VPAT für ein spezifisches Produkt). In der Praxis werden die Begriffe oft austauschbar verwendet — "Schick mir dein VPAT" bedeutet üblicherweise "Schick mir deinen ACR".

Wer schreibt den ACR?

Typischerweise: eine interne Accessibility-Lead oder Produktmanagerin + Ingenieure, die spezifische Features getestet haben + manchmal ein externer Auditor für Verifikation. Größere Firmen haben dedizierte Accessibility-Programme; kleinere Firmen mieten oft Spezialisten für VPAT-Engagements.

Wie lange dauert es, einen ACR zu schreiben?

Für ein kleines Produkt: 2-4 Wochen fokussierter Aufwand, hauptsächlich Testing-Zeit. Für eine große Enterprise-App: 2-3 Monate inklusive Koordination mit Produkt-, Design- und Engineering-Teams. Auditierte ACRs dauern länger.

Wie viel kostet ein externes Audit?

10.000-50.000+ $ je nach Produkt-Komplexität. Lohnt sich für hochwertige Verträge, in denen Käufer unabhängige Verifikation verlangen oder wo Reputation zählt.

Können automatisierte Tools den ACR generieren?

Nein — automatisierte Tools (axe, WAVE, Pa11y) fangen vielleicht 30-40% der Barrierefreiheits-Issues. Sie sind nützlich für skaliertes Scannen, aber die Glaubwürdigkeit des ACR kommt von manuellem Testing mit Assistive Technologies. Tools augmentieren menschliches Testing; sie ersetzen es nicht.

Braucht meine SaaS einen ACR, wenn wir nicht an die Regierung verkaufen?

Empfohlen auch ohne Regierungs-Kunden. Hochschulen, Fortune-500-Unternehmen und EU-Kunden (unter dem EAA ab Juni 2025) verlangen zunehmend ACRs. Einen auf deiner Website veröffentlichten ACR zu haben signalisiert Beschaffungs-Bereitschaft und beschleunigt Enterprise-Deals.

Wie LoadFocus zu Barrierefreiheits-Audits steht

Während LoadFocus auf Performance fokussiert, nicht auf Barrierefreiheit, brauchen Barrierefreiheits-Audits oft auch Performance-Verifikation — Seiten, die Core Web Vitals failen, erstellen Barrierefreiheits-Issues für Nutzer in langsamen Netzwerken oder auf Low-End-Geräten. Kombiniere deine VPAT/ACR-Arbeit mit LoadFocus-Speed-Audits über Regionen, um barrierefreiheits-unterstützende Performance-Baselines zu validieren (z.B. sicherstellen, dass Screen-Reader-Nutzer auf 3G-Verbindungen weiterhin angemessene Seiten-Ladezeiten erhalten).