RGAA-Audit: Ablauf Woche für Woche, Vorbereitung und Lesen des Berichts

Ein RGAA-Audit misst Kriterium für Kriterium, inwieweit eine Website, eine App oder ein Softwarepaket dem französischen Referenzrahmen für digitale Barrierefreiheit entspricht, dem Référentiel général d'amélioration de l'accessibilité (RGAA). Es ist die zwingende Grundlage jeder Erklärung zur Barrierefreiheit in Frankreich, und genau diese Erklärung prüft die Arcom bei ihren Kontrollen. Die meisten Seiten zum Thema beschreiben die Methode; dieser Leitfaden zeigt, wie ein RGAA-Audit tatsächlich abläuft, Woche für Woche, was Ihre Organisation vorbereiten muss, wie die Stichprobe entsteht, was die Ergebnisdokumente enthalten und wie Sie den Bericht lesen, ohne Fachmann zu sein. Er richtet sich auch an Organisationen in Luxemburg, in der Schweiz und in Ostbelgien, die Dienste in Frankreich betreiben oder deren Prüfrahmen nach derselben Logik funktioniert.

RGAA-Audit: was es misst und was nicht

Der RGAA, derzeit in der Version 4.1.2, umfasst 106 Kriterien in 13 Themenbereichen: Bilder, Frames, Farben, Multimedia, Tabellen, Links, Skripte, Pflichtelemente, Strukturierung der Information, Darstellung der Information, Formulare, Navigation sowie Abruf und Nutzung. Jedes Kriterium ist in präzise Tests zerlegt, die der Auditorin oder dem Auditor sagen, was im Code und in der Darstellung zu prüfen ist. Der Referenzrahmen übersetzt damit die Anforderungen der WCAG in ein Raster, mit dem zwei kompetente Prüfer auf derselben Seite zum selben Ergebnis kommen.

Ein RGAA-Audit liefert drei Dinge: einen Status für jedes Kriterium auf jeder bewerteten Seite (erfüllt, nicht erfüllt oder nicht anwendbar), eine Konformitätsquote für den Dienst und die genau verorteten Mängel, die zu beheben sind. Es bewertet weder die Ästhetik noch die allgemeine Gebrauchstauglichkeit noch die redaktionelle Qualität. Eine Website kann eine gute Quote erreichen und für eine blinde Person trotzdem mühsam zu bedienen sein, wenn die Abläufe lang und schlecht durchdacht sind. Deshalb lässt sich das Konformitätsaudit sinnvoll durch einen Test mit Nutzerinnen und Nutzern mit Behinderungen ergänzen.

Ein Audit ist auch kein Durchlauf eines automatischen Werkzeugs. Browser-Erweiterungen erkennen einen Teil der technischen Fehler, können aber nicht beurteilen, ob ein Alternativtext treffend ist, ob die Lesereihenfolge Sinn ergibt oder ob ein Aufklappmenü mit der Tastatur funktioniert. Die offizielle Seite zur Bewertung der Konformität (auf Französisch) beschreibt eine Bewertung Kriterium für Kriterium anhand einer repräsentativen Stichprobe: Diese Bewertung, und nur sie, begründet die in der Erklärung veröffentlichte Quote.

Für die Praxis bedeutet das: Wer einen Bericht erhält, der im Wesentlichen aus Bildschirmfotos eines automatischen Prüfwerkzeugs besteht, hat kein RGAA-Audit in Händen, sondern eine Vorabprüfung. Sie kann nützlich sein, um wiederkehrende Fehler schnell zu finden, sie ersetzt aber weder die manuelle Prüfung noch die Konformitätsquote, die in der Erklärung stehen muss.

Wer ein RGAA-Audit durchführen lassen muss

In Frankreich verpflichtet Artikel 47 des Gesetzes vom 11. Februar 2005 zur Barrierefreiheit und zur Veröffentlichung einer Erklärung: juristische Personen des öffentlichen Rechts, privatrechtliche Organisationen, die unter bestimmten Bedingungen mit einer Aufgabe des öffentlichen Dienstes oder im Allgemeininteresse betraut sind, und Unternehmen, deren in Frankreich erzielter Umsatz 250 Millionen Euro übersteigt. Für diese Organisationen ist das RGAA-Audit keine Option: Ohne tatsächliche Bewertung kann die Erklärung nur den Status „nicht konform“ angeben. Anwendungsbereich und Texte sind auf unserer Seite digitale Barrierefreiheit in Frankreich und in unserer Analyse der französischen Pflichten ausführlich dargestellt.

Ein Unternehmen, das unter den European Accessibility Act fällt, ohne diese Schwelle zu erreichen, folgt einer anderen Logik: Seine Pflichten ergeben sich aus dem französischen Verbraucherschutzgesetzbuch (code de la consommation), wobei die europäische Norm EN 301 549 als technische Referenz dient, und sie werden von der DGCCRF kontrolliert, der französischen Behörde für Wettbewerb, Verbraucherschutz und Betrugsbekämpfung. Ein Audit auf Grundlage der WCAG und der europäischen Norm, wie unser Konformitätsaudit, beantwortet diese Frage direkter als ein RGAA-Audit im engeren Sinn, auch wenn die Arbeitsweise sehr ähnlich ist. Unser Beitrag zum European Accessibility Act erläutert, welche Dienste betroffen sind.

