参考：
https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
对于无障碍的设计，焦点的管理很是重要。
例如Dialog组件，如果一个dialog是由一个button trigger的话。
那取消Dialog的时候，焦点的位置，应该处在哪？是从文档焦点再重来还是说从trigger位置继续？
键盘支持
- Tab键
用于将焦点移动到下一个可聚焦元素上。
当焦点位于对话框最后时，则焦点移至第一个可聚焦元素上
- shift+Tab键
用于将焦点移动到上一个可聚焦元素上。
当焦点位于对话框最开始时，则焦点移至倒数第一个可聚焦元素上。
- Escape
关闭模态框
我做了一个简单的demo支持简单的显隐与无障碍支持。Dialog
用到的角色以及aria标签
dialog 作为标志的对话框容器
aria-labelledby=”IDREF” 通过引用提供对话框标题的元素，为对话框提供可访问的名称。与标题id相同。
aria-describedby=”IDREF”
通过引用描述对话框的主要消息或目的的对话框内容，为对话框提供可访问的描述。
也是对应的内容标题id
aria-modal=”true” 字符串 转换 eg: checked === false –> String(checked) 告诉辅助技术当前对话框下方的窗口不可用于交互
例子分析
demo一共给出了四个例子。
首先是最直观的分析。
首先是最开始第一点说的，为了方便阅读，完全覆盖窗口，以及避免滚动内容。所以我们发现蒙层下是不能滚动的。
简单的来看就是当dialog出现时候，给body设置了一个overflow，这样一来避免了可滚动的情况。
.has-dialog {
overflow: hidden;
}
例子1
例子1是一个可填写表单，没有描述内容，只有dialog 标题以及表单组成。
这样以来aria-describedby 不用设置，只需要表单aria-labelledby 与dialog 标题链接即可。并且标志aria-modal=”true”。 以及管理焦点直接聚焦在此时dialog第一个可聚焦元素上。
四个例子中，我们都可以发现打开dialog的焦点，与取消dialog的焦点是一致的位置。
例子2
例子2 给出的情况是一个大量文本（超过可读范围），且聚焦可交互性元素位于较下方。
这种情况会导致两种取舍问题出现。（文本大于一屏）
一种是如果焦点管理处于第一个可聚焦位置时，则文本可能不可见。
另一种是如果文本可见，则可聚焦交互位置不可见。
对话框打开时，两个都很重要：
文本的开头是可见的，因此用户不必向后滚动即可开始阅读。
键盘焦点始终保持可见。
有两种解决方式
- 将交互式元素放在对话框顶部，例如按钮或链接。
- 使静态元素可聚焦，例如对话框标题或文本的第一块。（例子2使用）
还有强调对话框容器不应该获得焦点，有三点原因
- 可聚焦元件越大，从视觉上识别聚焦位置就越困难，尤其是对视野狭窄的用户来说。
- 对话框具有可视边框，因此在整个对话框都具有焦点时创建清晰的焦点可视指示符不是很可行。
- 屏幕阅读器读取可聚焦元素的标签和内容。该对话框包含其标签和很多内容！如果这样的对话框具有焦点，则很难理解实际的焦点。
（将一段内容变为可聚焦，设置其tabindex即可。例子2使用，但是这样声明 aria-describedby 会带来副作用，可能会导致第一段文本在模态框打开的时候会导致屏幕阅读器重复讲述。）
注意模态框的容器需要定义role=”dialog” 来标志它是一个dialog组件。
总结
- 了解无障碍设计的焦点管理，以及键盘能力支持
- 了解 aria-labelledby， aria-describedby， aira-modal， role=”dialog” 使用
- 了解无障碍的意义。