onkeypress兼容处理
<input type="text" onkeypress="getKeyMonitoring(event)" id="monitoringVlaue" placeholder="请输入">
<span class="projectStateBtn monitoring" tabindex="2" onkeypress="getKeyMonitoring(event)" >检测</span>
// 绑定单击事件
$(".monitoring").on("click", getNetworkMonitoring);
// enter键绑定事件
function getKeyMonitoring(evt){
getKey(evt,getNetworkMonitoring);
}
function getKey(evt,fun){
evt = (evt) ? evt : ((window.event) ? window.event : ""); // 兼容IE和Firefox获得keyBoardEvent对象
var key = evt.keyCode?evt.keyCode:evt.which; // 兼容IE和Firefox获得keyBoardEvent对象的键值
if(key == 13){
fun();
}
}
// 执行事件
function getNetworkMonitoring(){
var _value = $("#monitoringVlaue").val();
var pattern = new RegExp("[`~!@#$^&*()=|{}':;',\\[\\]<>《》/?~!@#¥……&*()——|{}【】‘;:”“'。,、?]");
if(pattern.test(_value)){
layer.msg("包含特殊字符或空格,请重新输入", {icon: 5});
}else if(_value.length>0){
$.ajax({
url: 'index.php?r=project/networkmonitoring',
type:'get',
dataType: 'json',
data:{
domainName: _value
},
success: function (data){
if(data.result_code == 200){
layer.msg(data.result_desc,{
icon: 1
})
}
}
});
}else{
layer.msg("不能为空!",{icon: 5});
}
}
tabindex
tabindex 全局属性规定当使用 “tab” 键进行导航时元素的顺序。
- tabindex属性的键盘索引顺序其实是从数值1开始的
- 如果tabindex缺省,则使用默认值-1
- tabindex属性值为“-1”: 鼠标可以focus,但是键盘却不能focus
- tabindex=”0”和tabindex=”-1”的唯一区别就是键盘也能focus,索引的顺序没有任何的变化
- tabindex属性值的最大值不能超过32767
引用内容均来自:HTML tabindex属性与web网页键盘无障碍访问
(在IE浏览器下,如果tabindex值正好超出最大限制,也就是tabindex=”32768”的时候,tabindex属性值无效被忽略;但是如果值继续往上超出,例如tabindex=”32768”或者tabindex=”123456”,其行为表现和tabindex=”-1”是一致的,可以被鼠标focus无法被键盘focus,真是非常怪异的表现。)
在Firefox和Chrome浏览器下,如果tabindex值正好超出最大限制,就跟完全没事似的,可以鼠标focus也能键盘focus。出现这种现象有两种可能:一是Firefox和Chrome没有32767的限制,二是有32767限制,但是浏览器按照最大值32767进行解析了。究竟是哪一种可能呢?经过我的测试,发现是第一种可能,Firefox和Chrome没有32767的限制,或者有限制,但是绝对比32767要大。
tabindex属性的键盘索引顺序其实是从数值1开始的,不是0,1索引顺序是最靠前的。也就是说哪怕你在页面的最底部、文档流的最后一个元素设置了tabindex=”1”,当按下Tab键的时候,首先focus就是这最后一个元素。
如果你是tabindex属性重度使用患者,免不了会遇到tabindex属性值一样的情况,这时候的索引属性是怎样的呢?
此时顺序是根据DOM元素在文档中的位置决定的,越靠前越外层的元素索引顺序更高。
HTML tabindex的使用场景
在通常的web开发中,你只要不犯一些HTML常识性错误,例如使用
或者 元素作为按钮,或者全局去除outline的错误,tabindex属性就算不出场,网站的键盘无障碍访问支持已经及格了。如果想更进一步,可以增加CSS :focus或JS focus事件的交互支持,具体可参考不久前我的这篇文章:“CSS :focus伪类JS focus事件提高网站键盘可访问性”。
但是仅仅额外增加事件支持,并不能让网站100%键盘支持,或者说可以100%支持,但交互和体验不一定完美,此时可能就要轮到tabindex属性出马了!
场景一:hover
显示下拉键盘支持
这是网页中非常常见的一种交互,当我们内容比较静态的时候,常常直接使用CSS :hover伪类实现内容的显隐效果,通常,我们都会使用一个大大的元素包在外面,从功能上讲,似乎满足了我们的需求,但实际上,对键盘以及其它辅助设备的访问却不友好,因为默认隐藏的下拉内容只能通过鼠标操作显示,键盘永远显示不出来,自然屏幕阅读器等辅助设备也不能读取,此时,就轮到tabindex属性来提高我们站点的可访问性了。就是给加一个tabindex=”0”,对吧,小手一抖,体验就有,皆大欢喜,何乐不为!然后再加个:focus伪类显示下拉内容就好了!都是举手之劳的事情。场景二:对网站模块进行自定义的键盘支持
写文章这么多年,第一次拿新浪微博做正面的例子。虽然说新浪微博PC端最重要的微博页,加载慢性能差,但是,数年前却专门增加了自定义的键盘访问支持,比方说按下键盘上的J键,则会自动索引每条微博信息,并使用JS进行focus高亮,如下截图所示:键盘J索引高亮截图效果
其原理就是设置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;
简简单单三步即可大功告成。