Für Leserinnen und Leser in Luxemburg, der Schweiz und Ostbelgien ist diese Unterscheidung oft die erste Frage: Betreibt Ihre Gruppe einen Dienst, der sich an Nutzer in Frankreich richtet und von einer französischen Gesellschaft oder Stelle verantwortet wird, die unter Artikel 47 fällt? Dann ist das RGAA-Audit für diesen Dienst maßgeblich. Andernfalls gilt der Rahmen Ihres Landes, der im vorletzten Abschnitt dieses Beitrags zusammengefasst ist.

Wann ein RGAA-Audit fällig ist: die sieben auslösenden Situationen

Die Frage lautet nicht nur, ob Sie prüfen lassen müssen, sondern wann. Der RGAA legt Fristen für die Aktualisierung der Erklärung fest, und jede setzt ein aktuelles Audit voraus. Andere Situationen sind keine Pflicht im engeren Sinn, machen ein Audit aber unverzichtbar, wenn Sie keinen falschen Stand veröffentlichen wollen.

Die vierte Zeile sollte man vorausplanen. Die DINUM, die interministerielle Digitaldirektion Frankreichs, hat die Veröffentlichung des RGAA 5, erwartet für Ende 2026 (auf Französisch) angekündigt. Er übernimmt die WCAG 2.2 und wird Kriterien für mobile Apps und Bürodokumente festlegen. Die DINUM stellt klar, dass Arbeiten auf Grundlage des RGAA 4.1.2 keinesfalls ausgesetzt oder verschoben werden sollen: Ein heute durchgeführtes Audit bleibt nützlich, seine Korrekturen behalten ihren Wert, und die daraus hervorgehende Erklärung profitiert von der Frist von achtzehn Monaten.

Bei Lieferungen von Dienstleistern nimmt das Audit die Form einer Barrierefreiheits-Abnahme an: Vor der förmlichen Abnahme wird geprüft, ob die gelieferten Seitenvorlagen und Abläufe die vertraglich geforderten Kriterien einhalten. Das ist weit wirksamer, als die Mängel erst beim nächsten Konformitätsaudit zu entdecken, wenn der Dienstleister das Projekt längst verlassen hat.

Ein Beispiel aus der Praxis: Eine Verwaltung lässt einen neuen Online-Antrag von einer Agentur entwickeln. Wird die Barrierefreiheit erst nach dem Go-live geprüft, sind Korrekturen an Formularkomponenten, Fehlermeldungen und Zusammenfassungsseite eine neue Bestellung. Wird sie vor der Abnahme geprüft, gehören dieselben Korrekturen zur vertraglich geschuldeten Leistung.

Ein RGAA-Audit vorbereiten: die Checkliste der geprüften Organisation

Die meisten Verzögerungen entstehen nicht bei den Prüfern, sondern durch Zugänge, die am ersten Testtag fehlen: ein gesperrtes Testkonto, eine nicht verfügbare Abnahmeumgebung, ein Zahlungsschritt, der sich nicht überwinden lässt. Einige Tage Vorbereitung ersparen eine verlorene Woche. Das ist es, was wir in der Praxis vor dem Kick-off-Termin anfragen.

• der genaue Umfang: Adresse des Dienstes, ein- oder ausgeschlossene Subdomains, Kundenbereiche, mobile Apps, herunterladbare Dokumente;
• die geltende Erklärung zur Barrierefreiheit, der Mehrjahresplan und der Maßnahmenplan, auch wenn sie veraltet sind, um den Abstand zu messen und Verwertbares zu übernehmen;
• Zugriffsstatistiken der meistbesuchten Seiten, die helfen, die Stichprobe repräsentativ zu gestalten;
• die Liste der Seitenvorlagen oder Seitentypen (Artikel, Datenblatt, Ergebnisliste, Formular, Dashboard) und der gemeinsam genutzten Komponenten (Menü, Suchfunktion, Karussell, modale Dialoge);
• Testkonten für jedes Nutzerprofil mit realistischen Daten: Ein leeres Konto zeigt weder Dashboard noch Verlauf;
• eine Möglichkeit, heikle Schritte zu durchlaufen: Testkreditkarte, Code für die starke Authentifizierung über eine erreichbare Ansprechperson, vorübergehende Umgehung eines Captchas in der Abnahmeumgebung;
• die herunterladbaren Dokumente, die für Verwaltungsvorgänge gebraucht werden: PDF-Formulare, Bescheide, Rechnungen, Protokolle;
• die Liste der Module von Drittanbietern (Terminbuchung, Zahlung, Kartendienst, Chat) mit dem Namen des jeweiligen Herstellers;
• eine technische Ansprechperson, die während der Tests verfügbar ist, und das Datum, ab dem keine Änderungen mehr eingespielt werden: Eine Website, die sich während des Audits verändert, liefert widersprüchliche Ergebnisse;
• der Kalender der Rahmenbedingungen: geplantes Go-live, Kontrollfrist, Lenkungsausschuss, in dem die Ergebnisse vorgestellt werden sollen.

