Image Accessibility and Alt Text Delivery: CDN Strategies for Inclusive Content

A few years ago I was auditing a retail site that had just moved to a shiny new image CDN. Pages loaded in under a second, but when I turned on VoiceOver, half the product gallery was silent. The images were there, the CDN was blazing fast, yet the alt text never made it to the browser. That’s when it clicked for me — we’d optimized for pixels and completely forgotten about people.

Where Alt Text Gets Lost Between Origin and Edge

When you’re new to CDNs, it’s easy to think of them as a dumb cache for your images. You upload a JPEG, the CDN copies it to 300+ PoPs, and everyone gets it faster. That’s true for the bytes, but alt text doesn’t live inside the JPEG. It lives in your HTML, your CMS, or sometimes a headless API that your front-end pulls at build time. If those two pipelines aren’t connected, your edge can serve a perfect image with zero context for assistive tech.

I’ve seen this happen most often with image transformation URLs. You know the pattern: /cdn-cgi/image/width=800,format=auto/product-123.jpg. Your origin CMS might store a great description like “women's navy wool peacoat with anchor buttons, front view”, but your image CDN is only asked to resize and compress. By the time the browser requests that transformed image, the HTML that should have carried the alt attribute was generated by a different service that didn’t have access to the CMS field. The result is what I call “decorative by accident” — meaningful images treated as decoration because the description fell through the cracks.

Earlier in my career I worked on a media site where we kept alt text in a separate translation table. It worked fine until we enabled aggressive HTML caching at the edge. The cached HTML was stale, and new alt text updates never purged correctly. Screen readers kept announcing outdated descriptions for weeks. That taught me to treat image accessibility like any other cache invalidation problem — you need a single source of truth and a clear way to bust the cache when it changes. If you’re mapping out how your origin, cache, and processing layers connect, this Image CDN Architecture Design: Building a Scalable Image Processing Pipeline breaks down the flow really well.

<!-- The disconnect: CMS has alt text, but edge-transformed HTML doesn't -->
<!-- CMS / Origin API response -->
{
  "image_id": "product-123",
  "cdn_url": "https://cdn.example.com/image/width=800/product-123.jpg",
  "alt_text": "Women's navy wool peacoat with anchor buttons, front view",
  "is_decorative": false
}

<!-- What the CDN actually served to the browser (alt missing) -->
<img src="https://cdn.example.com/image/width=800/product-123.jpg">

<!-- What it should have served -->
<img src="https://cdn.example.com/image/width=800/product-123.jpg" 
     alt="Women's navy wool peacoat with anchor buttons, front view">

Delivering Alt Text Reliably From the Edge

You don’t need to re-architect your whole stack to fix this. The simplest pattern I’ve come to rely on is to keep alt text with the image metadata at the origin and make sure your edge can read it when it assembles HTML. For most teams that means your CMS or DAM is the source of truth, and your front-end or edge worker pulls from it at render time, not at image-request time. That way even when the CDN creates 10 resized variants for srcset, they all share the same description from one place.

A practical approach for beginners is to use an edge worker to inject or validate alt text rather than trying to bake it into the image file itself. I’m not a fan of stuffing descriptions into EXIF or XMP — screen readers don’t read that, and you’ll just create confusion. Instead, let your worker fetch a small JSON manifest from origin (or KV store) and ensure every <img> has either a meaningful alt or an explicit empty alt="" for decorative images. The specs from the HTTP Working Group Specifications are pretty clear that content negotiation should be about format, not meaning, so don’t try to swap alt text via Accept headers or image bytes.

We did this for a news client last year and it solved a second problem we hadn’t seen coming: responsive variants. Their editors wrote one alt text, but the CDN was generating srcset automatically without carrying it through. Once we moved alt text injection to the HTML edge worker, all variants inherited the correct description. If you’re automating responsive images, you’ll want to read through Responsive Image CDN Automation: Generating srcset Variants on the Fly first — it’ll save you from duplicating alt text logic in five different places. The guidance in web.dev Articles on accessible images also aligns with this: one canonical alt per image concept, not per file variant.

