Text under an opaque cover

How the text is hidden

The parser does not build a layout, so it judges only the one shape of cover that needs no knowledge of where the covered text sits: an element that spans its whole containing block. Three conditions must all hold — positioned out of flow (absolute or fixed); covering the whole block (inset:0, all four offsets at zero, or top and left at zero with width and height at 100%); and genuinely opaque, meaning a solid background colour at full alpha with no fractional opacity and no background image. The declaration is re-parsed with an alpha-aware reader for that last test, so a dialog scrim at half alpha and a gradient hero overlay do not qualify — they tint the text, they do not hide it.

Why a model still reads it

Nothing is done to the text at all. It is in the flow, in the DOM, at full contrast; only paint order puts something in front of it, and paint order is not a property an extractor sees.

What we do about it

A qualifying overlay is registered against the nearest positioned ancestor on the open-element stack and finalised when that ancestor closes, because both spans are only known then. After the walk, any run inside that ancestor's span that is not itself a child of the overlay — those are painted with it, on top — and that is not already concealed for a more specific reason has its reason set to occluded. The rule fires at high with action flag; text is reported and retained, and containerVisibility is never, because no view, toggle or affordance lifts the overlay.

How often it fires

0% of a broad crawl of 399 real web pages — pages, not documents, measured 2026-08-21.

This is an alert-volume number and nothing else. It says how often the alarm sounds on documents as found — not how often it is right, and not whether what it found was harmless. Documents as found may themselves carry concealment. Read it against the population named above rather than as a property of documents in general.