Zwei Punkte werden häufig unterschätzt. Zunächst die Module von Drittanbietern: Ein bei einem Hersteller eingekauftes Terminbuchungswerkzeug gehört zu Ihrem Dienst, denn Sie haben es ausgewählt und finanzieren es. Es wird wie alles andere geprüft, und seine Mängel stehen in Ihrer Erklärung. Dann die Umgebung: Ein Audit in der Vorproduktion ist möglich und oft vorzuziehen, sofern diese Version mit der zu veröffentlichenden identisch ist und die Erklärung tatsächlich den Online-Dienst bezeichnet.

Ein typischer Stolperstein ist die starke Authentifizierung. Wenn der Zugang zum Kundenbereich einen per SMS versandten Code verlangt, muss jemand in Ihrer Organisation diesen Code während der Testtage zeitnah weitergeben können. Fehlt diese Person, steht das Audit still, und die Abläufe hinter der Anmeldung, also gerade die wichtigsten, bleiben ungeprüft.

Die Stichprobe des RGAA-Audits: offizielle Regeln und ein kommentiertes Beispiel

Man prüft nicht alle Seiten einer Website, sondern eine Stichprobe, und das Ergebnis gilt für den gesamten Dienst. Deshalb ist die Zusammensetzung der Stichprobe die wichtigste Entscheidung des Audits. Eine Gefälligkeitsstichprobe ergibt eine schmeichelhafte Quote, die der ersten Seite nicht standhält, die ein Kontrolleur nach dem Zufallsprinzip öffnet.

Was die Methode vorschreibt

Die offizielle Methode verlangt zunächst, sofern vorhanden, die Prüfung der Startseite, der Kontaktseite, des Impressums (mentions légales), der Seite zur Barrierefreiheit, der Sitemap, der Hilfe und der Anmeldeseite. Hinzu kommen mindestens eine relevante Seite pro Diensttyp, einschließlich der Suche, mindestens ein relevantes herunterladbares Dokument pro Diensttyp, alle Seiten eines Prozesses (mehrstufiges Formular oder mehrstufige Transaktion) sowie Seiten mit deutlich anderem Aufbau oder Inhalt: Tabellen, Multimedia, Formulare. Zufällig ausgewählte Seiten müssen mindestens 10 % der Seiten der Stichprobe ausmachen. Eine Gesamtzahl von Seiten ist nicht festgelegt; bei einer mobilen App gilt jeder Bildschirm als Seite.

Aus diesem Aufbau folgt eine Regel, die für Abläufe alles verändert: Ein Kriterium gilt für eine Seite eines Prozesses nur dann als erfüllt, wenn es für alle Seiten dieses Prozesses erfüllt ist. Enthält der dritte Schritt eines Online-Antrags ein Feld ohne Beschriftung, ist das betreffende Kriterium für sämtliche Schritte des Ablaufs nicht erfüllt.

Beispiel: der Nutzerbereich einer öffentlichen Einrichtung

Nehmen wir die Website einer öffentlichen Einrichtung, die allgemeine Informationen anbietet und einen Kundenbereich, in dem Nutzerinnen und Nutzer einen Antrag auf eine Beihilfe stellen und dessen Bearbeitung verfolgen. Eine vertretbare Stichprobe könnte so aussehen.

Diese Stichprobe umfasst rund zwanzig Seiten und Bildschirme, darunter die vier Schritte des Antrags. Sie zeigt einen Reflex, den man beibehalten sollte: Jede Funktion, die eine Nutzerin oder ein Nutzer selbstständig erledigen können muss (sich anmelden, einreichen, verfolgen, herunterladen), kommt mindestens einmal vor. Wer das Dashboard oder das PDF weglässt, weil sie schwer zu prüfen sind, nimmt genau das aus dem Audit heraus, was Nutzer blockiert.

Die Liste der geprüften Seiten steht anschließend mit ihren Adressen in der Erklärung zur Barrierefreiheit. Sie wird damit öffentlich: Jede Nutzerin, jeder Nutzer und die Arcom kann nachprüfen, ob die Stichprobe die Prozesse wirklich enthält. Unser Beitrag zur Erklärung zur Barrierefreiheit zeigt im Detail, wie diese Liste darzustellen ist und welche Berechnung daraus folgt.

Der Ablauf eines RGAA-Audits, Woche für Woche

In unserer Kanzlei beträgt die durchschnittliche Dauer eines Audits drei Wochen vom Start bis zur Übergabe des Berichts. Diese Dauer hängt von der Größe der Stichprobe, der Zahl der Abläufe und Plattformen sowie von der Verfügbarkeit der Zugänge ab. Der folgende Ablauf entspricht einer Website üblicher Komplexität mit Kundenbereich.

