Description AtkAction should be implemented by instances of AtkObject classes with which the user can interact directly, i.e. buttons, checkboxes, scrollbars, e.g. components which are not "passive" providers of UI information. Exceptions: when the user interaction is already covered by another appropriate interface such as AtkEditableText (insert/delete test, etc.) or AtkValue (set value) then these actions should not be exposed by AtkAction as well. Also note that the AtkAction API is limited in that parameters may not be passed to the object being activated; thus the action must be self-contained and specifiable via only a single "verb". Concrete examples include "press", "release", "click" for buttons, "drag" (meaning initiate drag) and "drop" for drag sources and drop targets, etc. Though most UI interactions on components should be invocable via keyboard as well as mouse, there will generally be a close mapping between "mouse actions" that are possible on a component and the AtkActions. Where mouse and keyboard actions are redundant in effect, AtkAction should expose only one action rather than exposing redundant actions if possible. By convention we have been using "mouse centric" terminology for AtkAction names.