`s and ``s spreads those errors thinner, so they look diluted. WebAIM makes the same point in its own report: density is offered as a site-lookup feature, but it can't stand in for a judgment about accessibility on its own, and more `

`s and ``s can push density down and make a page look better even as new errors pile up. That's why the report treats errors per page, not density, as its real yardstick. That's the problem with using density as a report card. If simply adding more elements makes the number look better, it can't tell you what actually improved. ## The Mean's Blind Spot: HTTP Archive's Median Actually Fell Let's put another dataset next to this one. HTTP Archive's Web Almanac crawls a far larger sample of the web and publishes its own yearly statistics. Its 2024 Markup chapter found that the **median** (the middle value when every page is lined up by element count) number of elements on mobile pages actually fell, from 653 in 2022 to 594 in 2024. Counting from the lighter end, the 75th percentile was 1,010 and the 90th percentile was 1,716. WebAIM says elements went up. HTTP Archive says the typical page got lighter. That might sound contradictory, but neither one is wrong. They're just measuring different things, in different ways. | Aspect | WebAIM Million | HTTP Archive Web Almanac | |---|---|---| | Statistic | Mean | Median and percentiles | | Sample | Home pages of the top 1 million sites by Tranco rank | All sites captured in Chrome user data (CrUX), including internal pages | | Timing | Every February | Once a year (June for the 2024 edition, July for 2025) | A mean gets pulled around by a small number of heavy outliers. One home page with 5,000 elements can drag the average up while the median doesn't budge at all. {{< img src="images/contents/mean-vs-median-en.png" alt="Example scatter of 11 hypothetical home pages - when only the single heaviest page grows from 5,200 to 7,000 elements, the mean rises 13% from 1,250 to 1,414, while the median stays put at 650" >}} So "average elements up 14.3%" is safer read as "the heavy tail likely got longer," not "the typical home page got 14.3% heavier." The two surveys' samples and timing differ too much for a direct comparison, but the fact that they point in opposite directions is itself a signal not to draw conclusions from a single average. ## Top 100K vs. Bottom 100K: Change the Sample, Change the Number The WebAIM report also breaks results down by popularity. In 2026, home pages among the top 100,000 sites averaged 1,584 elements, while the bottom 100,000 (ranks 900,000 to 1,000,000 in the sample) averaged 1,318. In 2025, those figures were 1,465 and 1,014. Do the math and the top 100,000 grew 8.1% in a year, while the bottom 100,000 grew 30.0%. The gap between them also narrowed sharply, from 45% to 20%. It's tempting to jump straight to "smaller sites got dramatically heavier in a single year." But that number is harder to read at face value than it looks. WebAIM's list of one million sites is redrawn every year from a popularity ranking called Tranco, and rankings like this get noisier the further down you go. The paper behind Tranco cites Alexa, once a leading source for these rankings, as having said that rankings below the 100,000 mark carry little statistical meaning and can swing sharply from small changes in measured traffic. The sample did change a lot. According to figures shared by WebAIM's Jared Smith, only 60.1% of the sites tested in 2026 were also tested in 2025. Broken down by range, the difference is starker: **72.6% of the bottom 100,000 were different sites** from last year, while only 10.1% of the top 100,000 changed (per WebAIM's Jared Smith, in correspondence, September 2026). Jared was careful about what that means: it's hard to know what's behind the faster growth at the bottom, but sampling may be a factor. So the bottom 100,000's +30% mixes two things: the same sites getting heavier, and different sites being measured in the first place. The top 100,000, on the other hand, is nine-tenths the same sites as last year, so its +8.1% is much closer to "how much the same sites actually got heavier." The two ranges differ on errors too. The top 100,000 averaged 52.2 errors, and the bottom 100,000 averaged 56.4. Jared added that it's reasonable to presume the most popular sites pay more attention to page size and complexity, just as they do to accessibility. > "Bottom 100,000" here doesn't mean the least popular sites on the internet. It means the sites ranked 900,000 to 1,000,000 within WebAIM's sample. Jared suggested making that clear when I asked about quoting these figures. ## Lighthouse's DOM Size Threshold of 1,400 and the Average Home Page's 1,437 Looking at the same number through a performance tool adds one more layer. Lighthouse, Google's web page quality audit tool, has a DOM size audit that warns once nodes inside `` pass roughly 800 and flags an error past roughly 1,400. There are three reasons: nodes that never even appear on the initial screen still have to be downloaded, adding to data usage; the browser has to recalculate node position and style on every user interaction; and code like `querySelectorAll` holding onto thousands of nodes at once can eat up memory. (Starting with Lighthouse 13, this audit moved into the "Optimize DOM size" insight. The new insight still shows the element count, but only flags a failure when style recalculation or layout takes more than 40ms at once. The focus shifted from the sheer number of elements to whether that number is actually causing something to slow down.) WebAIM's average home page measures 1,437 elements. The two tools don't count in exactly the same way, but the picture is clear: the "average home page" among the top one million sites sits above the line that older Lighthouse would have flagged as an error. So where do all these elements come from? Web Almanac 2025's Page Weight chapter puts the median size of a home page's HTML document at just 22KB. JavaScript, meanwhile, comes in at 697KB on desktop and 632KB on mobile, and the full page weighs 2.86MB on desktop and 2.56MB on mobile. Median and mean aren't directly comparable, but it's hard to believe 1,437 elements all fit inside 22KB of HTML. WAVE inspects the rendered DOM, after scripts and styles have been applied, so it's reasonable to assume a good share of those elements are built **after JavaScript runs**. That's where markup from frameworks, third-party widgets, and ad or analytics scripts all lands. {{< img src="images/contents/rendered-dom-en.png" alt="Flow diagram connecting 22KB of server-sent HTML, 632 to 697KB of JavaScript execution, and 1,437 rendered DOM elements with arrows - WAVE and Lighthouse both measure the last stage, the rendered DOM" >}} For comparison, I measured this blog's own home page. As a static site built with Hugo, the HTML the server sends (about 50KB) contains roughly 365 opening tags, and the DOM had 392 elements once rendering finished. Nearly a one-to-one match. That's how small the gap between HTML and DOM gets on a site where scripts don't add much afterward. This is where accessibility errors and performance problems meet. The more markup a developer didn't write by hand, the fewer people there are who actually know what's inside it. ## Errors by Framework: Complexity Isn't Automatically Bad None of this means "today's frameworks are all heavy, so nothing can be done." The WebAIM report also breaks down average errors by the technology a site uses. Against the overall average of 56.1, here's a selection: | Technology | Sites | Avg. Errors | vs. Overall Average | |---|---|---|---| | Astro | 5,472 | 9.0 | −84.0% | | Squarespace | 2,669 | 33.0 | −41.2% | | Wix | 3,183 | 33.3 | −40.6% | | Next.js | 23,863 | 40.9 | −27.1% | | React | 45,673 | 43.5 | −22.5% | | WordPress | 252,302 | 52.8 | −5.8% | | Bootstrap | 240,869 | 63.3 | +12.8% | | Vue.js | 55,049 | 64.6 | +15.1% | | jQuery | 560,294 | 64.9 | +15.7% | | Shopify | 42,516 | 75.1 | +33.9% | | AngularJS | 6,054 | 76.6 | +36.4% | | jQuery UI | 53,076 | 79.9 | +42.3% | It's hard to call a page built with React or Next.js light on the DOM. And yet both come in below average on errors. Astro sits at 9, far ahead of everything else. This is correlation, of course; a team choosing Astro and a team that's been running jQuery UI for a decade probably differ in more ways than just their stack. Still, this table breaks the simple equation of "complex stack means more errors." Tools that bake good defaults into the system, such as components that emit semantic elements by default or linting that enforces accessible names, can let a page grow without its error count growing along with it. WebAIM's own conclusion points the same way: scaling accessibility improvements takes better practices and simpler systems, and a complex system needs to lean even harder on accessibility fundamentals. ## How Many Elements Does Your Page Have? How many elements is the page you're responsible for carrying? You can count it straight from your browser's developer console. ```javascript // Total elements in the rendered DOM (including ) document.getElementsByTagName('*').length // Closer to what Lighthouse measures: inside only document.body.getElementsByTagName('*').length // Elements with at least one ARIA attribute document.querySelectorAll('[role], [aria-hidden], [aria-label], [aria-labelledby], [aria-describedby]').length // Common candidates for misuse: aria-hidden="true" and tabindex document.querySelectorAll('[aria-hidden="true"]').length document.querySelectorAll('[tabindex="0"], [tabindex="-1"]').length ``` Compare the first line's result against 1,437. Run it once right after a page reload, then again five seconds later, and you'll see how many elements scripts add in after the fact. For reference, WebAIM's average home page carried 23.3 instances of `aria-hidden="true"` and 30.4 elements with a `tabindex` of 0 or -1. If you want to measure with Lighthouse, open the Lighthouse tab in Chrome DevTools, run it with only Performance checked, and look for the DOM size item under diagnostics. It reports the total node count, the element with the most children, and the deepest element. ## One-Page Summary - WebAIM Million 2026's "elements up 22.5% in a year" was actually a two-year growth rate, corrected to +14.3% after I reached out. There's no correction notice on the original, so posts citing 22.5% will keep circulating. - Over seven years, home page elements grew from 782 to 1,437, an 84% increase, while errors held steady around 56. The drop in error density to roughly half its former level reflects errors getting diluted among more elements, not fewer errors. - Means get pulled by heavy outliers. HTTP Archive's median actually fell, so this shouldn't be read as "the typical page got heavier." - The bottom 100,000 (ranks 900,000 to 1,000,000 in the sample) turned over 72.6% in a year, so its +30% can't be read as a growth rate at face value. The top 100,000, nine-tenths unchanged, gives the closer figure: +8.1%. - The average home page's 1,437 elements sits above the DOM size error threshold (roughly 1,400) that older versions of Lighthouse used. Accessibility and performance degrade together, in the same markup. ## Wrapping Up What I took away from this wasn't really about complexity statistics. It was about habits. When copying a number from a report, check it, even just one line's worth. Especially for a value built from two numbers, like a growth rate, find the original two numbers and divide them yourself. This time it was one division. And when something looks wrong, ask the people who made it. WebAIM answered in three days and fixed it right away. A team that scans a million pages every year responding that quickly to a single contact form message is, itself, a reason to keep trusting and citing this report. The number's been fixed, but the web keeps getting heavier every year. Go count the elements on your own page today. Once you know where that number comes from, you're halfway to knowing where your accessibility errors come from too. --- ## References - The WebAIM Million 2026 (WebAIM). Reports from 2019 through 2025 are available at the same address with the year appended - Web Almanac 2024: Markup (HTTP Archive) - Web Almanac 2025: Page Weight (HTTP Archive) - Avoid an excessive DOM size (Lighthouse, Chrome for Developers) - Optimize DOM size insight (Chrome for Developers) - Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation (Le Pochat et al., NDSS 2019) - How large DOM sizes affect interactivity (web.dev)