1. Vor dem Start: die Abstimmung des Rahmens. Ein Gespräch von ein bis zwei Stunden legt den Referenzrahmen und seine Version, den Umfang, die vorläufige Liste der Stichprobe, die Testumgebung und die Ansprechpersonen fest. Sie übermitteln die Punkte der Vorbereitungs-Checkliste. Der Prüfer kontrolliert die Zugänge und meldet sofort, was fehlt.
2. Woche 1: Freigabe der Stichprobe und erste Tests. Die Stichprobe wird gemeinsam mit Ihnen festgelegt, einschließlich der zufällig gezogenen Seiten. Der Prüfer beginnt mit den Pflichtseiten und den gemeinsam genutzten Komponenten (Kopfbereich, Menü, Fußzeile, Suche): Ein Mangel in einer gemeinsamen Komponente wiederholt sich auf allen Seiten, und wer ihn früh erkennt, muss ihn nicht zwanzigmal beschreiben.
3. Woche 2: Abläufe, Formulare und assistive Technologien. Die Prozesse werden Schritt für Schritt mit den Testkonten geprüft. Dynamische Komponenten (Aufklappmenüs, Registerkarten, modale Dialoge, Fehlermeldungen, Inhalte, die beim Überfahren mit der Maus erscheinen) werden mit Screenreadern und per Tastatur getestet. Die herunterladbaren Dokumente werden kontrolliert. Ein Zwischenstand meldet etwaige schwerwiegende Blockaden, ohne auf den Bericht zu warten.
4. Woche 3: Konsolidierung, Bericht und Präsentation. Die Ergebnisse werden auf Ebene des Dienstes konsolidiert, die Konformitätsquote wird berechnet, jede Nichtkonformität wird mit einem Beispiel und einer Empfehlung beschrieben. Eine interne Gegenlesung prüft, ob die Status zwischen den Seiten stimmig sind. Bei der Präsentation werden die Ergebnisse den Fach- und Technikteams vorgestellt, anschließend werden Bericht, Prüfraster und Entwurf der Erklärung übergeben.
5. Nach der Übergabe: Korrekturen und Nachaudit. Ihre Teams oder Dienstleister beheben die Mängel anhand des Maßnahmenplans. Ein kürzeres Nachaudit prüft die Korrekturen auf denselben Seiten, und die Erklärung wird mit der neuen Quote aktualisiert.

Zwei Faktoren verlängern diesen Zeitplan fast immer: ein Zugang, der während der Tests in der zweiten Woche fehlt, und ein Produktivgang während des Audits. Ersteres lässt sich durch Vorbereitung vermeiden, Letzteres durch einen Änderungsstopp oder, ersatzweise, durch das im Bericht angegebene Datum der geprüften Version.

Für Ihre interne Planung ist es hilfreich, die Termine von Anfang an festzuhalten: den Kick-off, den Zwischenstand in der zweiten Woche und die Präsentation. Wenn die Ergebnisse einem Lenkungsausschuss oder einem politischen Gremium vorgelegt werden sollen, legen Sie die Präsentation einige Tage vor dessen Sitzung, damit Fragen noch geklärt werden können.

Was der Prüfer tatsächlich tut: Tests, Werkzeuge und Testumgebung

Für jede Seite der Stichprobe geht der Prüfer die 106 Kriterien durch. Ein großer Teil ist auf einer bestimmten Seite nicht anwendbar (kein Video, keine Tabelle, kein Frame); die übrigen werden Test für Test im Code und in der Darstellung geprüft. Sobald ein einziges Element der Seite einen Test nicht besteht, ist das Kriterium für diese Seite nicht erfüllt.

Ein Beispiel: das Online-Antragsformular

Bei einem einzigen Formularschritt prüft der Prüfer unter anderem, ob jedes Feld eine Beschriftung hat (Kriterium 11.1) und ob die Schaltflächen eine aussagekräftige Bezeichnung tragen (Kriterium 11.9), ob die Eingabekontrolle Fehler und Pflichtfelder wahrnehmbar anzeigt, auch für Screenreader (Kriterium 11.10), ob Skripte, die Felder ein- oder ausblenden, mit assistiven Technologien kompatibel (Kriterium 7.1) und per Tastatur bedienbar sind (Kriterium 7.3), ob der Fokus sichtbar bleibt (Kriterium 10.7), ob die Tabulatorreihenfolge schlüssig ist (Kriterium 12.8) und ob die Nutzerin oder der Nutzer nie in einer Tastaturfalle festsitzt (Kriterium 12.9). Er misst die Kontraste des Textes (Kriterium 3.2) und der Feldrahmen (Kriterium 3.3) und kontrolliert, dass Informationen nicht allein über die Farbe vermittelt werden, etwa durch ein fehlerhaftes Feld, das lediglich rot umrandet ist.

Diese Aufgliederung erklärt, warum ein einziger Mangel die Quote teuer zu stehen kommen kann: Eine fehlende oder falsch mit ihrem Feld verknüpfte Fehlermeldung macht Kriterium 11.10 auf der Seite nicht erfüllt, damit für den ganzen Prozess und damit für den Dienst. Sie erklärt auch, warum sich eine schlecht gebaute Komponente, die in allen Formularen der Website wiederkehrt, mit einem Eingriff beheben lässt.

Werkzeuge und Testumgebung

Der Prüfer arbeitet mit dem Code-Inspektor des Browsers, einem Kontrastanalysator, Prüf-Erweiterungen, die das Auffinden wiederkehrender Fehler beschleunigen, und einer systematischen Tastaturnavigation. Bei dynamischen Komponenten prüft er die Ausgabe mit assistiven Technologien. Der RGAA veröffentlicht eine Referenz-Testumgebung (auf Französisch): am Computer Kombinationen aus NVDA oder JAWS mit Firefox sowie VoiceOver mit Safari; mobil TalkBack mit Chrome unter Android und VoiceOver mit Safari unter iOS. Eine Komponente gilt als kompatibel, wenn sie mit mindestens einer Kombination vollständig funktioniert; für eine öffentlich zugängliche Website, die auch mobil genutzt wird, empfiehlt der Referenzrahmen, in beiden Umgebungen zu testen.

