Triggering of Events by Keyboard Focus Location

You should avoid having events triggered by movements of the keyboard focus. However, if you must include triggering, you should make it optional.

To enable the user to "read" or explore a window's contents, you should support keyboard mechanisms that allow the focus to change to a control or area without causing problems. For example, it is typical for a user who is blind to use the TAB key to move through all the controls in a dialog box as a means of exploring it before he or she goes back and does any actual work.

There are exceptions to this rule, primarily in cases where application behavior has been standardized and mechanisms exist for accessibility aids to work appropriately:

It is acceptable to display explanatory text that gives details about the function of a menu while menu messages are being processed. It is preferable to draw this text in a status bar to be consistent with other applications, but any text drawn during menu processing will be assumed to serve this function.
It is acceptable to automatically change the value of option controls (radio buttons) and tab controls during keyboard navigation. Although this behavior can cause problems for keyboard users, it is necessary for backwards compatibility.
An application that takes some action when the focus moves should provide an alternative way to move the focus. This is typically done by using the CTRL key to modify the navigation key. For example, in Windows Explorer or in a list box that supports discontiguous selection, the user can move the focus and change the selection when navigating with an arrow key. However, the user can move the focus without changing the selection by holding down the CTRL key when he or she presses the arrow key.