Collapsed content should not fake participation in in-page find

What it is

Browser or in-app find matches strings in the document. A collapsed block often leaves its content in the tree and simply does not paint it, so find reports a hit while the viewport stops on a still-closed heading and the user never sees the match. That is the find-in-page versus collapsed content illusion: the system says the content is present, the page model says it is not. This is not about whether the block should start open. It is about whether find, as a channel, can be lied to by collapse.

Why it happens

Find assumes a matched node is visually reachable: scroll to it, highlight it, read it. Collapse removes the node from layout without always removing it from the tree. After a match, the scroller parks a closed heading mid-viewport, the highlight sits on an invisible subtree, and the counter has already ticked. Pressing “next” skips a hit the user never saw, so they conclude the word is absent, or that find is broken. The reverse illusion: implementations that tear collapsed content out of the DOM report “no results,” and after expand the word is obviously there. Both make the find count disagree with visible hits. Consistency is only two ways: expand on match and scroll to a visible highlight, or exclude collapsed content from the find domain and say so — “closed blocks are not searched.”

Studying it

On a long page with collapsed blocks, bury a unique word that exists only inside a collapse. Test three implementations: content remains in the DOM and does not auto-expand; match expands; content is not in the DOM. Ask people to locate the word with system find. Dependent variables: whether they report a hit, whether they see a highlight, whether find triggered an expand. Independent variables: collapse implementation (hide versus unmount), whether find may expand. If “found” counts exceed “seen” counts, the illusion holds.

Where it stops holding

An in-app find that only scans visible text is consistent with collapse and is not an illusion, but a no-result state should hint “it may be in a closed section.” Print preview and PDF have no collapse; find follows visible pages. If a screen-reader find can enter collapsed nodes, those nodes should be marked expanded at the same time, or spoken hits and visual hits diverge again. Virtualised lists that unmount undrawn rows create a similar “find misses,” with lists as the object rather than disclosure blocks.

Applying it

• When in-page find hits text inside a collapsed block, expand the block, scroll the highlight into view, and count it as a visible hit.
• If expand is not technically possible, skip those nodes and report “N more in closed sections” rather than pretending a find.
• Do not unmount collapsed content as a shortcut unless find and reading order unmount with it, and remount includes it again.
• How to check: search a word that exists only inside a collapsed block. The outcome must be a visible highlight or an explicit “in a closed block.” A rising counter with no highlight in the viewport is the illusion.

Related

• Within the group: E4.07.1 Collapsing hides content and also hides that the content exists · E4.07.2 Default expanded or collapsed should follow how often the content is needed
• Adjacent: E4.18 Virtualized long lists · E2.10 Search fields
• Search terms: find in page · hidden text · disclosure and search