Die verwendeten Kombinationen, die Werkzeuge und ihre Versionen werden anschließend im Bericht und in der Erklärung angegeben. Das ist eine Garantie für Sie: Ein Ergebnis, das mit einer nicht dokumentierten Kombination erzielt wurde, ließe sich beim Nachaudit kaum reproduzieren.

Die Ergebnisse eines RGAA-Audits: Bericht, Prüfraster, Maßnahmenplan und Erklärung

Die DINUM stellt ein Audit-Kit (auf Französisch) bereit, das eine Vorlage für den Bericht, eine Vorlage für die Erklärung und das Prüfraster des RGAA 4.1.2 als Tabellendatei enthält; auf derselben Seite wird Ara vorgestellt, ein Online-Werkzeug, das die Erfassung der Ergebnisse strukturiert und Bericht und Erklärung erzeugt. Ara ist kein automatisches Werkzeug: Es setzt einen Prüfer voraus, der die 106 Kriterien kennt. Ein professionelles Audit stützt sich auf diese Vorlagen oder übernimmt ihre Struktur, was den Vergleich zweier aufeinanderfolgender Audits ermöglicht.

Die offizielle Vorlage für den Auditbericht (PDF, auf Französisch) ordnet die Beschreibung der Fehler nach Themenbereichen. Für jedes nicht konforme Kriterium sieht sie eine kurze Darstellung des Kriteriums vor, einen repräsentativen Fall mit Bildschirmfoto bei Bedarf, die Beschreibung des Problems und eine technische Empfehlung. Ihr Schluss enthält eine Einschätzung des Prüfers, verfasst für ein nicht technisches Publikum, und eine Priorisierung der Korrekturen nach drei Achsen: die wesentlichen Funktionen und Inhalte, die Kriterien, die den Zugang blockieren, und die Einfachheit der Umsetzung. Das Prüfraster im Anhang gibt die Ergebnisse Seite für Seite wieder.

Bestehen Sie darauf, dass jede Nichtkonformität verortet (Seite, Komponente, Element) und mit einer Empfehlung versehen ist, mit der eine Entwicklerin oder ein Entwickler arbeiten kann. Eine Zeile wie „Kriterium 1.1 nicht konform“ ohne Beispiel zwingt Ihre Teams, einen Teil des Audits zu wiederholen, um die Mängel zu finden.

Achten Sie auch auf die Sprache. Bericht und Erklärung eines RGAA-Audits werden in der Regel auf Französisch erstellt, weil die Erklärung auf einem französischen Dienst veröffentlicht wird. Arbeiten Ihre Entwicklungsteams in Luxemburg, in der Schweiz oder in Ostbelgien auf Deutsch, klären Sie bei der Abstimmung des Rahmens, in welcher Sprache Maßnahmenplan und Empfehlungen geliefert werden.

Einen RGAA-Auditbericht lesen, ohne Experte zu sein

Ein Bericht von fünfzig Seiten kann eine Geschäftsführerin oder einen Bürgermeister verunsichern. Er lässt sich dennoch in zehn Minuten lesen, wenn man weiß, wo man hinschauen muss und in welcher Reihenfolge.

1. Die globale Konformitätsquote. Sie ist das Verhältnis zwischen erfüllten und anwendbaren Kriterien, berechnet über die gesamte Stichprobe: (erfüllte Kriterien ÷ anwendbare Kriterien) × 100. Eine Quote von 100 % ergibt einen vollständig konformen Dienst, eine Quote von mindestens 50 % einen teilweise konformen Dienst, darunter ist er nicht konform. Diese Quote, und nur sie, steht in der Erklärung.
2. Die Durchschnittsquote. Sie ist der Mittelwert der Quoten der einzelnen Seiten. Sie liegt fast immer höher als die globale Quote, weil ein vereinzelter Fehler nur auf einer Seite ins Gewicht fällt. Sie ist nützlich, um einen Fortschritt zu verfolgen, ersetzt aber nie die globale Quote.
3. Die Zahl der anwendbaren Kriterien. Eine sehr niedrige Zahl anwendbarer Kriterien sollte Fragen aufwerfen: Entweder ist der Dienst tatsächlich einfach, oder Inhalte wurden ausgeklammert. Nicht anwendbare Kriterien sind nur gerechtfertigt, wenn der Inhalt nicht existiert, ausgenommen ist oder unter eine Ausnahmeregelung mit barrierefreier Alternative fällt.
4. Die Blockaden vor der Zahl der Mängel. Suchen Sie in der Zusammenfassung nach den Mängeln, die die Erledigung einer Aufgabe verhindern: sich anmelden, bezahlen, einen Antrag stellen, einen Bescheid herunterladen. Ein Kontrastmangel bei einem Nebenhinweis und eine per Tastatur nicht bedienbare Bestätigungsschaltfläche zählen jeweils als ein Kriterium, haben aber nicht dieselbe Wirkung.
5. Die gemeinsam genutzten Komponenten. Erkennen Sie die Mängel, die aus der Seitenvorlage, dem Menü oder der Komponentenbibliothek stammen: Ihre Behebung verbessert alle Seiten auf einen Schlag.
6. Die Inhalte, die Sie nicht selbst in der Hand haben. Notieren Sie die Mängel, die einem Modul eines Herstellers zuzurechnen sind. Sie werden über die Vertragsbeziehung gelöst, nicht durch Ihre Entwickler.

