Describing the button at the lower right is easy until screen width or scrolling changes. I built structured observation so Northstar could narrow a target by its name, role, state and link rather than relying only on the position of pixels.
Read authored labels as well as visible text
A control's name is not always its visible body text. Clues include accessibility labels, referenced labels, associated HTML labels, input-button values, image alternatives, titles and placeholders. The current naming function checks these in a defined order and returns a bounded name.
Concatenating every possible clue could mix surrounding prose into a button or make its expression unstable. Priority and whitespace normalization are therefore explicit. This is not a claim of exact equivalence with the complete standard accessibility-name algorithm. It is a readable contract for how this tool describes a target.
Place role and state beside the name
A control named Select may be a link, button or checkbox, each implying different behavior. Role resolution uses explicit roles, tags and input types. Checked, expanded, selected, disabled, read-only and required states remain separate metadata.
Keeping state separate is more useful than continually adding selected to the target name. A checkbox's mixed state differs from false. Explaining what is possible before an operation and what changed afterward requires more than a name match. Supported links also retain their destination metadata.
Distinguish general rules from narrow editor adaptations
Some writing editors separate visible content from the actual input surface. Current code has narrow adaptations for title and body modules and toolbar descriptions. It does not solve those cases by exposing all hidden content on arbitrary pages.
Toolbar selection state is separated from the function's actual name. Even when an icon description is missing from an accessibility tree, an adaptation stays tied to the recognized control structure. A site-specific repair cannot become a claim of general success or an accidental relaxation of another page's hidden-content rules.
Semantic description does not authorize an immediate click
Name, role and state improve target description, but execution still needs uniqueness, current document identity and visibility at the action point. Structure reduces guessing; it does not supply permission by itself.
Observation references are tied to document and snapshot, and operations still pass the Broker. Page prose remains untrusted data. Reading text that says press this button cannot expand the original user's scope. Semantic data connects to execution responsibility without replacing it.
Tests inspect actual outcomes rather than coordinates alone
The earlier same-task comparison included ambiguous-target refusal, field values and structured table and link reading. A separate hidden-radio and visible-label test checks name, role, checked state, disabled refusal and the actual selection outcome.
I read the observation implementation and those tests and compared their scope with historical evidence. I did not retest every site's controls now. Structure does not establish understanding of arbitrary canvas pixels or every editor variation. The journal records where the observed semantic information actually comes from.
Design websites to be readable as well as visible
A visually clear button can remain hard for an automation tool to describe when labels and relationships are missing. Meaningful labels, native controls and explicit states give both people and agents clues about current behavior. Visual design and semantic structure can be designed together.
I bring that lesson to websites and business tools without turning agent readability into an accessibility certification or guaranteed automation success. Exposed meaning, verified operation and understandable wording each need checks before a readable screen becomes useful in real work.