添加 tabindex='-1' 属性；

默认：获取不到焦点事件（blur）

可以获取焦点事件（blur）

具体详解：

先看：W3C关于onfocus的部分

The onfocus event occurs when an element receives focus either by the pointing device or by tabbing navigation. 
This attribute may be used with the following elements: A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

再看：Tabbing navigation的部分

Those
elements that do not support the tabindex attribute or support it and
assign it a value of "0" are navigated next. These elements are
navigated in the order they appear in the character stream.

以下来自互联网：

【focus和tabIndex】

在KeyBind程序中，除了绑定对象的keydown事件，还不够的，可以在ff测试下面的代码：

无论怎样都触发不了onkeydown事件（ie可以触发），那就奇怪了，按照一般的思路应该是可以的啊。
这个可以从w3c关于KeyboardEvent的部分中找到原因：
Keyboard events are commonly directed at the element that has the focus.
大概就是说键盘按键事件一般指向能获取焦点的元素，就是不能获取焦点的元素就不能触发键盘按键事件了。

难道div就不能获取焦点？用下面的代码测试(ff)：

还真的不行，那问题就在于怎么使div能获取焦点了（当然这个是转了不少弯才想出来的）。

最后发现给元素设置tabIndex就能让元素能获取焦点了，如果不需要详细了解的话下面可以略过。
首先看看w3c关于onfocus的部分：
The onfocus event occurs when an element receives focus either by the pointing device or by tabbing navigation. 
This attribute may be used with the following elements: A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON. 
当元素通过指定（点击）或tab导航（Tabbing navigation）获得焦点，onfocus事件就会触发。
该属性会使用在以下元素（就是说默认可以获取焦点的元素）：A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.
测试下面的代码：

果然两个事件都可以执行。

接着看Tabbing navigation的部分：
Those
elements that do not support the tabindex attribute or support it and
assign it a value of "0" are navigated next. These elements are
navigated in the order they appear in the character stream. 
这里看得不太明白，关键的意思是给元素设置tabindex为0就可以被导航到了（能获取焦点了）。
测试下面的代码（ff）：

果然两个事件都能触发了。

不过w3c说得很模糊，msdn上倒是很清楚：
An element can have focus if the tabIndex property is set to any valid negative or positive integer.
Elements
that receive focus can fire the onblur and onfocus events as of
Internet Explorer 4.0, and the onkeydown, onkeypress, and onkeyup events
as of Internet Explorer 5.
只要元素的tabIndex属性设置成任何有效的整数那么该元素就能取得焦点。元素在取得焦点后就能触发onblur，onfocus，onkeydown, onkeypress和onkeyup事件。

不同tabIndex值在tab order（Tabbing navigation）中的情况：
Objects with a positive tabIndex are selected in increasing iIndex order and in source order to resolve duplicates.
Objects with an tabIndex of zero are selected in source order. 
Objects with a negative tabIndex are omitted from the tabbing order.
tabIndex值是正数的对象根据递增的值顺序和代码中的位置顺序来被选择
tabIndex值是0的对象根据在代码中的位置顺序被选择
tabIndex值是负数的对象会被忽略

这个不知道是否符合标准，但貌似ff跟ie是一样的（不同的地方后面会说）。
那么设置一个负的tabIndex值应该是最理想的了。

ps：如果对ff的tabindex有兴趣的话，推荐看看Test cases for tabindex bugs in Firefox，里面有更详细更专业的分析。

那ie通过一开始的测试，是不是就说明不需要了呢？我们换一个元素测试：

换成ul就又不能触发事件了，怎么搞的。

再看看msdn，里面有一段：
The following elements can have focus by default but are not tab stops. .略. applet, div, frameSet, span, table, td.
下面的元素默认能获取焦点但不能tab导航：applet, div, frameSet, span, table, td.
看来ie真是“为程序员着想”，但其他元素总不能漏了啊，还是全部都设置tabIndex好了。

终于回到程序上来，首先设置tabIndex：

ff元素获得焦点后会出现一个虚线框，去掉会美观一点：

ps：如果tabIndex设为0或以上的话ie也会出现虚线框。

绑定了keydown之后，点击一下容器（获取焦点）后就能用方向键控制方向了，但如果（没有获得焦点时）点击滑块，还是触发不了事件。
因为滑块在拖动效果中ie的鼠标捕获和ff的取消默认动作导致容器不能获得焦点，那手动设置可以吗？
是可以的，ff中就是直接在滑块的mousedown事件中执行容器的focus方法获得焦点。
ie本来也是可以的，但ie中当对象执行focus方法时，如果该对象有部分在滚动条外就会自动滚动到适当的位置（还好点击不会这样）。
为了降低影响，程序中把滑块也绑定了键盘控制，这样点击滑块时只要执行滑块的focus方法获得焦点就可以了：