Nehmen wir eine Stichprobe, in der 52 Kriterien anwendbar und 39 erfüllt sind: Die Quote beträgt 75 %, der Dienst ist teilweise konform. Erreicht die Durchschnittsquote pro Seite 88 %, dann sind die meisten der 13 nicht erfüllten Kriterien nur auf einer oder zwei Seiten fehlerhaft, oft im selben Ablauf. Die richtige Lesart lautet also: ein insgesamt ordentlicher Dienst, bei dem ein Ablauf vorrangig überarbeitet werden muss. Die genaue Berechnung und ihre Fallstricke behandelt unser Beitrag zur Erklärung zur Barrierefreiheit und zur Konformitätsquote.

Was eine Kontrolle der Arcom über die Qualität eines Audits verrät

Seit 2023 kontrolliert die Arcom, die französische Regulierungsbehörde für audiovisuelle und digitale Kommunikation, die Einhaltung von Artikel 47. Ihre Entscheidung Nr. 2026-358 vom 24. Juni 2026 zur Website impots.gouv.fr (im Amtsblatt veröffentlicht, auf Französisch) ist für jede Organisation lehrreich, die ein Audit vorbereitet, denn die beanstandeten Mängel betreffen genau die Inhalte, die Gefälligkeitsstichproben auslassen.

• ein Steuerbescheid als PDF, herunterladbar aus dem Bereich für Privatpersonen, ohne Titel, ohne festgelegte Sprache, ohne Tagging und ohne barrierefreie Alternative (Kriterium 13.3);
• in der gesicherten Nachrichtenfunktion eine Rubrik „Schreiben“ (Écrire), die per Tabulatortaste nicht erreichbar ist und deren Informationen von Screenreadern nicht ausgegeben werden (Kriterium 10.8);
• in derselben Nachrichtenfunktion ein Aufklappmenü zur Auswahl des Steuerjahres, das nur mit der Maus erscheint und daher per Tastatur nicht bedienbar ist (Kriterium 12.11);
• im Formular der Online-Einkommensteuererklärung (Rubrik der nicht gewerblichen möblierten Vermietung) eine Tabelle, deren Zellen nicht mit ihren Überschriften verknüpft sind (Kriterium 5.7);
• ein Dienst, dessen Erklärung mangels Audit keine Quote angab.

Aus einem Kundenbereich heruntergeladene Dokumente, Nachrichtenfunktion, dynamische Auswahlfelder, Tabellen in einem Formular: Alle diese Inhalte liegen hinter einer Anmeldung. Ein Audit, das sich auf die öffentlichen Seiten beschränkt, sieht sie nicht. Die Behörde hat neun Monate für die Behebung der Barrierefreiheitsmängel eingeräumt und zwei Monate, um die Erklärungen zur Barrierefreiheit in Ordnung zu bringen und den Maßnahmenplan des laufenden Jahres zu veröffentlichen. Für den öffentlichen Sektor greifen diese Anforderungen mit der öffentlichen Beschaffung und der Steuerung ineinander, die auf unserer Seite öffentlicher Sektor beschrieben sind.

Die Lehre für die Auswahl der Stichprobe ist einfach: Wenn ein Kontrolleur sich nach der Anmeldung zuerst die Dokumente und die Nachrichtenfunktion ansieht, muss Ihr Audit diese Bereiche ebenfalls abdecken. Eine Erklärung, die nur die öffentlichen Seiten bewertet, kann eine gute Quote zeigen und dennoch genau die Mängel übersehen, die zu einer Inverzugsetzung führen.

Nach dem RGAA-Audit: Korrekturen, Nachaudit und Erklärung

Das Audit verbessert für sich genommen nichts; erst die Korrekturen verändern den Alltag der Nutzerinnen und Nutzer und die Quote. Die Zeit nach der Übergabe des Berichts entscheidet über den Wert der Investition.

Sofort einen zutreffenden Stand veröffentlichen

Veröffentlichen Sie unmittelbar nach der Übergabe des Berichts die Erklärung, die den Ergebnissen entspricht, auch wenn sie ungünstig ausfallen, und passen Sie den Hinweis auf der Startseite an. Eine zutreffende Erklärung „teilweise konform“ erfüllt die Transparenzpflicht; wer mit der Veröffentlichung bis zum Ende der Korrekturen wartet, lässt monatelang einen falschen Stand oder gar keine Erklärung online.

In der richtigen Reihenfolge korrigieren