// Example: Cloudflare Worker / Fastly Compute pattern for alt text injection
// Keep a lightweight manifest in KV / Edge Dictionary
// manifest.json: { "product-123.jpg": "Women's navy wool peacoat..." }

async function handleRequest(request) {
  let response = await fetch(request);
  let html = await response.text();

  // Simple validation: warn if meaningful images lack alt
  html = html.replace(/<img([^>]*?)src="([^"]+product-(\d+)\.jpg)"([^>]*?)>/g, (match, before, src, id, after) => {
    if (match.includes('alt=')) return match;
    const alt = await getAltFromManifest(`product-${id}.jpg`);
    // If no alt found, mark as needing review rather than leaving silent
    const finalAlt = alt || "";
    const altAttr = alt ? `alt="${finalAlt}"` : `alt="" data-alt-missing="true"`;
    return `<img${before}src="${src}" ${altAttr}${after}>`;
  });
  
  return new Response(html, response);
}

How Delivery Choices Affect Real Users and Performance

There’s a common worry I hear from beginners: “If we add alt text checks at the edge, won’t it slow everything down?” In practice, the overhead is tiny compared to image bytes, but the way you implement it does matter. I’ve measured this trade-off a lot, especially when teams are trying to balance accessibility with Balancing Lazy Loading and Preloading with CDN: Optimal Image Loading Strategies. You don’t want your accessibility fix to wreck your Largest Contentful Paint.

What actually hurts performance isn’t the alt text itself — it’s doing synchronous origin lookups for every single HTML request. That’s why I recommend caching the alt manifest at the edge for at least 60 seconds and validating alt presence at build time where you can. Think of it this way: the HTML document is small, the images are huge. A 300-byte JSON lookup at the edge is noise, but a 2MB unoptimized hero image without an alt is a double failure — slow and inaccessible. Getting the basics right means your accessible images don’t cost you speed.

The goal for inclusive content isn’t just passing an automated audit. I run a quick manual check with a screen reader and keyboard only after every CDN change, because automated tools will miss “alt text exists but is useless” like alt="image123.jpg". Track both technical and human metrics and you’ll see where your CDN strategy is really helping.

Practical Implementation: Building an Alt-Aware Edge Pipeline

We’ve seen teams with perfect Lighthouse accessibility scores at origin drop to 68-74 after enabling aggressive image optimization at the edge. It isn’t a bug in your CMS — it’s pipeline design. If your CDN is fetching, transforming, and re-serving images without carrying the semantic layer with them, you’re stripping accessibility at scale. The fix isn’t to disable optimization; it’s to make alt text a first-class citizen in your edge logic, just like cache-control or content-type.

The most reliable pattern we deploy for enterprise clients doesn’t embed alt text in the image binary itself. Instead, we decouple it. You’ll store a lightweight manifest — typically a JSON map of canonical image URLs to alt strings — in an edge KV store like Cloudflare Workers KV, Fastly Edge Dictionary, or AWS DynamoDB Global Tables. Your edge function then intercepts HTML responses, not image responses, and injects or validates the alt attribute before it hits the browser. This keeps your image cache hit ratio high (we typically see 96-98.5% for transformed images) while adding only 8-15ms of TTFB overhead for HTML documents, which is negligible compared to the 120-250ms you save with edge caching. It also survives image transformations like WebP/AVIF conversion, resizing, and compression where inline metadata would be stripped.

Don’t try to preserve alt text by keeping EXIF or XMP fields intact — that’s a losing battle. Most performance-focused image pipelines intentionally strip all metadata to shave 12-35KB per image, and that behavior is correct for privacy. As we covered in Image Metadata Stripping at CDN Edge: EXIF Removal for Privacy and Performance, you *want* that stripping for GDPR and performance, but you need a separate channel for accessibility metadata. The manifest approach gives you that separation. It also lets you update alt text without purging multi-gigabyte image caches — a KV update propagates globally in under 60 seconds versus a full image cache purge that can take 5-15 minutes and spike origin load by 300%.

