How this was measured
On 2026-10-17 we requested the homepage of each of the same 78 hand-picked domains our other surveys use — news, commerce, SaaS, developer tooling, social, streaming, reference, SEO, education, finance, cloud, local and government — and parsed every <img> tag in the HTML we got back. Each request identified itself as a survey crawler and was attempted directly first, then through a local proxy; 42 domains answered on the direct path and 20 needed the proxy.
62 of 78 returned HTML we could parse (79.5%), using a 2 KB floor. The other 16 are counted as undecidable, not as absent: no response at all from nytimes.com, reuters.com, washingtonpost.com, etsy.com, quora.com and coinbase.com; 202 from amazon.com and booking.com; 403 from ebay.com, stackoverflow.com, npmjs.com, searchengineland.com, yelp.com and nih.gov; 406 from uber.com; and a 1,951-byte response from archive.org that was too small to be a homepage.
Seven of the 62 then produced no images at all — reddit.com, x.com, pinterest.com, tumblr.com, youtube.com, twitch.tv and nodejs.org. Six are JavaScript shells; nodejs.org is something else entirely, and we come back to it in Finding 8. That leaves 55 homepages carrying 2,418 images, a median of 31 each, ranging from 1 to 189.
Four parsing decisions shaped every number below, and three of them changed an answer. Tracking pixels are counted separately. An image with width="1" height="1" or display:none is a measurement beacon, not content — ahrefs.com ships two Facebook and LinkedIn pixels and paypal.com one, and leaving them in would put nonsense values into every rate below. Blank data URIs are not images. asana.com inlines the same 1×1 transparent GIF 93 times; our first pass judged blankness by string length and counted all 93 as real photographs, which invented a large block of missing-alt images. We now match the base64 prefix instead, and 133 placeholders across 8 sites are excluded. <img alt> written as a bare attribute is an empty alt, not a missing one. HTML gives a valueless attribute the empty string, so wikipedia.org, wikimedia.org, w3.org, kubernetes.io and gitlab.com — 33 images in total — are writing "decorative" in an unusual way, and our first pass reported them as defects. Inline JavaScript, styles and templates are masked before parsing, because a string inside a bundle is not an element in the document.
Finding 1: the largest group of images says it is decorative
Of the 2,418 images, 2,278 (94.2%) carry an alt attribute — and 957 of those (39.6%) set it to the empty string. Per site the median is 25.7% decorative, so this is not one outlier dragging a pooled number: roughly a quarter to a half of the images on a typical homepage here are announced as carrying no information.
That is the correct mark for a huge share of them. Icon strips, spacers, background flourishes and the logo repeated in the header and footer all should be silent, and the alternative — giving every decorative image a descriptive alt — is worse for a screen reader user than saying nothing. The number is a statement about what homepages are made of, not about neglect.
What is missing is the other half of the convention. 858 of the 957 empty-alt images (89.7%) carry neither aria-hidden="true" nor role="presentation". An empty alt already removes the image from the accessibility tree in every current browser, so nothing is broken; the pairing is belt-and-braces for older assistive technology and for the case where a script later writes a value into alt. Only 112 images here are explicitly hidden and 4 are given a presentation role, which tells you how rarely anyone writes the second half.
Finding 2: 5.8% have no alt at all, and one site is half of them
140 images (5.8%) have no alt attribute in any form, and 41 of the 55 homepages have zero of them. Subtracting images that do have an accessible name from another attribute leaves 136 confirmed gaps (5.6%). The per-site median is 0%, which is the honest summary: the typical homepage in this sample has solved this, and a minority has not.
The tail is almost entirely one site. bbc.com accounts for 71 of the 140, and all 71 are the same thing: <img src="…/grey-placeholder.png" class="… hide-when-no-script" aria-label="image unavailable"/>, repeated 71 times. Those are React placeholder slots waiting for a client-side swap, they have an accessible name through aria-label, and Google does not read aria-label on an <img> — it reads alt. So the page is accessible to a screen reader and invisible to image search, and the fix is one empty alt on a template.
Remove bbc.com and the rest of the list is small and specific: screamingfrog.co.uk 23 of 34 (service icons in its homepage navigation), go.dev 16 of 56 (social and community logos), ahrefs.com 11 of 108, zoom.us 4, wise.com 4, bloomberg.com 3, w3.org 2, and one each on theguardian.com and cnn.com. Two of the top three are SEO software vendors, which is the kind of detail that makes this worth publishing.
Finding 3: a bare alt is an empty alt, and five sites write it
Attributes do not need values, and HTML assigns the empty string when one is absent. That makes <img alt> and <img alt=""> the same instruction. 33 images across 5 homepages are written in the valueless form: wikimedia.org 15, wikipedia.org 7, w3.org 5, kubernetes.io 4 and gitlab.com 2.
We report it because our own first pass got it wrong. A parser that only recognises alt= sees no attribute at all and files these as missing, which is the opposite of what the markup says. It is the same trap as crossorigin on a preload — it looks like a missing value and is actually a complete one. Every one of the 33 was checked against the raw tag before being reclassified.
Finding 4: alt text is short, and one newsroom fills it with filenames
Among the 1,284 alt strings long enough to analyse (37 more were dropped because the page came back in a non-Latin script), the median alt is 20 characters and 3 words. 19.4% are a single word and 24.8% run to ten words or more — a wide spread with no consensus in the middle. 78 alts (6.1%) exceed 125 characters, the length at which screen readers start feeling like they are reading a paragraph; the longest, 553 characters, is on cnn.com.
The single-word end is mostly legitimate: slack, shopify, amazon, hubspot — the name of the company whose logo it is, which is exactly right. Only 8 alts in the whole sample are three characters or fewer ("Go", "W3C", "Yep", "P&G") and all of them are correct for what they label.
Then there is cnn.com. 31 of its alts are the content management system's filename, extension included: "IMG_3049.jpg", "map-4.jpg", "Split1.jpg", "9x16_1.jpg", "CobbThumbClean.jpg", "SASKYA THUMBNAIL.png". Across the whole sample 39 alts (3.0%) are identical to the image's own filename, spread over 12 sites, and zoom.us supplies four of the remainder with "[email protected]" and "[email protected]". This is the failure mode everyone warns about and few expect to find on a top-ten news site: the field was filled by a CMS default, nobody overrode it, and a screen reader announces the file name.
Two things the audit-tools love to flag barely exist here. Alt text beginning "image of" or "picture of" appears once in 1,284. Alts that are a bare number or a hash appear zero times. And 53 alt strings beyond the first copy repeat five or more times on the same page, which is template repetition rather than a mistake — the same four featured-story cards rendered in four sections.
Finding 5: lazy loading is the default, and it reaches the first image on 13 sites
1,442 images (59.6%) carry loading="lazy", 119 (4.9%) are explicitly eager, and 857 (35.4%) say nothing. 36 of 55 homepages use it at least once and 19 never do; among users, the median share of images deferred is 51.7%.
The interesting question is where it starts. On 13 of 55 homepages (23.6%) the first image in source order is lazy-loaded: walmart.com, target.com, github.com, atlassian.com, notion.so, trello.com, developer.mozilla.org, ahrefs.com, semrush.com, stanford.edu, wise.com, squareup.com and netlify.com.
Read the tags and that list splits cleanly in two, which matters before anyone calls it a bug. Seven of the 13 are logos or decorative art — walmart.com's spark mark, github.com's background particles with alt="" and aria-hidden="true", atlassian.com's "Team 26 EU logo", developer.mozilla.org's tiled Mozilla logo, semrush.com's and netlify.com's customer logo strips, ahrefs.com's first card art. Deferring those costs nothing anyone can perceive.
Four are genuinely above-the-fold art and one contradicts itself. stanford.edu's first element is an 800×1067 photograph of a researcher in a greenhouse, wise.com's is a 1440-wide lifestyle photograph, trello.com's is a 1092×733 product illustration, and target.com's is a full-width hero with an empty alt — all four are the kind of image that is usually the Largest Contentful Paint element, and all four are deferred. squareup.com writes fetchpriority="high" and loading="lazy" on the same tag, which asks the browser to prioritise a fetch it has also been told to postpone.
Only 3 homepages mark their first image eager (bloomberg.com, figma.com, digitalocean.com) and 7 put fetchpriority="high" on it (docker.com, searchenginejournal.com, coursera.org, squareup.com, cloudflare.com, vercel.com, digitalocean.com). fetchpriority="high" appears 51 times across 9 sites in total — the attribute exists and is being used, just not on the one image where it pays.
110 images across 3 sites have no src at all, only data-src or data-lazy: slack.com's mega-menu thumbnails, zoom.us's award banners and who.int's regional maps. A crawler that does not execute JavaScript never sees those files, which is a separate problem from lazy loading and a much older one.
Finding 6: fewer than half the images reserve their own space
984 images (40.7%) declare both width and height; the per-site median is 36.6%. 14 of 55 homepages size every image — forbes.com, notion.so, trello.com, docker.com, developer.mozilla.org, wikipedia.org, mozilla.org, semrush.com, searchenginejournal.com, vercel.com, netlify.com and digitalocean.com among them — and 22 homepages size none of them. The attribute pair is the cheapest available defence against layout shift, and it is used on a minority of images by a minority of sites.
Responsive delivery sits lower still. 528 images (21.8%) use srcset, but it is concentrated: 27 sites use it and the per-site median share is 0%, meaning half the sites that do use it apply it to almost nothing. sizes appears on 207 images, and 321 images have a srcset with no sizes — without it the browser assumes the image fills the viewport and picks the wrong candidate. decoding="async" appears on 411 images across 13 sites.
Finding 7: SVG is the most common image format on a homepage
By URL suffix, the 2,418 images break down as SVG 871 (36.0%), PNG 597 (24.7%), JPEG 434 (17.9%), WebP 204 (8.4%), inline data: 108 (4.5%), GIF 4 and AVIF 1. SVG leads because a homepage is mostly icons, and 37 of the 55 sites use it. AVIF appears once in the entire sample, which is a fair summary of where adoption actually is.
725 <picture> elements across 22 sites carry 1,775 <source> children (we count only sources inside a picture; the 193 sources belonging to <video> and <audio> are excluded). The heaviest users are news and marketing sites swapping art direction per breakpoint: theguardian.com 113, ahrefs.com 106, searchenginejournal.com 99, squareup.com 85, cnn.com 71, bloomberg.com 56.
Finding 8: the bigger picture is inline SVG, and it has no alt at all
Everything above counts <img>. Counting <svg> as well changes the scale: 2,753 inline SVG elements across 52 of the 62 homepages, a median of 22 per site. vimeo.com has 274, atlassian.com 167, squareup.com 163, stripe.com 151, forbes.com 127, cloudflare.com 125, github.com 115 and searchenginejournal.com 115.
An inline SVG cannot have an alt; it is named by a <title> child or an aria-label, or hidden. 126 SVGs here have a <title>, 137 have an aria-label, and 1,002 are aria-hidden="true". The dominant pattern is an icon font replacement that nobody is meant to announce, and it works — but it means an alt-text audit that only looks at <img> is measuring the smaller of two populations.
Which is what nodejs.org is. It returned 531 KB of HTML with zero <img> tags and 27 inline SVGs — sponsor logos, social icons, the lot. A crawler counting images reports "no images"; the page is full of them, and none of them can carry alt text by construction.
What to ship
Write alt="" on every decorative image, and stop there. 39.6% of images here do it and it is right. Adding aria-hidden="true" is optional belt-and-braces — 89.7% of sites skip it and nothing breaks.
Never let a CMS filename become alt text. 39 images in this sample are their own filename and 31 of them are on one newsroom. A build check that rejects an alt matching /.(jpe?g|png|webp|svg)$/i catches all of them.
Check the first image before you ship, not the average. 13 of 55 homepages defer the first image in the document; 4 of them are deferring above-the-fold art. The rule is one line: the hero gets loading="eager" or fetchpriority="high", everything below the fold gets lazy, and never both on one tag.
Put width and height on every image. 40.7% is not a passing rate for the cheapest Core Web Vitals fix there is, and 22 of 55 sites do it zero times.
Pair srcset with sizes, or skip srcset. 321 images here have one without the other, and the browser then assumes a viewport-wide image.
If you audit alt text, count inline SVG too. There are more of them than images on the median homepage here, and they cannot carry the attribute you are auditing for.
To assemble the tags around them without any of them drifting apart, the meta tag generator produces the title, description, canonical, robots and icon tags from one input, and the Open Graph preview shows how the image you choose renders as a social card.
Limitations
Homepages only, 55 of them, one snapshot. Everything was fetched on 2026-10-17 with a crawler identity. WAFs answer differently per client, an article page has a completely different image profile from a homepage, and a newsroom's front page changes hourly.
Server-rendered HTML only. Seven otherwise-readable homepages had no images because they are JavaScript shells, and every image added after load is invisible to this method — including the 110 that exist only as data-src. Our zero counts are floors. The 99 images inside <noscript> blocks, which Google does see, are counted in the totals.
We counted markup, not rendering. Whether the first image really is the LCP element depends on layout, viewport and CSS, none of which we can see. "First image in source order" is a proxy, and Finding 5 says so site by site rather than asserting it. Whether a deferred image cost anyone a millisecond is not something this method can answer.
The decorative/undecided split is partly a guess. We take alt="" at its word and call an image decorative. A site that writes an empty alt on a meaningful image is counted as correct here.
Localisation. Our exit IP is in Asia and some sites answered with a regional variant. 37 alt strings were dropped from the text-layer metrics on that basis; the structural counts were kept, since alt="" and loading="lazy" mean the same thing in any language.
Reproduce it
The script and the shared domain list ship with this site. node scripts/survey-images.mjs re-parses every number from the stored homepage HTML without touching the network — it is offline by design, so a parsing fix can be applied and re-run months after the fetch — and --evidence prints the original <img> tag behind every verdict. It reads the most recent snapshot in .workbuddy/tmp by default, which today is the 2026-10-17 fetch; pass --raw=<file> to pin a specific one. That is what caught the bare <img alt>, the 93 inlined blank GIFs on asana.com, and every one of cnn.com's filename alts, and it is what stopped us publishing two findings that were our own parser's fault. Our resource hint, favicon, heading and link rel surveys run the same domain list from other angles.