Beginnen Sie mit den Blockaden in den wesentlichen Abläufen, dann mit den gemeinsam genutzten Komponenten, zuletzt mit den vereinzelten Mängeln. Binden Sie jede Korrektur in den normalen Entwicklungsprozess ein, mit einem Akzeptanzkriterium, das den Test des RGAA übernimmt: Das verhindert den Rückfall in der nächsten Version. Wenn die Mängel in der Architektur des Frontends liegen, vermeidet eine Begleitung bei der barrierefreien Entwicklung, dass Seite für Seite korrigiert wird, was sich in der Komponentenbibliothek lösen lässt.

Konkret heißt das zum Beispiel: Statt in jedem Formular einzeln Fehlermeldungen nachzurüsten, wird die Formularkomponente der Bibliothek so angepasst, dass jede Fehlermeldung mit ihrem Feld verknüpft und für Screenreader wahrnehmbar ist. Alle Formulare, die diese Komponente verwenden, profitieren von der Korrektur, auch die künftigen.

Nachaudit und Aktualisierung

Das Nachaudit prüft die Korrekturen auf den Seiten der ursprünglichen Stichprobe. Es ist kürzer als das Audit, muss aber ebenso gründlich sein: Ein Kriterium, das auf einer Seite korrigiert wurde und auf einer anderen fehlerhaft bleibt, ist weiterhin nicht erfüllt. Die neue Quote wird mit dem Datum der Aktualisierung in die Erklärung übernommen. Die nicht behobenen Mängel fließen in den Maßnahmenplan des Jahres ein, der an den Mehrjahresplan anknüpft.

Schulen, um nicht von vorn anzufangen

Ein Audit deckt fast immer Mängel auf, die mit Arbeitsweisen zusammenhängen: ohne Methode verfasste Bildalternativen, ohne Tagging exportierte PDF-Dateien, Komponenten, die von einem Projekt ins nächste kopiert werden. Gezielte Schulungen nach Rolle (Redaktion, Konzeption, Entwicklung, Einkauf) verringern die Zahl der Mängel beim nächsten Audit dauerhaft.

Internes oder externes RGAA-Audit: wie Sie wählen und Angebote vergleichen

Die offizielle Methode lässt die Selbstbewertung ebenso zu wie das an Dritte vergebene Audit, sofern es zuverlässig und repräsentativ ist: Die Organisation sorgt mit allen Mitteln für die Verlässlichkeit ihrer Erklärung, sei es über einen externen Dienstleister, geschulte interne Fachleute oder gegenseitige Audits. Die Unternehmen nach Nummer 4 von Artikel 47, also jene, die die Umsatzschwelle überschreiten, dürfen sogar eine andere Testmethode verwenden, sofern sie auf Anfrage mitgeteilt werden kann, mit einer Entsprechungstabelle zur Norm versehen ist und in der Erklärung angegeben wird.

Ein internes Audit ist sinnvoll, wenn Sie über Prüferinnen und Prüfer verfügen, die im RGAA geschult sind, assistive Technologien beherrschen und die Website nicht selbst konzipiert haben. Ein externer Blick begrenzt das Risiko einer überhöhten Quote und liefert einen Nachweis der Unabhängigkeit, der bei einer Kontrolle nützlich ist. Viele Organisationen kombinieren beides: ein externes Audit alle drei Jahre oder bei jedem Relaunch, interne Prüfungen bei jeder Version.

Fragen, die Sie vor der Wahl eines Prüfers stellen sollten

• Bewertet das Audit die 106 Kriterien manuell, Seite für Seite, oder beruht es auf einem automatischen Werkzeug?
• Enthält die vorgeschlagene Stichprobe die Pflichtseiten, die vollständigen Prozesse, herunterladbare Dokumente und mindestens 10 % zufällig gezogener Seiten?
• Welche Kombinationen assistiver Technologien werden verwendet, und werden sie im Bericht angegeben?
• Umfassen die Ergebnisse das vollständige Prüfraster, einen priorisierten Maßnahmenplan und den Entwurf der Erklärung?
• Ist jede Nichtkonformität verortet und mit einer Korrekturempfehlung versehen?
• Ist ein Nachaudit vorgesehen, mit welchem Umfang und in welcher Frist?
• Sind die Prüfer unabhängig von den Teams, die den Dienst konzipiert oder entwickelt haben?

Was das Budget betrifft, gibt es keinen Referenzpreis: Die Kosten hängen von der Zahl der Seiten und Seitenvorlagen, der Komplexität der Abläufe, der Zahl der Plattformen, den zu bewertenden Dokumenten und den begleitenden Leistungen ab. Um zwei Angebote zu vergleichen, prüfen Sie, ob sie dieselbe Stichprobe, denselben Referenzrahmen und dieselben Ergebnisdokumente abdecken. Am einfachsten beschreiben Sie uns Ihren Dienst über die Seite Kontakt: Nach einem Abstimmungsgespräch nennen wir in unserem Angebot die Stichprobe und die Dauer.

Ein Angebot, das deutlich günstiger ist als ein anderes, erklärt sich meist durch einen dieser Punkte: weniger Seiten, ein ausgeklammerter Kundenbereich, keine Tests mit assistiven Technologien, kein Nachaudit oder ein Bericht ohne verortete Empfehlungen. Legen Sie die Angebote nebeneinander und vergleichen Sie Zeile für Zeile, bevor Sie den Preis vergleichen.

