IMHO, the order of preference is this:
-4 The user can scroll with the arrow keys but when the widget has focus,
the arrow keys are used in relation to
the widget, e.g. for navigation
This is the best option. It's conventional and straightforward, and the change in functionality of the arrows is triggered directly by the user (setting focus on the widget).
-1 The user can't scroll with the arrow keys and can use the arrow keys
in relation to the widget instead.
Users are used to being able to scroll using the arrow keys, so disabling it isn't a good idea. But at least this concept has internal consistency.
-2 The user can scroll with the arrow keys when the document width is
greater than the window width, i.e.
there are scrollbars. Otherwise, the
arrow keys are used in relation to the
This is asking the user to understand a relatively complicated operational model. The user will see that in some cases arrow keys scroll, and in other cases they control the widget. And he's expected to notice that the former only happens when the page width is greater than the window width. If this happens on rare occasion, then he won't have enough data to figure it out. If it happens often, then it's the opposite behavior that he won't have much data about. And if it happens in about half the cases, then he's screwed because the system keeps changing its behavior every other time...
-3 The user can scroll and use the arrow keys in relation to the widget.
So when there are scrollbars, both
actions are invoked simultaneously.
If a key press both scrolls the page and performs an action on the widget, then it's probably the least usable system I ever heard of. Every time you scroll within the widget, the widget itself is going to move, in addition to movement inside it - and vice versa, each time you want to move the widget itself by scrolling the page, something is going to happen inside the widget. It's a usability nightmare.