本文作者:文蔺
本文地址:http://www.wemlion.com/2016/accessible-modal/
本文由 @文蔺 创作，转载请保留此声明。
所有权利保留，请勿用于商业目的。

问题提出

需要说明的是，题目中所说的 Modal，指的是所有由前端开发者自定义的对话框，如通常用到的 Alert、Prompt、Confirm 等等，经常伴随着一个半透明的灰黑色全局 mask。

事情源自某天使用某网站的页面，出现一个自定义的 Comfirm，习惯性按下回车确认，等了很久也不见弹出层关闭。于是很绝望。继而发现，真不是这一个网站的问题。

看看一般浏览器原生的 alert、prompt、confirm 可以发现，它们基本上都提供默认操作项（eg.确认/取消），通过回车键可以直接完成。传统软件如 PhotoShop 也是如此，否则真不知那些无需鼠标的 PS 大神是怎样练出来的。然而不少自定义的插件，却并未提供这样的功能，往往不得不将手挪到鼠标或触摸板上操作，极其不便。

主要存在两个方面的问题，一是根本无法直接通过键盘操作对话框；二是虽然可以操作，但视觉提示并不明显；三是整个应用对焦点的控制不够，容易导致成本可能极高误操作。下面先简单谈谈这几个问题，然后结合实际例子说明。

键盘、鼠标切换成本

先谈第一个问题。键盘、鼠标之间的切换成本应该是很高的，尤其是当应用响应与用户心理预期不符时，造成的焦虑感或挫败感很影响用户体验。

因此在使用弹出 Modal 时，需要根据业务场景，设置一个默认选项（尤其是确认、取消、提交等操作），用户通过回车键或鼠标点击就可以轻松完成任务。不过，另外一种更好的方式是提供 Tab 和 (Shift + Tab) 两种操作，通过键盘可以自由地在弹出层不同选项之间按照顺序切换。

明确的焦点提示

接着转到第二个，视觉提示的问题。没有明确是视觉提示，会造成用户的疑惑。

有默认选项的时候，无论是通过闪动的光标、背景色的变化，还是边框、outline 等形式，都需要明确提示用户，Modal 弹出时默认操作项是什么。而当用户使用键盘操作，焦点发生变化后，当前焦点在哪一项上，必须给出明确的视觉提示，否则极容易带来困难，甚至误操作。

应用对焦点的控制

第三个问题实际是第二个问题的延续。前面提到焦点的视觉提示问题，其实还有一种可能性，可能导致严重后果，这就是用户通过 Tab 操作，将焦点移动到弹出层 mask 背后的应用中。

这时候，一方面没有给出清晰的提示，一方面没有对焦点进行很好的控制，万一焦点在一个敏感位置（如一个外部跳转链接），按下回车键，这时候页面将刷新，用户此前的数据面临荡然无存的境地。脑洞再大一点，万一 mask 背后获得焦点的是巨额交易乃至核按钮（233333），那么恭喜你，攻城狮生涯就此结束。

我们知道，当网页弹出原生 alert 时，整个页面其他部分处于不可操作状态。使用类似的自定义组件替代这些功能时，纵然我们不能阻塞页面其他所有部分，但也得采取一定的控制，防止意外发生，最简便的方法便是将 Tab 的控制权掌握在开发者手中。

当然，相比于第三点，前两点应该是必须项，第三项可以算是加分项，在一些普通应用中不实现影响也不大。

举栗子

我们来看下一些实现。

首先是 Github 的 Fork。如图所示：

Github Fork

首先 fork 操作不提供默认选项。但使用 Tab 和 (Shift + Tab) 时，焦点只会在整个弹出层中用紫色框线标出的四个部分中依次切换。回车键按下时，则会 fork 到相应账号，或者取消操作、关闭弹出层。

接着看 SweetAlert，以第一个 Confirm 为例：

SweetAlert

Confirm 弹出后，默认选项是右边的 “Yes, delete it!”，点击回车键，就会产生确认反馈。通过 Tab 操作几次发现，整个页面的焦点，只能够在图中两个按钮之间切换。同时仔细观察还能，获得焦点状态（:focus）的按钮，会有一个不太容易察觉的 box-shadow。

再来看看 Vue 组件库 Element 的 MessageBox 组件 中的 “确认消息” Demo。

先说结果，嗯，有提供默认选项，切换到不同选项时，也会有视觉提示（“取消”按钮的颜色和边框色会变，“确认”按钮背景亮度有明显变化）。然而有两点做得还不够：第一，无法通过 Tab 轻易切换到“❎”关闭按钮；第二点，也是最致命的是，根本就没有获取到 Tab 的控制权，以至于多按几次 Tab 然后回车，页面跳到主页，而弹框依然存在（如图所示）。