Fehler, die ein RGAA-Audit verfälschen

Die folgenden Fehler finden sich in zahlreichen Berichten und veröffentlichten Erklärungen. Jeder von ihnen führt zu einer Quote, die nicht der Erfahrung der Nutzerinnen und Nutzer entspricht.

1. Nur die öffentlichen Seiten prüfen. Verwaltungsvorgänge, Kundenbereiche und die dort heruntergeladenen Dokumente bündeln die Blockaden.
2. Seiten auswählen, statt sie auszulosen. Die Regel von 10 % zufällig gezogener Seiten soll übersehene Seitenvorlagen aufdecken.
3. Einen Prozess zerstückeln. Den ersten und den letzten Schritt eines Antrags zu prüfen, reicht nicht: Alle Schritte gehören zur Stichprobe.
4. „Nicht anwendbar“ vervielfachen. Ein Kriterium ist nur dann nicht anwendbar, wenn der Inhalt nicht existiert, ausgenommen ist oder unter eine Ausnahmeregelung mit barrierefreier Alternative fällt.
5. Werkzeug-Score und Konformitätsquote verwechseln. Ein automatischer Score deckt nur einen Teil der Kriterien ab und beurteilt nicht die inhaltliche Angemessenheit.
6. Module von Drittanbietern ignorieren. Ein eingekauftes und integriertes Werkzeug gehört zum geprüften Dienst.
7. Eine Website in Bewegung prüfen. Ohne Änderungsstopp beschreiben die Ergebnisse einer Seite nicht mehr die Online-Version.
8. Die Umgebung nicht dokumentieren. Ohne angegebene Testkombinationen kann das Nachaudit die Ergebnisse nicht reproduzieren.
9. Die Durchschnittsquote statt der globalen Quote veröffentlichen. Der Konformitätsstatus ergibt sich ausschließlich aus der globalen Quote.
10. Das Audit als Endpunkt betrachten. Ohne Maßnahmenplan, Korrekturen und Nachaudit liefert das nächste Audit dasselbe Ergebnis.

RGAA-Audit in Belgien, Luxemburg und der Schweiz: welches Gegenstück

Der RGAA ist ein französischer Referenzrahmen. Außerhalb Frankreichs bleibt die Arbeitsweise sehr ähnlich, aber das Prüfraster ändert sich, und ein RGAA-Audit ist nicht immer der beste Nachweis der Konformität.

In Luxemburg übernimmt der RAWeb die Logik aus Kriterien und Tests des RGAA und passt sie an die Norm EN 301 549 an; mobile Apps fallen unter den RAAM, den wir in unserem RAAM-Audit von iOS- und Android-Apps anwenden. In Belgien ist die europäische Norm der Bezugspunkt, in allen drei Regionen. In der Schweiz dient die Norm eCH-0059 den Verwaltungen als Referenz. Für eine Gruppe, die in mehreren Ländern tätig ist, vermeidet ein Leitreferenzrahmen, dass sich die Audits vervielfachen: Unser Beitrag zu den Normen der digitalen Barrierefreiheit erklärt, wie man ihn wählt, und die Beiträge zu Belgien, zu Luxemburg und zur Schweiz beschreiben die Pflichten vor Ort.

Praktisch lassen sich die meisten Erkenntnisse dieses Leitfadens auf diese Länder übertragen: die Vorbereitung der Zugänge, die Aufnahme vollständiger Prozesse und herunterladbarer Dokumente in die Stichprobe, die Prüfung mit Screenreadern und per Tastatur, die verorteten Empfehlungen, das Nachaudit. Was sich ändert, ist das Raster, an dem jede Seite gemessen wird, und damit die Form des Berichts und der Erklärung. Eine Gruppe mit Sitz in Luxemburg und einem französischen Dienst kann beispielsweise denselben Ablauf und dieselben Testkonten für ein RAWeb-Audit und ein RGAA-Audit nutzen und so die Vorbereitung nur einmal leisten.

Musterzeitplan: von der Entscheidung für ein Audit bis zur veröffentlichten Erklärung

Für einen Dienst üblicher Komplexität ist folgender Zeitplan realistisch. Er setzt voraus, dass die Zugänge zum Start bereitstehen und die Korrekturen ab der Präsentation eingeplant werden. Er fügt sich in das Gesamtvorgehen ein, das unser Leitfaden zur digitalen Barrierefreiheit beschreibt.

Die Dauer der Korrekturen schwankt weit stärker als die des Audits: einige Wochen, wenn sich die Mängel auf wenige Komponenten konzentrieren, mehrere Monate, wenn die Architektur des Frontends überarbeitet werden muss. Wenn Sie Ihr Audit planen möchten, stellt unsere Seite RGAA-Audit den Inhalt der Leistung vor, und Großunternehmen, die unter Artikel 47 fallen, finden dort dieselben Ergebnisdokumente.

Ein letzter Hinweis für die Budgetplanung: Rechnen Sie das Nachaudit und die Schulungen von Anfang an in den Zeitplan ein. Wer nur das Audit beauftragt, hat am Ende einen genauen Befund, aber noch keinen barrierefreien Dienst und keine Gewähr, dass die nächste Version die erreichten Fortschritte bewahrt.

Häufige Fragen