A bound property of an object (such as a widget) is a property which transmits notification of any changes to an adapter or event handler. A simple (and typical) example is the text property of a textbox control. Changes made by an end user can be monitored, and perhaps corrected by a verification routine.
There is still a fair amount of semantic ambiguity in regards to fundamental concepts in object and component orientation, so when discussing the concept of properties (bound or not) we must be clear whether the definition is a general one or a specific notion unique to a given language or methodology. In general, we speak of object properties in context of component orientation, or libraries of reusable objects, since the specification of an objects properties and object property access methods is fundamentally concerned with addressing contractual specification related to the 'uniform' and 'standard' use and interaction semantics of components.
An object's property, in contrast to its member fields, is a conceptual construct which does not necessarily have (or require) a corresponding data-type member element in the object itself (though it certainly can be internally represented and supported by one or more fields, if required). Also note that an object can expose a member field as a property.
In general, the above distinction between an object's fields (i.e. its data-type members) and an object's properties is the reason for the fact that fields are specified through data-type declarations, whereas properties are fundamentally specified through the definition of read and write access-semantics. This is an important distinction, and can be encapsulated by the maxim that object fields address internal structural concerns, and properties address use and access semantics concerns.
When we speak of access semantics, in context of properties, what is meant is simply that (unlike a field) the read-write operations on an object's property are managed and observed. Thus we can say that 'A property is a virtual data element of an object and the access to the property is managed by getter/read and setter/write methods'.
A bound property of an object is one which has been bound to a semantic context and changes in its state may potentially affect the wider scope (beyond the owning object itself) and thus beyond simply managing the access to the property, we also need to provide means of updating the wider context of the changes in the property.
For example, in GUI frameworks which employ the MVC pattern, there is an intrinsic and explicit set of objects, (the model, the view, and the controller,) that together support the abstraction of a 'visual user interface component': changes made in the model (typically through another process) must be reflected in the GUI (by the view); and changes made by user through the GUI (thus the 'View') need to be reflected in the model; and the interaction is managed by the controller (which is typically the extension point of the GUI framework). Here, the various properties of the model (typically the value of the data element backing the GUI representation) are of interest to other objects in the 'binding context' of the model's properties: the model is the 'bound property' of the GUI widget and the binding context is the widget itself, and the interested observer is the controller. By exposing a standard bound property interface, the model allows for the controller to register interest in the model's value property.