Why can acting on an off-screen element that the element tree reports as present still fail?

## Present, visible and reachable are three different states An automated case usually asks the screen one question — *is this element there?* — and treats a yes as permission to act. Three separate properties actually have to hold before an interaction lands: - **Presence**: the element exists in the screen's reported element tree, with bounds and attributes. - **Visibility**: those bounds fall inside the area currently drawn, with a non-zero size and no attribute hiding it. - **Reachability**: the point the case is about to contact really belongs to that element — the coordinate is inside the visible area and nothing is drawn over it. Presence is the cheapest to check and the only one many cases check. Reachability is what the interaction depends on, because a contact is not addressed to an element at all. It is addressed to a **coordinate**, and the system delivers it to whatever is drawn there and accepting input. ## How the failure actually shows up | State of the element | What the element tree reports | What a contact at its coordinate does | |---|---|---| | Scrolled outside the visible area | present, bounds outside the viewport | lands on whatever is drawn there, or is discarded | | Inside the visible area but covered | present, bounds overlapping the viewport | is delivered to the element drawn on top | | Rendered with zero width or height | present | nothing accepts it | | Inside the visible area, unobstructed | present, bounds inside the viewport | reaches the intended element | Several signatures recur, and recognising them saves hours: - The case passes on a tall screen and fails on a short one, because the target sat below the fold only on the short one. - The case passes with the on-screen keyboard closed and fails once an earlier step opened it, because the keyboard now owns the lower part of the screen. - The wrong item is actioned: after a partial scroll the coordinate landed on a neighbouring row. - The harness reports something as not interactable and names an element the case never mentioned — the one actually drawn at that point. **None of these is a readiness problem, and none of them is fixed by waiting longer.** The element is already present; it is simply not somewhere a contact can reach. Time does not move it. Recognising that is the difference between a real fix and a longer timeout that hides the cause. ## Why leaving it to the harness is not a plan Many harnesses scroll automatically before acting, which is exactly why this failure is intermittent rather than constant. That automatic behaviour is a policy you did not choose and cannot see in the case: - it may scroll the outermost scrollable container when the element lives in an inner one; - it may stop as soon as the bounds intersect the visible area, leaving the element half under a fixed bar; - it may do nothing at all for a container it does not recognise as scrollable; - and it may change when the tooling is upgraded, turning a stable suite red for no product reason. Writing the step yourself costs three lines. Not writing it costs a class of failure whose cause is invisible in the source. ## Making reach an explicit step 1. **Scroll the container that owns the element**, not the whole screen. Nested scrollers are the usual reason an automatic scroll moves the wrong thing. 2. **Scroll toward a target, not by an amount.** Repeat a bounded scroll until the bounds fall inside the visible area, with a maximum count and a failure message saying the element never arrived. 3. **Check geometry immediately before acting**: bounds inside the visible area, non-zero size, and the contact point not covered by a fixed overlay. 4. **Undo what the case put in the way.** If an earlier step opened the on-screen keyboard, dismiss it before acting on anything beneath it. 5. **Capture the screenshot at the moment of the failed action**, not at the end of the case. By then the obstruction has usually gone and the artefact proves nothing. ## When unreachable is the finding The last point separates a mechanical fix from judgment. Scrolling to a control makes the case pass; it does not make the control reachable for a person. If a form's submit control cannot be brought into view by ordinary scrolling on a small screen — because the container does not scroll, or the keyboard covers it and the layout does not inset for it — then **the product has a defect and the suite has just hidden it.** Keep the functional case, and add a check that states reachability as an expectation: after the flow's ordinary interactions, the control is inside the visible area and unobstructed. That check fails for a product reason, which is precisely what you want it to do. The distinction is worth making explicit in review, because both halves are true at once: scrolling is a legitimate part of using a screen and automating it is right, while silently arranging conditions a person cannot arrange is not.