跳转优化
现阶段，单页应用（Single Page Application）的应用非常广泛，Vue 、React 等框架大行其道。但是一些常见的写法，也容易衍生一些小问题。
譬如，点击按钮、文本进行路由跳转。譬如，经常会出现这种代码：
<template> ... <button @click="gotoDetail"> Detail </button> ... <template> ... gotoDetail() { this.$router.push({ name: 'xxxxx', }); }
大致逻辑就是给按钮添加一个事件，点击之后，跳转到另外一个路由。当然，本身这个功能是没有任何问题的，但是没有考虑到用户实际使用的场景。
实际使用的时候，由于是一个页面跳转，很多时候，用户希望能够保留当前页面的内容，同时打开一个新的窗口，这个时候，他会尝试下的鼠标右键，选择在新标签页中打开页面，遗憾的是，上述的写法是不支持鼠标右键打开新页面的。
原因在于浏览器是通过读取 <a> 标签的 href 属性，来展示类似在新标签页中打开页面这种选项，对于上述的写法，浏览器是无法识别它是一个可以跳转的链接。简单的示意图如下：
所以，对于所有路由跳转按钮，建议都使用 <a> 标签，并且内置 href 属性，填写跳转的路由地址。实际渲染出来的 DOM 可能是需要类似这样：
<a href="/xx/detail">Detail</a>
易用性
易用性也是交互设计中需要考虑的一个非常重要的环节，能做的有非常多。简单的罗列一下：
- 注意界面元素的一致性，降低用户学习成本
- 延续用户日常的使用习惯，而不是重新创造
- 给下拉框增加一些预设值，降低用户填写成本
- 同类的操作合并在一起，降低用户的认知成本
- 任何操作之后都要给出反馈，让用户知道操作已经生效
先探索，后表态
这一点非常的有意思，什么叫先探索后表态呢？就是我们不要一上来就强迫用户去做一些事情，譬如登录。
想一想一些常用网站的例子：
- 类似虎牙、Bilibili 等视频网站，可以先观看体验，一定观看时间后才会要求登录（登录享受蓝光）
- 电商网站，只有到付款的时候，才需要登录
上述易用性和先探索，后表态的内容，部分来源于：Learn From What Leading Companies A/B Test，可以好好读一读。
字体优化
字体的选择与使用其实是非常有讲究的。
如果网站没有强制必须使用某些字体。最新的规范建议我们更多的去使用系统默认字体。也就是 CSS Fonts Module Level 4 -- Generic font families 中新增的 font-family: system-ui 关键字。
font-family: system-ui 能够自动选择本操作系统下的默认系统字体。
默认使用特定操作系统的系统字体可以提高性能，因为浏览器或者 webview 不必去下载任何字体文件，而是使用已有的字体文件。 font-family: system-ui 字体设置的优势之处在于它与当前操作系统使用的字体相匹配，对于文本内容而言，它可以得到最恰当的展示。
举两个例子，天猫的字体定义与 Github 的字体定义：
- 天猫：font-family: "PingFang SC",miui,system-ui,-apple-system,BlinkMacSystemFont,Helvetica Neue,Helvetica,sans-serif;
- Github：font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
简单而言，它们总体遵循了这样一个基本原则：
1、尽量使用系统默认字体
使用系统默认字体的主要原因是性能，并且系统字体的优点在于它与当前操作系统使用的相匹配，因此它的文本展示必然也是一个让人舒适展示效果。
2、兼顾中西，西文在前，中文在后
中文或者西文（英文）都要考虑到。由于大部分中文字体也是带有英文部分的，但是英文部分又不怎么好看，但是英文字体中大多不包含中文。通常会先进行英文字体的声明，选择最优的英文字体，这样不会影响到中文字体的选择，中文字体声明则紧随其次。
3、兼顾多操作系统
选择字体的时候要考虑多操作系统。例如 MAC OS 下的很多中文字体在 Windows 都没有预装，为了保证 MAC 用户的体验，在定义中文字体的时候，先定义 MAC 用户的中文字体，再定义 Windows 用户的中文字体；
4、兼顾旧操作系统，以字体族系列 serif 和 sans-serif 结尾
当使用一些非常新的字体时，要考虑向下兼容，兼顾到一些极旧的操作系统，使用字体族系列 serif 和 sans-serif 结尾总归是不错的选择。
对于上述的一些字体可能会有些懵，譬如 -apple-system, BlinkMacSystemFont，这是因为不同浏览器厂商对规范的实现有所不同，对于字体定义更多的相关细节，可以再看看这篇文章 -- Web 字体 font-family 再探秘
可访问性（A11Y）
可访问性，在我们的网站中，属于非常重要的一环，但是大部分前端（其实应该是设计、前端、产品）同学都会忽视它。
我潜伏在一个叫无障碍设计小组的群里，其中包含了很多无障碍设计师以及患有一定程度视觉、听力、行动障碍的用户，他们在群里经常会表达出一个观点，就是国内的大部分 Web 网站及 APP 基本没有考虑过残障人士的使用（或者可访问性做的非常差），非常的令人揪心。
尤其在我们一些重交互、重逻辑的网站中，我们需要考虑用户的使用习惯、使用场景，从高可访问性的角度考虑，譬如假设用户没有鼠标，仅仅使用键盘，能否顺畅的使用我们的网站？
假设用户没有鼠标，这个真不一定是针对残障人士，很多情况下，用户拿鼠标的手可能在干其他事情，比如在吃东西，又或者在 TO B 类的业务，如超市收银、仓库收货，很可能用户拿鼠标的手操作着其他设备（扫码枪）等等。
本文不会专门阐述无障碍设计的方方面面，只是从一些我觉得前端工程师需要关注的，并且仅需要花费少量代价就能做好的一些无障碍设计细节。记住，无障碍设计对所有人都更友善。
色彩对比度
颜色，也是我们天天需要打交道的属性。对于大部分视觉正常的用户，可能对页面的颜色敏感度还没那么高。但是对于一小部分色弱、色盲用户，他们对于网站的颜色会更加敏感，不好的设计会给他们访问网站带来极大的不便。
什么是色彩对比度
是否曾关心过页面内容的展示，使用的颜色是否恰当？色弱、色盲用户能否正常看清内容？良好的色彩使用，在任何时候都是有益的，而且不仅仅局限于对于色弱、色盲用户。在户外用手机、阳光很强看不清，符合无障碍标准的高清晰度、高对比度文字就更容易阅读。
这里就有一个概念 -- 颜色对比度，简单地说，描述就是两种颜色在亮度（Brightness）上的差别。运用到我们的页面上，大多数的情况就是背景色（background-color）与内容颜色（color）的对比差异。
最权威的互联网无障碍规范 —— WCAG AA规范规定，所有重要内容的色彩对比度需要达到 4.5:1 或以上（字号大于18号时达到 3:1 或以上），才算拥有较好的可读性。
借用一张图 -- 知乎 -- 助你轻松做好无障碍的15个UI设计工具推荐：
很明显，上述最后一个例子，文字已经非常的不清晰了，正常用户都已经很难看得清了。
检查色彩对比度的工具
Chrome 浏览器从很早开始，就已经支持检查元素的色彩对比度了。以我当前正在写作的页面为例子，Github Issues 编辑页面的两个按钮：
审查元素，分别可以看到两个按钮的色彩对比度：
可以看到，绿底白字按钮的色彩对比度是没有达到标准的，也被用黄色的叹号标识了出来。
除此之外，在审查元素的 Style 界面的取色器，改变颜色，也能直观的看到当前的色彩对比度：
焦点响应
类似百度、谷歌的首页，进入页面后会默认让输入框获得焦点：
并非所有的有输入框的页面，都需要进入页面后进行聚焦，但是焦点能够让用户非常明确的知道，当前自己在哪，需要做些什么。尤其是对于无法操作鼠标的用户。
页面上可以聚焦的元素，称为可聚焦元素，获得焦点的元素，则会触发该元素的 focus 事件，对应的，也就会触发该元素的 :focus 伪类。
浏览器通常会使用元素的 :focus 伪类，给元素添加一层边框，告诉用户，当前的获焦元素在哪里。
我们可以通过键盘的 Tab 键，进行焦点的切换，而获焦元素则可以通过元素的 :focus 伪类的样式，告诉用户当前焦点位置。
当然，除了 Tab 键之外，对于一些多输入框、选择框的表单页面，我们也应该想着如何简化用户的操作，譬如用户按回车键时自动前进到下一字段。一般而言，用户必须执行的触按越少，体验越佳。👍
下面的截图，完全由键盘操作完成：
通过元素的 :focus 伪类以及键盘 Tab 键切换焦点，用户可以非常顺畅的在脱离鼠标的情况下，对页面的焦点切换及操作。
然而，在许多 reset.css 中，经常能看到这样一句 CSS 样式代码，为了样式的统一，消除了可聚焦元素的 :focus 伪类：
:focus { outline: 0; }
我们给上述操作的代码。也加上这样一句代码，全程再用键盘操作一下：
除了在 input 框有光标提示，当使用 Tab 进行焦点切换到 select 或者到 button 时，由于没有了 :focus 样式，用户将完全懵逼，不知道页面的焦点现在处于何处。
保证非鼠标用户体验，合理运用 :focus-visible
当然，造成上述结果很重要的一个原因在于。:focus 伪类不论用户在使用鼠标还是使用键盘，只要元素获焦，就会触发。
而其本身的默认样式又不太能被产品或者设计接受，导致了很多人会在焦点元素触发 :focus 伪类时，通过改变 border 的颜色或者其他一些方式替代或者直接禁用。而这样做，从可访问性的角度来看，对于非鼠标用户，无疑是灾难性的。
基于此，在W3 CSS selectors-4 规范 中，新增了一个非常有意思的 :focus-visible 伪类。
:focus-visible：这个选择器可以有效地根据用户的输入方式(鼠标 vs 键盘)展示不同形式的焦点。
有了这个伪类，就可以做到，当用户使用鼠标操作可聚焦元素时，不展示 :focus 样式或者让其表现较弱，而当用户使用键盘操作焦点时，利用 :focus-visible，让可获焦元素获得一个较强的表现样式。
看个简单的 Demo：
<button>Test 1</button>
button:active { background: #eee; } button:focus { outline: 2px solid red; }
使用鼠标点击：
可以看到，使用鼠标点击的时候，触发了元素的 :active 伪类，也触发了 :focus伪类，不太美观。但是如果设置了 outline: none 又会使键盘用户的体验非常糟糕。尝试使用 :focus-visible 伪类改造一下：
button:active { background: #eee; } button:focus { outline: 2px solid red; } button:focus:not(:focus-visible) { outline: none; }
看看效果，分别是在鼠标点击 Button 和使用键盘控制焦点点击 Button：
可以看到，使用鼠标点击，不会触发 :foucs，只有当键盘操作聚焦元素，使用 Tab 切换焦点时，outline: 2px solid red 这段代码才会生效。
这样，我们就既保证了正常用户的点击体验，也保证了一批无法使用鼠标的用户的焦点管理体验。
值得注意的是，有同学会疑惑，这里为什么使用了 :not 这么绕的写法而不是直接这样写呢：
button:focus { outline: unset; } button:focus-visible { outline: 2px solid red; }
为的是兼容不支持 :focus-visible 的浏览器，当 :focus-visible 不兼容时，还是需要有 :focus 伪类的存在。
使用 WAI-ARIA 规范增强语义 -- div 等非可获焦元素模拟获焦元素
还有一个非常需要注意的点。
现在很多前端同学在前端开发的过程中，喜欢使用非可获焦元素模拟获焦元素，譬如：
- 使用 div 模拟 button 元素
- 使用 ul 模拟下拉列表 select 等等
当下很多组件库都是这样做的，譬如 element-ui 和 ant-design。
在使用非可获焦元素模拟获焦元素的时候，一定要注意，不仅仅只是外观长得像就完事了，其行为表现也需要符合原本的 button、select 等可聚焦元素的性质，能够体现元素的语义，能够被聚焦，能够通过 Tab 切换等等。
基于大量类似的场景，有了 WAI-ARIA 标准，WAI-ARIA是一个为残疾人士等提供无障碍访问动态、可交互Web内容的技术规范。
简单来说，它提供了一些属性，增强标签的语义及行为：
- 可以使用 tabindex 属性控制元素是否可以聚焦，以及它是否/在何处参与顺序键盘导航
- 可以使用 role 属性，来标识元素的语义及作用，譬如使用 <div id="saveChanges" tabindex="0" role="button">Save</div> 来模拟一个按钮
- 还有大量的 aria-* 属性，表示元素的属性或状态，帮助我们进一步地识别以及实现元素的语义化，优化无障碍体验
使用工具查看标签的语义
我们来看看 Github 页面是如何定义一个按钮的，以 Github Issues 页面的 Edit 按钮为例子：
一块，清晰的描述了这个按钮在可访问性相关的一些特性，譬如 Contrast 色彩对比度，按钮的描述，也就是 Name，是给屏幕阅读器看到的，Role 标识是这个元素的属性，它是一个按钮，Keyboard focusable 则表明他能否被键盘的 Tab 按钮给捕获。
分析使用非可聚焦元素模拟的按钮
这里，我随便选取了我们业务中一个使用 span 模拟按钮的场景，是一个面包屑导航，点击可进行跳转，发现惨不忍睹：
HTML 代码：
<span class="ssc-breadcrumb-item-link"> Inbound </span>
基本上可访问性为 0，作为一个按钮，它不可被聚焦，无法被键盘用户选中，没有具体的语义，色彩对比度太低，可能视障用户无法看清。并且，作为一个能进行页面跳转的按钮，它没有不是 a 标签，没有 href 属性。
即便对于面包屑导航，我们可以不将它改造成 <a> 标签，也需要做到最基本的一些可访问性改造：
<span role="button" aria-label="goto inbound page" tabindex="0" class="ssc-breadcrumb-item-link"> Inbound </span>
不要忘了再改一下颜色，达到最低色彩对比度以上，再看看：
OK，这样，一个最最最基本的，满足最低可访问性需求的按钮算是勉强达标，当然，这个按钮可以再更进一步进行改造，涉及了更深入的可访问性知识，本文不深入展开。
分析组件库的 A11Y
最后，在我们比较常用的 Vue - element-ui、React - ant-design 中，我们来看看 ant-design 在提升可访问性相关的一些功能。
以 Select 选择框组件为例，ant-design 利用了大量的 WAI-ARIA 属性，使得用 div 模拟的下拉框不仅仅在表现上符合一个下拉框，在语义、行为上都符合一个下拉框，简单的一个例子：
看看使用 div 模拟下拉框的 DOM 部分：
再看看在交互体验上：
上述操作全是在键盘下完成，看着平平无奇，实际上组件库在正常响应可获焦元素切换的同时，给用 div 模拟的 select 加了很多键盘事件的响应，可以利用回车，上下键等对可选项进行选择。其实是下了很多功夫。
对于 A11Y 相关的内容，篇幅及内容非常之多，本文无法一一展开，感兴趣的可以通读下下列文章：
总结一下
本文从页面展示、交互细节、可访问性三个大方面入手，罗列一些在实际的开发过程中，积攒的一些有益的经验。虽然不够全面，不过从一开始也就没想着大而全，主要是一些可能有用但是容易被忽视的点，也算是一个不错的查缺补漏小指南。
当然，很多都是我个人的观点想法，可能有一些理解存在一些问题，一些概念没有解读到位，也希望大家帮忙指出。
