The team ships an "RGAA-compliant" redesign. Two weeks later, complaints pile up: low-vision users wait eight seconds before the menu appears, the CDN serves yesterday's cached error page, the WAF blocks the automated validator. The HTML is clean; infrastructure is not.
Digital accessibility — RGAA, WCAG, the European Accessibility Act — rests first on content, design, and development. But unsuitable hosting can prevent an otherwise compliant site from being usable: latency, downtime, bad TLS or CDN configuration, overly aggressive security rules. Ignoring that layer means publishing fragile compliance at the first traffic spike.
What infrastructure controls — and what it does not
Three overlapping scopes need clear ownership before any audit.
Outside the host's scope — your responsibility: contrast, text alternatives, semantic structure, keyboard navigation, properly labelled forms, focus management. No hosting contract signs your accessibility statement for you.
Shared scope: perceived performance, stability, HTTPS compatibility, HTTP headers (Cache-Control, Content-Type, Content-Language), no platform-injected scripts. You configure; the host delivers the layer that carries them.
Host-only scope: uptime, shared or VPS capacity, CDN point-of-presence location, WAF rules, rate limiting. These levers are often missing from accessibility test plans.
| User symptom | Possible infra cause | Diagnostic lead |
|---|---|---|
| Intermittent blank page | CPU/RAM saturation | Monitor load, upgrade tier |
| Form submission timeout | Time to first byte > 3 s | Cache, PHP-FPM, database |
| Validator blocked | WAF / bot fight | Audit IP whitelist |
| Media not loading | Hotlink protection | CDN or host rule |
A perfect Lighthouse score locally means nothing if shared hosting fails every newsletter traffic spike.
Perceived performance: a forgotten accessibility criterion
Accessibility standards are not markup-only. A site that takes ten seconds to respond effectively excludes users on limited mobile connections, people with cognitive fatigue, or anyone who must memorise a slow interface between interactions.
Measure time to first byte and Largest Contentful Paint in production, not only on local staging. Saturated shared hosting, undersized databases, or misconfigured CDN degrade assistive experiences as much as a missing alt attribute.
RGAA criteria tied to uptime for essential services cross directly with host SLA and status pages. If your site is treated as a public or essential service, downtime is not just a technical incident — it is an access barrier.
CDN, compression, and WAF: silent traps
A CDN speeds delivery — but can also transform HTML, aggressively compress assets, cache error pages, or inject bot-management scripts. Each transformation is a risk for screen readers and assisted browsers.
Blind "auto-minify" on dynamic pages is especially dangerous: it can strip ARIA attributes, break tab order, or alter semantic structure. Test after every CDN change, with and without a screen reader.
Application firewalls sometimes block audit bots (pa11y, WAVE, RGAA validators) mistaken for malicious traffic. Plan temporary IP whitelists for testing, or an unfiltered staging mirror. Otherwise your latest audit date may reflect an environment nobody actually uses.
Hosting good practices
Staging environment: run pa11y, axe-core, or RGAA tests on a stable URL with server configuration matching production before major releases.
CDN without breaking HTML: avoid blind automatic optimisations on dynamic pages; document every transformation rule.
Documented availability: cross-check contract SLA, status page, and external monitoring over at least thirty days.
Audit tool access: temporarily allow test IPs or provide a staging mirror reachable by automated validators.
Compare offers via the directory on documented performance and support quality — not shared price alone.
The climax
Decide and move forward without blind spots
Start by measuring time to first byte and availability over thirty days in production, from several regions if your audience is European. Then test with a screen reader on the live URL — not only on your local machine. Adjust CDN and WAF configuration while documenting each change. Finally, compare performance-oriented hosts via the compare tool and guides to choose a tier suited to your load.
Frequently asked questions
Is the host responsible for site accessibility?
Not for content and application code — the publisher signs the statement. The host still influences availability, perceived performance, TLS, and HTTP headers, all of which can degrade assistive experiences. A passing local audit guarantees nothing if production is slow or unstable.
Is a slow site an accessibility issue?
Yes, for users on limited connections, older devices, or with cognitive fatigue. High response times or saturated shared hosting make the interface unusable before any WCAG HTML error is detected. Perceived performance is part of accessible experience.
Can a CDN break accessibility?
Yes: aggressive compression, HTML transformation, cached error pages, geo-blocking, or uncontrolled third-party scripts. Every CDN enable or change should be followed by screen-reader and automated validator testing.
What should you ask the host concretely?
HTTP/2 or HTTP/3, stable certificates, no arbitrary audit-bot blocking, logs for 403/503 diagnosis, a documented availability SLA, and a staging environment for automated tests.
Accessibility is verified where users struggle — often on saturated shared hosting, not in a static HTML report.