An input node in HTML is not necessarily a field a person can use now. Hidden native controls, visible substitutes and inactive regions coexist. Northstar should not treat every existing node as an action candidate, and exceptions should stay tied to an actual visible control surface.
Inspect hidden ancestors as well as the node
Exclusion walks from an element through its parents and shadow hosts, checking hidden, inert, accessibility-hidden and relevant styles. Zero opacity and hidden visibility are excluded too. A button with visible local styling is not an ordinary candidate when its containing region is hidden.
Visibility also requires positive dimensions, but that does not mean inside the current viewport. An offscreen element still in layout can carry a separate viewport state. Conflating hidden and scrollable targets either loses useful controls or encourages actions on unavailable ones.
Disabled and hidden describe different conditions
A disabled button can have a readable name without being actionable. Read-only, required and sensitive fields also retain distinct state. Keeping explanatory metadata can be more useful than simply erasing every unavailable control.
Reading state does not imply exposing field values. General body extraction treats inputs, textareas and editable regions separately. Value verification and site-specific editor reading require their own contracts. Existence, description, value access and permission to change are separate stages.
A visible label for a hidden radio is a narrow exception
Services sometimes hide a radio or checkbox and offer its label as the clickable surface. The label adapter requires an associated radio or checkbox whose own input surface is not visible. It does not turn every descriptive label into a button.
Role and checked or disabled state come from the associated control, while the action surface is the visible label. The intent is to connect the same surface a person uses, rather than directly changing a hidden value. A normal visible checkbox must also avoid appearing twice because it has a label.
Keep adaptations from relaxing the global hidden policy
Special editors and toolbar descriptions can tempt a broad relaxation of exclusion. Reading every hidden descendant would add inactive panels, advertisements and sensitive fields to the candidate pool. Current adaptations remain tied to recognized editor structures or label relationships.
The diagnostic control probe is not a general value collector either. It reports bounded structural, size and ancestor-display metadata for selected accessibility-reported inputs and excludes sensitive categories. Being diagnosable does not make a node actionable. Explanation and dispatch conditions remain separate.
Test the changed selection and the refusals together
The hidden-choice test checks visible labels exposed as radios or checkboxes while ordinary descriptions and hidden labels stay absent. Clicking the scheduling label must change actual checked state and outcome text. Disabled controls and references made stale by a later state change must be rejected.
I read that Electron-fixture test and the implementation; I did not make a new choice on the user's live service. The evidence does not cover every custom control or CSS variation. A new structure needs its own bounded reproduction under the same principles.
Describe the actual control surface
Clear relationships between visible labels and stored values help people and agents in business software too. A meaningful control with explicit state is easier to check than a button painted only for appearance. If design hides a native input, the contract should still identify what is pressed and what changes.
I chose separate questions of existence, visibility and actionability rather than revealing everything hidden or deleting every exception. That distinction avoids inventing an available field while retaining genuine choices. Reading structure is less about collecting nodes than expressing their relationships accurately.