Element

和 Element 类似，Weui 中的 Dialog 也存在类似问题，但 Weui 主要面向移动端，倒也情有可原。

如何实现控制

一开始我想到了 tabIndex 这个属性。但这货控制起来，十分不方便，在本文场景中使用它，简直是惹火烧身。

那么我能想到最简单的实现，莫过于手动调用 focus 事件了。Simple Demo 。代码示例如下：

var $ = (sel) => document.querySelector(sel);

$('#js-show-alert').addEventListener('click', () => {
  $('#js-prompt').style.display = 'block';
  $('#js-confirm').focus();
});

$('#js-cancel').addEventListener('click', () => {
  if (confirm('Are your sure?')) {
    $('#js-prompt').style.display = 'none';
  }
});

$('#js-confirm').addEventListener('click', () => {
  $('#js-prompt').style.display = 'none';
  alert('Confirmed! The Prompt will disappear');
});

样式方面，按钮使用的是 button，整体并未 reset，所以按钮获取焦点时，是有 outline 的。这也提醒我们，可以直接通过 :focus 伪类来实现 tab 选中时的样式，这样做好懂又靠谱。

还存在另外一点问题，上面的代码中，#js-confirm 元素是默认获取焦点的。那么，假如我们不需要任何默认焦点，而又需要用户按下 Tab 时，让 #js-prompt 中的按钮依次获得焦点呢？

这里提一点不成熟的想法（23333333）。只要让容器元素 #js-prompt 获得焦点即可：$('#js-prompt').focus();。在控制台上打印下 HTMLElement.prototype.focus，就会明白我的意思了。但这么做，可能是野路子（我还没细看 HTML 中元素获得焦点相关的规范）。

但是，上面 Demo 的实现，没有考虑到 Tab 控制权的接管。要接管 Tab，就得使用事件绑定来完成。下面看下 Github 是如何实现的。

如何取得控制权

找到 Github 对应的源码，又通过开发者工具发现弹出层容器有个值为 facebox 的 id。

接下来，开始 Ctrl + F 大法。利用长久积累的火眼金睛，找到下面这样两段代码：

Github code

Github code

就是它了。

先看第二段，整理后如下，重点直接划在注释中：


// 弹出层出现
document.addEventListener("facebox:reveal", function() {
  var t = document.getElementById("facebox");
  setTimeout(function() {
    e(t)
  }, 0);

  // 为 document 绑定 keydown 事件
  // 事件回调函数 n 就是第一张截图的函数
  r(document).on("keydown", n);
});

// 弹出层关闭后
document.addEventListener("facebox:afterClose", function() {
    // 移除出现时候为 document
    // 绑定的 keydown 事件
    r(document).off("keydown", n);

    // 弹出中已经获得焦点的元素
    // 强行失去焦点
    r("#facebox :focus").blur()
});

// ....

再来看看函数 n 做了什么。


function n(e) {
  var t = void 0;

  // hotkey 是自定义的
  // 这里开始控制 tab 和 shift+tab 操作
  if ("tab" === (t = e.hotkey) || "shift+tab" === t) {
    // 阻止默认事件
    e.preventDefault();

    // 弹出层
    var n = r("#facebox"),

      // 变量 i 存储弹出层中可以获得焦点的、可见的、可用的
      // input, button, .btn, textarea 等元素集合
      // filter 用到的函数 o 用于过滤不可见的相关元素
      // o = require("github/visible")["default"]
      i = r(Array.from(n.find("input, button, .btn, textarea")).filter(o)).filter(function() {
          return !this.disabled
      }),

      // tab 方向
      s = "shift+tab" === e.hotkey ? -1 : 1,

      // i 集合中当前获得焦点的元素的 index
      a = i.index(i.filter(":focus")),

      // i 集合中下一个获得焦点的元素的位置
      u = a + s;
    
    // 如果下一个获得焦点的位置超出 i 集合范围
    // 或者当前没有任何元素获得焦点、并且使用的是向前的 tab 键
    // 则将焦点置于 i 集合中的第一个元素上
    if (u === i.length || -1 === a && "tab" === e.hotkey) {
      i.first().focus()
    }
    // 当前没有任何元素获得焦点
    // 并且使用 shift+tab 向前
    // 则将焦点置于 i 集合中最后一个元素
    else if（-1 === a）{
      i.last().focus();
    }
    // 正常行为
    // 将焦点置于下一个元素
    else {
      i.get(u).focus();
    }

  }
}

好了，本文也就结束了。

嗯，今天（2016-12-04）我想起来那个完全无法使用的例子了 🙂：

实例

本文作者：文蔺
本文地址：http://www.wemlion.com/2016/accessible-modal/
转载请注明来源