// Edge Worker: Inject alt text from KV manifest into HTML response
// Compatible with Cloudflare Workers / Fastly Compute@Edge
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const response = await fetch(request);
  const contentType = response.headers.get('content-type') || '';
  
  // Only process HTML documents - never image binaries
  if (!contentType.includes('text/html')) return response;

  const html = await response.text();
  // ALT_MANIFEST is a global KV namespace: { "/images/hero-1200.jpg": "Team collaborating..." }
  const manifest = await ALT_MANIFEST.get('alt-map-v2', 'json');
  if (!manifest) return new Response(html, response);

  const patched = html.replace(/<img([^>]*?)src="([^"]+)"([^>]*?)>/g, (match, pre, src, post) => {
    if (/alt\s*=/i.test(match)) return match; // Don't overwrite author-provided alt
    const cleanSrc = src.split('?')[0].split('#')[0];
    const alt = manifest[cleanSrc];
    return alt ? `<img${pre}src="${src}" alt="${alt.replace(/"/g, '&quot;')}"${post}>` : match;
  });

  return new Response(patched, {
    headers: { ...response.headers, 'x-alt-injected': '1' },
    status: response.status
  });
}

Advanced Patterns and Troubleshooting When Alt Text Still Vanishes

If you’ve implemented a manifest but screen readers still announce “graphic” or skip images entirely, you’re likely hitting one of three edge cases we troubleshoot weekly. First, responsive images with srcset and <picture> elements. Your edge HTML rewriter might patch the fallback src but ignore srcset URLs that resolve to different transformed variants like hero-480w.avif or hero-800w.webp. You’ll need to normalize all candidate URLs back to their canonical key before lookup, or your alt injection will miss 40-60% of mobile traffic. Second, client-side lazy loading. If you’re using a CDN-injected lazy-load placeholder that replaces src with data-src, ensure your alt attribute travels with the placeholder — we’ve seen placeholders generate <img data-src="..."> with no alt at all, which fails WCAG 1.1.1 immediately.

Third, and trickier, are composite delivery methods like sprites and SVGs. When you combine icons into a single sprite sheet for performance, the accessibility model changes completely. A single background-image sprite has no alt attribute by definition, so you must provide accessible names via aria-label or off-screen text on the element using it. We detail those trade-offs in CSS Sprite Generation and CDN Optimization: When Sprites Still Beat HTTP/2 — sprites can still save 6-12 HTTP requests and 18-22% load time on icon-heavy pages, but only if you don’t sacrifice semantics to get there. For SVGs, the problem is different: if your CDN serves them as external <img src="icon.svg">, alt text works normally, but if you inline them at the edge for performance — a common technique we break down in SVG Delivery Optimization Through CDN: Inline, External, and Sprite Approaches — you’ll need to ensure <title> and role="img" are injected, not alt. External SVG + alt and inline SVG + title are not interchangeable.

For debugging, don’t rely on View Source. What the edge serves to a screen reader and what you see in DevTools can differ due to ESI or edge-side HTML streaming. Instead, curl your edge directly with curl -H "Accept: text/html" -A "Mozilla/5.0" https://your-edge-url/page | grep -i "alt=" and compare it to the origin response curl --resolve your-origin:443:ORIGIN_IP https://your-origin/page. Log your edge function’s x-alt-injected header and sample 1-2% of responses in your observability platform. If you’re seeing cache HITs serving stale HTML without alt text after a manifest update, you haven’t configured cache key variation correctly — set your HTML TTL to 60-300s with stale-while-revalidate=86400 and purge by surrogate key on manifest changes, not by URL.

Frequently Asked Questions