Das Team veröffentlicht ein „RGAA-konformes“ Redesign. Zwei Wochen später häufen sich die Beschwerden: sehbehinderte Benutzer, die acht Sekunden warten, bevor sie das Menü anzeigen, CDN, das eine seit dem Vortag zwischengespeicherte Fehlerseite bereitstellt, Anwendungs-Firewall, die den automatischen Validator blockiert. Der HTML-Code ist sauber; Infrastruktur ist es nicht.
Digitale Barrierefreiheit – RGAA, WCAG, europäische Richtlinie zur Barrierefreiheit – basiert hauptsächlich auf Inhalt, Design und Entwicklung. Aber ungeeignetes Hosting kann die Nutzung einer ansonsten konformen Site verhindern: Latenz, Nichtverfügbarkeit, schlechte TLS- oder CDN-Konfiguration, übermäßig strenge Sicherheitsregeln. Das Ignorieren dieser Schicht bedeutet, dass die fragile Compliance ab der ersten Belastungsspitze freigegeben wird.
Was die Infrastruktur kontrolliert – und was nicht
Drei Bereiche überschneiden sich und die Verantwortlichkeiten müssen vor jeder Prüfung klar sein.
Außerhalb des Hosting-Bereichs – Ihre Verantwortung: Kontraste, Textalternativen, semantische Struktur, Tastaturnavigation, korrekt beschriftete Formulare, Fokusverwaltung. Kein Hosting-Vertrag unterzeichnet Ihre Erklärung zur Barrierefreiheit für Sie.
Gemeinsamer Bereich: wahrgenommene Leistung, Stabilität, HTTPS-Kompatibilität, HTTP-Header („Cache-Control“, „Content-Type“, „Content-Language“), Fehlen von von der Plattform oder dem Administrationsbereich eingefügten Skripten. Sie konfigurieren; Der Host stellt die Schicht bereit, die sie überträgt.
Reiner Hosting-Bereich: Verfügbarkeit, gemeinsame oder VPS-Kapazität, Standort der CDN-Präsenzpunkte, Anwendungs-Firewall-Regeln, Durchsatzbegrenzung. Dies sind Hebel, die in Plänen für Barrierefreiheitstests oft vergessen werden.
| Benutzersymptom | Mögliche Infrastrukturursache | Diagnosepfad |
|---|---|---|
| Zeitweise leere Seite | Prozessor- oder Speichersättigung | Auslastung überwachen, aktualisieren |
| Frist für die Einreichung des Formulars | Reaktionszeit auf erstes Byte > 3 s | Cache, PHP-FPM, Datenbank |
| Validator blockiert | Anwendungs-Firewall / Anti-Bot | Audit-IP-Whitelist |
| Medien nicht geladen | Anti-Direktlink-Schutz | CDN- oder Host-Regel |
Ein perfekter lokaler Lighthouse-Score ist wertlos, wenn der geteilte Score mit jedem Höhepunkt des Newsletter-Verkehrs sinkt.
Wahrgenommene Leistung: ein vergessenes Zugänglichkeitskriterium
Barrierefreiheits-Benchmarks beschränken sich nicht nur auf Markup. Eine Website, die de facto zehn Sekunden braucht, um zu reagieren, schließt Benutzer mit einer eingeschränkten mobilen Verbindung, Menschen mit kognitiver Ermüdung oder solche, die sich eine langsame Schnittstelle zwischen zwei Interaktionen merken müssen, aus.
Messen Sie die Reaktionszeit des ersten Bytes und den größten Contentful Paint in der Produktion, nicht nur im lokalen Staging. Eine ausgelastete gemeinsame Plattform, eine schlecht dimensionierte Datenbank oder ein schlecht konfiguriertes CDN verschlechtern das Hilfserlebnis genauso stark wie ein Bild ohne „Alt“-Attribut.
Die RGAA-Kriterien, die mit der Betriebszeit für wesentliche Dienste verknüpft sind, überschneiden sich direkt mit dem Host-SLA und der Statusseite. Wenn Ihre Website als öffentlicher Dienst oder als wesentlicher Dienst gilt, ist die Nichtverfügbarkeit nicht nur ein technischer Vorfall, sondern eine Zugangsbarriere.
CDN, Komprimierung und Firewall: die stillen Fallen
Ein CDN beschleunigt die Bereitstellung – kann aber auch HTML transformieren, Ressourcen aggressiv komprimieren, Fehlerseiten zwischenspeichern oder Bot-Management-Skripte einschleusen. Jede Transformation ist ein Risiko für Screenreader und unterstützte Browser.
Besonders gefährlich sind Optimierungen der „automatischen Minimierung“ auf dynamischen Seiten: Sie können ARIA-Attribute entfernen, die Tab-Reihenfolge aufheben oder die semantische Struktur verändern. Testen Sie nach jeder Änderung der CDN-Konfiguration, mit und ohne Bildschirmleseprogramm.
Die Anwendungs-Firewall blockiert manchmal Prüfroboter (pa11y, WAVE, RGAA-Validatoren), die mit bösartigem Datenverkehr verwechselt werden. Stellen Sie eine temporäre Whitelist für Test-IPs oder einen ungefilterten Staging-Spiegel bereit. Ohne dies kann es sein, dass Ihr letzter Prüfungstermin in einer Umgebung stattfindet, die eigentlich niemand sieht.
Best Practices auf der Hosting-Seite
Vorproduktionsumgebung: Führen Sie vor jeder Hauptversion pa11y-, axe-core- oder Ihre RGAA-Tests unter einer stabilen URL aus, die hinsichtlich der Serverkonfiguration mit der Produktion identisch ist.
CDN ohne Unterbrechung von HTML konfiguriert: Vermeiden Sie blinde automatische Optimierungen auf dynamischen Seiten; Dokumentieren Sie jede Transformationsregel.
Dokumentierte Verfügbarkeit: Vergleichen Sie das vertragliche SLA, die Statusseite und die externe Überwachung über einen Zeitraum von mindestens dreißig Tagen.
Zugriff auf Prüftools: Test-IPs vorübergehend zulassen oder einen Staging-Spiegel bereitstellen, der für automatische Validatoren zugänglich ist.
Vergleichen Sie Angebote über das Verzeichnis, indem Sie auf die dokumentierte Leistung und Qualität des Supports achten – nicht nur auf den Preis des gemeinsam genutzten Dienstes.
Der Gipfel
Entscheide dich und gehe ohne blinden Fleck voran
Beginnen Sie mit der Messung der Reaktionszeit des ersten Bytes und der 30-Tage-Verfügbarkeit in der Produktion, und zwar aus mehreren Regionen, wenn Ihr Publikum Europäer ist. Testen Sie dann mit einem Screenreader die tatsächliche URL – nicht nur auf Ihrem lokalen Computer. Passen Sie die CDN- und Anwendungs-Firewall-Konfiguration an und dokumentieren Sie jede Änderung. Vergleichen Sie abschließend leistungsorientierte Hoster über den Vergleicher und die Ratgeber, um ein an Ihre Bedürfnisse angepasstes Angebot auszuwählen.
Häufig gestellte Fragen
Ist der Hoster für die Erreichbarkeit der Website verantwortlich?
Nein für den Inhalt und den Anwendungscode: Es ist der Publikationsmanager, der die Erklärung unterzeichnet. Der Host beeinflusst jedoch die Verfügbarkeit, die wahrgenommene Leistung, TLS- und HTTP-Header, was allesamt das Erlebnis der unterstützenden Technologie beeinträchtigen kann. Ein erfolgreiches lokales Audit garantiert nichts, wenn die Produktion langsam oder instabil ist.
Ist eine langsame Website ein Problem mit der Barrierefreiheit?
Ja, für Benutzer mit eingeschränkter Verbindung, mit alten Geräten oder in einer Situation kognitiver Erschöpfung. Hohe Antwortzeiten oder ein gesättigter Pool machen die Schnittstelle unbrauchbar, bevor ein WCAG-Fehler im HTML erkannt wird. Die wahrgenommene Leistung ist Teil des zugänglichen Erlebnisses.
Kann CDN die Barrierefreiheit beeinträchtigen?
Ja: aggressive Komprimierung, HTML-Transformation, zwischengespeicherte Fehlerseiten, Geoblocking oder unkontrolliert eingeschleuste Skripte von Drittanbietern. Auf jede CDN-Aktivierung oder -Änderung müssen ein Screenreader-Test und automatische Validatoren folgen.
Was genau können Sie vom Gastgeber verlangen?
HTTP/2 oder HTTP/3, nahtlose Zertifikate, keine willkürliche Blockierung von Audit-Bots, Protokolle zur Diagnose von 403- und 503-Fehlern, ein dokumentiertes Verfügbarkeits-SLA und eine Staging-Umgebung für automatisierte Tests.
Die Barrierefreiheit wird dort überprüft, wo Benutzer darunter leiden – oft auf einer überlasteten freigegebenen Website, nicht in einem statischen HTML-Bericht.