Acts

What an act does

• ✓Invoke, toggle, set a value or a range, select, expand, collapse.
• ✓Select and confirm; every value a picker holds, and reaching one.
• ✓Record the controls as a case found them, and put them back.
• ✓Each attempt is capped and counted, so “attempt 3 of 3” is in the record rather than in somebody's memory.

Checked before, not discovered after

Actionability answers whether an element can take an act at all, and where it cannot, why not. The preflight takes every declared act in a case and checks what it needs against the tree before anything is pressed — which turns a red run halfway through into a refusal at the start.

The verbs that do need the foreground

Synthesised mouse and keyboard input exist for the controls with no peer worth asking, and every one of them is marked as needing the foreground in the catalogue. The catalogue is checked against the engine in both directions: a verb added without an entry is a red.

Menus, traversal and the notification area

• ✓Enter a menu bar the way a keyboard user does, walk to an entry, open a submenu, dismiss.
• ✓The walk reports its hop count, which is what makes a timing observation mean anything.
• ✓The tray, the overflow flyout, the icons on either, and an icon's context menu.
• ✓Finding an icon says which of the two happened — the icon is absent, or the flyout would not open — because a caller reading a null cannot tell them apart.

The one act that has to be meant

A declared destructive entry reached without saying you meant it is refused. And a bare name is refused as a declaration where the project ships more than one language: a name is the field a translation rewrites, so a safety check compared against text a person sees expires the moment somebody translates the application.