哪些元素默认可以获得焦点
在html中表单元素、button、带href的a可以默认获得光标焦点,对表单元素设置autofocus=“autofocus”在页面加载完毕后可以自动获得光标焦点,除非有其它的方法修改了界面的焦点.比如通过focus()
方法修改页面的焦点.其他可以获得焦点的元素
可以通过键盘上的tab来切换
元素如何获得/修改焦点
非表单元素的div span等:必须要添加属性tabIndex=1这个属性后调用HTMLElement.focus()方法即可
表单元素:直接调用HTMLElement.focus()
⚠️ tabIndex取值最好小于1,避免打乱键盘Tab键真正的切换顺序
判断元素或者子元素是否获得焦点
方法一:
document.hasFocus()
方法返回一个Boolean
值 用来获得当前document
或者document
里面的元素是否获得焦点.
方法二:
document.activeElement
document的一个只读属性,返回当前界面获得焦点的元素.
通常将返回input
或者textarea
等表单元素,(如果通过tab控制焦点移动,都会返回当前获得焦点的元素,或许是一个a
标签或者是一个div
);
该属性还属于HTML5开发中的标准
tabIndex
tabindex
表示的意思就是“元素使用Tab键进行focus时候的顺序值”
当使用键盘时,tabindex是个关键因素,它用来定位html元素。
tabindex有三个值:0 ,-1, 以及X(X里32767是界点,稍后说明)
原本在Html中,只有链接a和表单元素可以被键盘访问(即使是a也必须加上href属性才可以),但是aria允许tabindex指定给任何html元素。
当tabindex=0时,该元素可以用tab键获取焦点,且访问的顺序是按照元素在文档中的顺序来focus,即使采用了浮动改变了页面中显示的顺序,依然是按照html文档中的顺序来定位。
当tabindex=-1时,该元素用tab键获取不到焦点,但是可以通过js获取,这样就便于我们通过js设置上下左右键的响应事件来focus,在widget内部可以用到。
当tabindex>=1时,该元素可以用tab键获取焦点,而且优先级大于tabindex=0;不过在tabindex>=1时,数字越小,越先定位到。
在IE中,tabindex范围在1到32767之间(包括32767)
在FF, Chrome无限制,不过一旦超出32768,顺序跟tabindex=0时一样。
这个估计跟各个浏览器对int型的解析有关。
认识tabindex=”0″
我先抛一个问题问问大家,如下两个<div>
,请问,当使用Tab键进行索引的时候,哪个先被focus
?哪个后被focus
?
<div tabindex="0">tabindex="0"</div>
<div tabindex="1">tabindex="1"</div>
//zxx: 假设三分钟过去了…
一定有很多很多小伙伴会认为第一个<div>
首先被focus
,然后才是第二个<div>
,因为0
比1
小,索引的顺序也自然更加的靠前。
但实际上,所有浏览器都是第二个<div>
先被focus
,然后才是第一个<div>
!
不要摆出上面的表情,事实就是如此。
tabindex
属性的键盘索引顺序其实是从数值1
开始的,不是0
,1
索引顺序是最靠前的。也就是说哪怕你在页面的最底部、文档流的最后一个元素设置了tabindex="1"
,当按下Tab键的时候,首先focus
就是这最后一个元素。
那tabindex="0"
又是怎么回事呢?
前文说过,元素设置tabindex="-1"
,可以鼠标和JS可以focus
,但键盘不能focus
;tabindex="0"
和tabindex="-1"
的唯一区别就是键盘也能focus
,索引的顺序没有任何的变化。或者你可以这么理解,<div>
设置了
tabindex="0"
,从键盘访问的角度来讲,相对于<div>
元素变成了<button>
元素。
因此,实际上,我们是可以使用<div>
或者<span>
元素模拟按钮的,但是千万不能忘记设置tabindex
属性,如下示意:
<div class="button" tabindex="0" role="button">按钮</div>
遇到tabindex
属性值一样的情况,这时候的索引属性是怎样的呢?
此时顺序是根据DOM元素在文档中的位置决定的,越靠前越外层的元素索引顺序更高。
应用场景
场景一:hover
<div>
显示下拉键盘支持
这是网页中非常常见的一种交互,当我们内容比较静态的时候,常常直接使用CSS :hover
伪类实现内容的显隐效果,通常,我们都会使用一个大大的<div>
元素包在外面,从功能上讲,似乎满足了我们的需求,但实际上,对键盘以及其
它辅助设备的访问却不友好,因为默认隐藏的下拉内容只能通过鼠标操作显示,键盘永远显示不出来,自然屏幕阅读器等辅助设备也不能读取,此时,就轮到tabindex
属性来提高我们站点的可访问性了。就是给<div>
加一
个tabindex="0"
,对吧,小手一抖,体验就有,皆大欢喜,何乐不为!然后再加个:focus
伪类显示下拉内容就好了!都是举手之劳的事情。
场景二:对网站模块进行自定义的键盘支持
写文章这么多年,第一次拿新浪微博做正面的例子。虽然说新浪微博PC端最重要的微博页,加载慢性能差,但是,数年前却专门增加了自定义的键盘访问支持,比方说按下键盘上的J键,则会自动索引每条微博信息,并使用JS进行focus
高亮,如下截图所示:
其原理就是设置tabindex="-1"
然后使用JS进行focus
,如下JS示意:
div.setAttribute('tabindex', '-1');
div.focus();
由于设置了tabindex="-1"
的元素鼠标点击可以focus
并outline
轮廓显示,因此,这里的tabindex="-1"
并不是默认就有,而是按下对应的快捷键后临时动态添加的。
场景三:临时改变页面索引起始位置
当我们点击按钮并显示一个弹框的时候,Tab键的索引起始位置应该是从弹框元素开始的,但是如果我们不做任何处理,索引起始位置还是弹框背后的页面,此时想要通过Tab键一个一个索引到弹框元素,估计天都已经黑了,很显然,为
了达到完美的键盘交互体验,我们就需要额外做点事情。
-
给弹框容器元素设置
tabindex="-1"
; -
弹框显示的时候容器元素
DOM.focus()
使其获取焦点; -
容器元素CSS设置
outline:none
;
简简单单三步即可大功告成。
demo页面中,点击按钮出现弹框后,你再按一下Tab键,会发现第一个被focus
的是关闭按钮,如下截图:
依次Tab,就可以focus
弹框内所有focusable
元素了。
参考