HTML5-焦点管理

2,376

在开发TV web 应用时,发现在交互方式上和传统web开发很不一样。PC上的页面上都是通过鼠标进行交互,而TV则不同,它是通过遥控器按键进行交互,它有点击、移动(上下左右)、返回、主页等操作。
移动的实质则是切换焦点,所以我们需要去理解什么焦点。

focusable元素: 能够被聚焦的元素,比如 button 、 input

接下来我们需要了解一下 tabindex 属性,这个很重要,没有它实现不了焦点管理。

Tab Index

根据 HTML5 规范,属性 tabindex 定义了元素是否可以聚焦。
也就是说如果一个元素声明了 tabindex="0"  ,那么这个元素就允许聚焦了。

<div tabindex="0"></div>

tabindex 的值有一些规则,我们接下来看一看。
它的值必须是一个整数(Integer),包括正整数、负整数、0。

负整数

如果该属性值为负整数,浏览器必须允许该元素可被聚焦,但,不能允许它被连续聚焦导航触及。

连续聚焦导航: 通过键盘进行连续导航,比如 tab 键

举个具体例子,在chrome下,给一个 div 设置 tabindex="-1"

<div id="test" tabindex="-1" ></div>

如果使用 tab 键进行焦点切换,这个div是选不中的,如果使用 focus 事件,是可以选中的。

document.getElementById("test").focus()

0

如果该属性值为 0,浏览器必须允许该元素可聚焦,允许该元素可被连续聚焦导航触及,遵循平台(platform)约定去判定该元素的相对顺序。

也就是说不论通过键盘(tab键),还是 focus 事件,都可以选中元素。

正整数

如果该属性值为正整数,浏览器必须允许该元素可聚焦,允许该元素可被连续聚焦导航触及,应该安排该元素在连续聚焦导航中的顺序

在0和正整数中出现了导航顺序这个概念,那这又是什么呢?

导航顺序

导航顺序,使用tab键进行焦点切换的顺序。
根据HTML5文档来看,假设有一个元素设置了tabindex,且属性值为正整数,那元素排序具体有以下几个规则:

  • 在任何tabindex属性被忽略或对其值解析后返回一个错误的可聚焦元素之前
  • 在任何tabindex属性值小于等于零的可聚焦元素之前
  • 在任何tabindex属性值大于零,小于该元素的tabindex值的元素之后,
  • 在任何tabindex属性值等于该元素的tabindex值且在文档的树顺序(#tree order)中比该元素靠前的元素之后,
  • 在任何tabindex属性值等于该元素的tabindex值且在文档的树顺序(#tree order)中比该元素靠后的元素之前,
  • 在任何tabindex属性值大于该元素的tabindex值的元素之前。

我根据规范在chrome中进行了测试,顺序在chrome中简单来说就是:

  • 导航顺序以从小到大的顺序,正序排列, 0 特殊,始终在最后面。(e.g. [1, 2, 3, 4, 5, 6, ..., 0] )
  • 负整数不在导航顺序之中
  • 如果属性值一样,那就依据在文档流中的顺序进行排列(0和正整数都适用)

默认的聚焦元素

HTML5规定,有一些元素默认是聚焦元素

  • 具有href属性的a元素
  • 具有href属性的link元素
  • 没有被禁用(#disabled)的button元素
  • type属性不为隐藏(#Hidden)状态且没有被禁用的input元素
  • 没有被禁用的select元素
  • 没有被禁用的textarea元素
  • 没有disabled属性的command元素
  • 设有draggable属性的元素,如果有可能user agent允许用户使用非指针设备进行拖拽操作的
  • 编辑宿主(#Editing hosts)
  • 浏览上下文容器(#Browsing context containers)

另外,每一个由area元素生成的形状都应该为可聚焦元素。除非平台约定有不同的描述。

我在chrome下测试了几个元素,发现实现和规范还是有一些出入。比如:具有href属性的link元素,不能被聚焦。

焦点使用场景

  • TV,遥控器操作
  • 无障碍访问网站
  • 表单输入框自动切换
  • ……

其它

  • 对焦点元素的样式控制,使用的是 :focus 选择器。
  • 在chrome控制台中,使用 focus 事件无效,因为不是用户真实的行为,会被浏览器拦截

通过合理的利用默认焦点元素和 tabindex ,就可以实现对web页面的焦点控制。

参考资料