本文是基于 Shopee 供应链团队 WMS（Warehouse Management System，仓库管理系统） 项目的整体重构，总结而出的一份 Web 用户体验设计提升指南。

在这一篇文章中，我们将从交互设计与可访问性的角度聊聊如何提升 Web 端用户体验。还没有读过上一期文章的小伙伴请戳：《Web 用户体验设计提升实践（上）》。

2. 交互设计优化

接下来一个大环节是一些关于交互的细节。

什么是交互设计？交互设计（Interaction Design, IXD）是定义、设计人造系统的行为的设计领域，它定义了两个或多个互动的个体之间交流的内容和结构，使之互相配合，共同达成某种目的。

2.1 Web 端交互方式

Web 端交互围绕计算机为中心，主要涉及键盘、鼠标两类设备的交互。

关于交互设计，一些比较通用的准则有：

• Don’t make me think
• 符合用户的习惯与预期
• 操作便利
• 做适当的提醒
• 不强迫用户

2.2 Don’t make me think

有一本书就叫 Don’t make me think，它所想表述的核心是，尽可能让产品做到高可用性，让用户无须思考也能明确无误地使用产品中的各项功能。

那么，我们的页面如何尽可能做到高可用性呢？

2.2.1 使用习惯用法

使用习惯用法。当我们设计一个新的页面时，页面位置、功能设置、视觉元素应当和惯常用法相差无几，这样才能让用户有舒适感。

这里并不是要扼杀大家的想象力，让所有页面都一成不变。根据产品的形态及受众，大部分页面是不适用于各种天马行空的想象的。

例如下面这样一个 PC 端页面结构，这种布局已经非常常见。遇到这种页面，用户能够非常快速地在指定区域找到想要的元素及信息：

可以再和我们的 WMS 重构后的页面作比较，整体是非常类似的：

采用习惯用法的设置能够让人快速上手新的陌生的页面或者功能。

2.2.2 降低视觉噪声

另外一种做法是降低视觉噪声，让用户快速聚焦。

譬如弹窗背后的阴影、虚化，就是非常好的降低视觉噪声的手段。

这一点还是非常好理解的，也属于常见设计手段之一，在我们内部的相关组件、自研组件库已经沉淀得很好了。

2.3 符合用户的习惯与预期

接下来是符合用户的习惯与预期，它的意义在于减少用户的思考，符合用户的习惯，让用户的体验更加舒适。

下面这几种弹窗，哪一个是更好的选择？

三个弹窗可供操作的按钮分别是：

• 右下角的取消和确认，同时右上角的 X 可以关闭弹窗；
• 只有右下角的取消和确认；
• 只有确认按钮。

更好的选择应该是第一个：同时有取消和确认按钮，右上角的 X 可以关闭弹窗。因为这样最符合用户的习惯预期。

看看这个 Windows 下的弹窗：

大部分 Windows 的弹窗，都是有取消、确认加上右上角的 X 按钮的。这种弹窗的好处在于：

• 视觉原因，元素平衡；
• 符合用户习惯，大多数用户都是 Windows 操作系统过来的；
• 交互一致性，降低用户学习成本；
• 提升页面的可访问性和无障碍访问性。

2.3.1 优化手势：不同场景应用不同 cursor

对于不同的内容，最好给出不同的 cursor 样式，CSS 原生提供了非常多种常用的手势。

在不同的场景使用不同的鼠标手势，符合用户的习惯与预期，可以很好地提升用户的交互体验。

首先对于按钮，就至少会有三种不同的 cursor，分别是可点击、不可点击、等待中：

{
    cursor: pointer;    // 可点击
    cursor: not-allowed;    // 不可点击
    cursor: wait;    // loading
}

除此之外，还有一些常见用法：对于一些可输入的 Input 框，使用 cursor: text；对于提示 Tips 类，使用 cursor: help；放大缩小图片 zoom-in、zoom-out 等等：

一些常用的简单列一列：

• 按钮可点击: cursor: pointer
• 按钮禁止点击：cursor: not-allowed
• 等待 loading 状态：cursor: wait
• 输入框：cursor: text
• 图片查看器可放大可缩小：cursor: zoom-in/ zoom-out
• 提示：cursor: help

当然，实际 cursor 还支持非常多种，可以在 MDN 或者下面这个 CodePen Demo 中查看完整列表：CodePen Demo - Cursor Demo。

2.3.2 点击区域优化：伪元素扩大点击区域

按钮是我们网页设计中十分重要的一环，而按钮的设计也与用户体验息息相关。

考虑这样一个场景：在摇晃的车厢上或者是单手操作着屏幕，有的时候一个按钮死活也点不到。

让用户更容易点击到按钮无疑能很好地提升用户体验，并提升页面的访问性。尤其是在移动端，按钮通常都很小，但是受限于设计稿或者整体 UI 风格，我们不能直接去改变按钮元素的高宽。

那么，有什么办法在不改变按钮原本大小的情况下增加点击热区呢？

借助伪元素可以轻松实现。伪元素也是可以代表其宿主元素来响应鼠标交互事件的。我们可以这样写：

.btn::before{
  content:"";
  position:absolute;
  top:-10px;
  right:-10px;
  bottom:-10px;
  left:-10px;
}

当然，在 PC 端下这样子看起来有点奇怪，但是合理地用在点击区域较小的移动端则能取得十分好的效果：

2.4 操作便利

好的系统，操作起来应该是流畅的。同时，它能够通过一些小细节打动用户。

2.4.1 快速选择优化：user-select: all

操作系统或者浏览器通常会提供一些快速选取文本的功能。看看下面的示意图：

快速单击两次，可以选中单个单词；快速单击三次，可以选中一整行内容。但如果核心内容被分隔符分割，或者成为潜藏在一整行中的一部分，这个时候选取起来就比较麻烦。

利用 user-select: all，可以将需要一次选中的内容进行包裹，用户只点击一次，就可以选中该段信息：

.g-select-all {
    user-select: all
}

给需要一次选中的信息加上这个样式，该细节作用在一些需要复制粘贴的场景时，非常好用。

在我们 WMS 的很多操作页面，需要频繁从表格中复制一些基础信息，例如下述的 Location ID、Cell Name，由于完整的字段使用了分隔符 -，所以一次点击是无法选中整段信息的，而利用 user-select: all 可以很好地解决这个痛点：

别看只是减少一次点击鼠标的次数，但正是这些细节的累积，才更能让用户感受到开发者的用心。

CodePen - user-select: all 示例

2.4.2 选中样式优化：::selection

CSS 还提供了一个 ::selection 伪类，可以控制选中的文本样式（只能控制 color、background、text-shadow），进一步加深效果。

CodePen - user-select: all && ::selection 控制选中样式

2.4.3 添加禁止选择：user-select: none

有快速选择，也就会有它的对立面——禁止选择。

对于一些可能频繁操作的按钮，可能会出现如下尴尬场景：

• 文本按钮的快速点击，触发了浏览器的双击快速选择，导致文本被选中：
• 翻页按钮的快速点击，触发了浏览器的双击快速选择：

对于这种场景，我们需要把不可被选中的元素设置为不可被选中，利用 CSS 可以快速实现这一点：

{
    -webkit-user-select: none; /* Safari */
    -ms-user-select: none; /* IE 10 and IE 11 */
    user-select: none; /* Standard syntax */
}

这样，无论点击频率多快，都不会出现内容被选中的尴尬情况：

2.5 跳转优化

现阶段，单页应用（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>

在实际的 WMS 重构过程中，我们对于所有有页面跳转功能的按钮，包括但不限于路由菜单、面包屑导航、跳转按钮等，都进行了跳转优化，以满足用户的不同诉求。

路由菜单导航：

表格中的一些按钮跳转：

2.6 表单交互优化

输入及选择于用户而言，是一项高交互成本的操作。下面提供了一些小的建议来减少用户输入出错、提升用户体验。

2.6.1 尽可能地简化表单

将表单做得简单点，确保用户在抓狂之前能进入下一步（表单越复杂，流失率越高）：

对于没法省去的输入项，尽可能简化用户的输入：

• 智能预设默认项
• 输入时提供智能联想
• 对于选择框，尽可能精简选项信息
• 使用单选项来代替下拉菜单

2.6.2 及时校验

表单及时校验，而不是用户填完一堆信息，统一提交后才告诉用户填错了：

2.6.3 贴心细节提示，校验更宽容

还有一些比较有益的建议，可以有效的提升交互过程中用户的体验，根据实际情况可以考虑：

• 在表单中增加一些提示信息，减少错误的几率
• 尝试将表单输入变得更加宽容，让用户的填写更加简单

2.7 先探索，后表态

这一点非常有意思，什么叫先探索后表态呢？就是我们不要一上来就强迫用户去做一些事情，例如登录。想一想一些常用网站的例子：

• 类似虎牙、bilibili 等视频网站，可以先蓝光体验，一定观看时间后才会要求登录；
• 电商网站，只有到付款的时候，才需要登录。

上述易用性和先探索后表态的内容，部分来源于 “Learn From What Leading Companies A/B Test”，推荐阅读。

2.8 结合产品的创意交互动画

由于业务的类型限制，在这一块，我们实际中运用的并不多，但是它也是增强用户体验非常有益且重要的一环，下文将简单讲一讲。

这一类交互为结合产品的创意交互动画。通过定制化的有仪式感的交互，提升品牌价值，能给予用户深刻的印象。

结合产品及业务的创意动画，是需要挖掘，不断打磨、不断迭代的。比如 bilibili 官网的顶部 banner，配合一些节日、活动，经常会出现一些有意思的创意交互动画：

以及这个：

我非常多次在不同地方看到有人讨论 bilibili 的顶部 banner 动画，可见它这块的动画是成功的。很好地结合了一些节日、实事、热点，作为一种比较固定的产品去不断推陈出新，在不同时候带给用户不同的体验。

2.9 字体优化

字体的选择与使用其实是非常有讲究的。

在 WMS 项目重构过程中，我们使用的全局字体定义是：font-family: Roboto,system-ui,-apple-system,BlinkMacSystemFont,Segoe UI,Oxygen,Ubuntu,Fira Sans,Droid Sans,Helvetica Neue,"sans-serif";。

这里，我们的设计师对英文字体有一些强限制，首选字体是 Roboto，并且在系统中提供了该字体包。

如果网站没有强制必须使用某些字体。最新的规范建议我们使用系统默认字体。也就是 “CSS Fonts Module Level 4: Generic font families” 中新增的 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;

简单而言，它们总体遵循了以下几项基本原则：

2.9.1 尽量使用系统默认字体

使用系统默认字体的主要原因是性能，系统字体的优点在于它与当前操作系统相匹配，因此它的文本展示效果必然也是令人舒适的。

2.9.2 兼顾中西：西文在前，中文在后

中文或者英文（西文）都要考虑到。由于大部分中文字体也带有英文部分，但是英文部分又不怎么好看，并且英文字体中大多不包含中文。因此我们通常会先进行英文字体的声明，选择最优的英文字体，这样不会影响到中文字体的选择。

2.9.3 兼顾多操作系统

选择字体的时候要考虑多操作系统。例如 macOS 下的很多中文字体在 Windows 都没有预装。为了保证 Mac 用户的体验，在定义中文字体的时候，先定义 Mac 用户的中文字体，再定义 Windows 用户的中文字体。

2.9.4 兼顾旧操作系统：以字体族系列 serif 和 sans-serif 结尾

当使用一些非常新的字体时，要考虑向下兼容，兼顾到一些极旧的操作系统，使用字体族系列 serif 和 sans-serif 结尾总归是不错的选择。

3. 可访问性（A11Y）

可访问性（accessibility，也被称为 “A11Y”）在网站中属于非常重要的一环，但是大部分前端（其实应该是设计、前端、产品）同学都忽视了它。

3.1 什么是可访问性

传统上我们认为这只与残障人士有关，但提升网站的可访问性也可以让其他用户群体（每个人）受益。

根据网页内容可访问性准则（即 “Web Content Accessibility Guidelines (WCAG) 2.0”），Web 可访问性有以下四个基础性原则。

（1）可感知

• 用文本替代非文本内容
• 多媒体的字幕及其他替代物
• 内容有多种呈现方式
• 内容的看和听更容易

（2）可操作

• 可以通过键盘使用功能
• 用户有充足的时间阅读和使用内容
• 内容不要诱发癫痫和物理反应
• 用户可以方便地导航、找到内容并确认自己在哪里
• 用户可以使用除键盘外的不同输入方式

（3）可理解

• 文本容易阅读和理解
• 内容以可预测的方式出现和操作
• 用户可以得到帮忙，以避免和纠正错误

（4）健壮性

• 健壮的内容和可靠的解释
• 内容与现在和未来的用户工具兼容
• 在各个平台和环境中都能正确地展示

我潜伏在一个叫无障碍设计小组的群里，其中包含了很多无障碍设计师以及患有一定程度视觉、听力、行动障碍的用户，他们在群里经常会表达出一个观点，就是国内的大部分 Web 网站及 App 基本没有考虑过残障人士的使用（或者可访问性做得很差），非常令人揪心。

尤其在一些重交互、重逻辑的网站中，我们需要从高可访问性的角度考虑用户的使用习惯、使用场景。比如：假设用户没有鼠标，仅仅使用键盘，能否顺畅使用我们的网站？

假设用户没有鼠标，这个真不一定是针对残障人士。很多情况下，用户拿鼠标的手可能在干其他事情，比如在吃东西；又或者在 To B 类的业务，如超市收银、仓库收货，很可能用户拿鼠标的手操作着其他设备（扫码枪）等等。

本文不会专门阐述无障碍设计的方方面面，只是从一些我觉得前端工程师需要关注的，并且仅需要花费少量代价就能做好的一些无障碍设计细节。记住，无障碍设计对所有人都更友善。

3.2 色彩对比度

颜色，也是我们天天需要打交道的属性。大部分视觉正常的用户可能对页面的颜色敏感度还没那么高。但是对于一小部分色弱、色盲用户，他们对网站的颜色会更加敏感，不好的设计会给他们访问网站带来极大的不便。

3.2.1 什么是色彩对比度

是否曾关心过页面内容的展示，使用的颜色是否恰当？色弱、色盲用户能否正常看清内容？良好的色彩使用，在任何时候都是有益的，而且不仅仅局限于色弱、色盲用户。在户外使用手机，阳光很强看不清时，符合无障碍标准的高清晰度、高对比度文字就更容易阅读。

这里引入了一个概念——色彩对比度。简单地说，就是两种颜色在亮度（brightness）上的差别。运用到我们的页面上，大多数的情况就是背景色（background-color）与内容颜色（color）的对比差异。

“最权威的互联网无障碍规范——WCAG AA 规范规定，所有重要内容的色彩对比度需要达到 4.5:1 或以上（字号大于 18 号时达到 3:1 或以上），才算拥有较好的可读性。”

看看下面这张图：

很明显，对比度由低到高。前两个例子，别说视障用户，正常用户都已经很难看得清了。

当然，也会存在一些特例，譬如输入框的 placeholder、按钮的禁用状态等等。因此，在网页重构的过程中，我们需要尽可能遵循这个规范。但又不是盲目遵循，导致毫无回旋余地。

3.2.2 检查色彩对比度的工具

Chrome 浏览器从很早开始，就已经支持检查元素的色彩对比度了。以 WMS 页面中的一个 Table Header 为例，我们可以去检查一些无法直观界定是否达到标准的文字：

审查元素，分别可以看到当前文字与背景的对比度。下述结果表示，这个对比度是没有问题的：

当然，我们的页面上也会存在这样的面包屑导航：

可以看到，色彩对比度没有达到标准文字被用黄色的叹号标识了出来。

除此之外，在审查元素的 Style 界面的取色器改变颜色，也能直观地看到当前的色彩对比度：

3.2.3 不要单纯依赖颜色

为了保证无障碍的准确性，应当确保你没有完全依赖颜色来展示系统不同层级的关键信息。

看看下面这个例子：

本来我们期待利用绿色和红色来表达正确与错误，但是对于部分视觉障碍用户，他可能根本感受不到这个提示。

正确的做法是，使用必要的文字和图标进行说明：

因此在实际应用中，我们需要利用能传达准确信息的图标配合文字描述去表达，譬如 WMS 登录错误页面：

3.3 焦点响应

类似百度、谷歌的首页，进入页面后会默认让输入框获得焦点：

并非所有的有输入框的页面都需要进入页面后进行聚焦，但是焦点能够让用户非常明确地知道当前自己在哪，需要做些什么。尤其是对于无法操作鼠标的用户来说。

页面上可以聚焦的元素，称为可聚焦元素，获得焦点的元素，则会触发该元素的 focus 事件。对应地，也会触发该元素的 :focus 伪类。

浏览器通常会使用元素的 :focus 伪类，给元素添加一层边框，告诉用户当前的获焦元素在哪里。

我们可以通过键盘的 Tab 键，进行焦点的切换。而获焦元素则可以通过元素的 :focus 伪类的样式，告诉用户当前焦点位置。

当然，除了 Tab 键之外，对于一些多输入框、选择框的表单页面，我们也应该想着如何简化用户的操作，例如用户按回车键时自动前进到下一字段。一般而言，用户必须执行的触按越少，体验越佳。👍🏻

下面的截图，完全由键盘操作完成：

通过元素的 :focus 伪类以及键盘 Tab 键切换焦点，用户可以非常顺畅的在脱离鼠标的情况下，对页面的焦点切换及操作。

然而，在许多 reset.css 中，经常能看到这样一句 CSS 样式代码，为了样式的统一，消除了可聚焦元素的 :focus 伪类：

:focus {
    outline: 0;
}

我们给上述操作的代码。也加上这样一句代码，全程再用键盘操作一下：

除了在 input 框有光标提示，当使用 Tab 进行焦点切换到 select 或者到 button 时，由于没有了 :focus 样式，用户会感到迷茫，不知道页面的焦点现在处于何处。

3.3.1 保证非鼠标用户体验，合理运用 :focus-visible

造成上述结果很重要的一个原因在于，:focus 伪类不论用户在使用鼠标还是使用键盘，只要元素获焦，就会触发。

而其本身的默认样式又不太能被产品或者设计接受，导致了很多人会在焦点元素触发 :focus 伪类时，通过改变 border 的颜色或者其他一些方式替代或者直接禁用。而这样做，从可访问性的角度来看，对于非鼠标用户，无疑是灾难性的。

基于此，在 W3 CSS selectors-4 规范中，新增了一个非常有意思的 :focus-visible 伪类。这个选择器可以有效地根据用户的输入方式（鼠标或是键盘）展示不同形式的焦点。

有了这个伪类，当用户使用鼠标操作可聚焦元素时，就可以做到不展示 :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：

CodePen Demo - :focus-visible example

可以看到，使用鼠标点击，不会触发 :foucs，只有当键盘操作聚焦元素，使用 Tab 切换焦点时，outline: 2px solid red 这段代码才会生效。

这样，我们就既保证了正常用户的点击体验，也保证了一批无法使用鼠标的用户的焦点管理体验。

值得注意的是，有同学会疑惑，这里为什么使用了 :not 这么绕的写法而不是直接这样写呢：

button:focus {
  outline: unset;
}
button:focus-visible {
  outline: 2px solid red;
}

为的是兼容不支持 :focus-visible 的浏览器，当 :focus-visible 不兼容时，还是需要有 :focus 伪类的存在。

我们在实际的 WMS 重构过程中，也会尽量保持这一点，让用户尽可能在非鼠标操作下（仅仅使用键盘），也能使用我们的页面，能做到基础的焦点切换、回车响应事件。

下图是一个简单的演示（仅仅使用键盘进行页面的操作，能够知道当前焦点在哪，可以回车触发点击）：

3.3.2 使用 WAI-ARIA 规范增强语义：div 等非可获焦元素模拟获焦元素

还有一个非常需要注意的点。

现在很多前端同学在前端开发的过程中，喜欢使用非可获焦元素模拟获焦元素，例如：

• 使用 div 模拟 button 元素
• 使用 ul 模拟下拉列表 select 等等

当下很多组件库都是这样做的，像是 element-ui 和 ant-design。

在使用非可获焦元素模拟获焦元素的时候，一定要注意，不仅仅只是外观长得像就完事了，其行为表现也需要符合原本的 button、select 等可聚焦元素的性质，能够体现元素的语义，能够被聚焦，能够通过 Tab 切换等等。

基于大量类似的场景，有了 WAI-ARIA 标准。它是一个为残疾人士等提供无障碍访问动态、可交互 Web 内容的技术规范。

简单来说，WAI-ARIA 提供了一些属性，用于增强标签的语义及行为：

• 可以使用 tabindex 属性控制元素是否可以聚焦，以及它是否/在何处参与顺序键盘导航；
• 可以使用 role 属性，来标识元素的语义及作用，譬如使用 <div id="saveChanges" tabindex="0" role="button">Save</div> 来模拟一个按钮；
• 还有大量的 aria-* 属性，表示元素的属性或状态，帮助我们进一步地识别以及实现元素的语义化，优化无障碍体验。

3.4 使用工具查看标签的语义

我们来看看 Github 页面是如何定义一个按钮的。以 Github Issues 页面的 Edit 按钮为例：

这一块清晰地描述了这个按钮在可访问性相关的一些特性。比如 Contrast（色彩对比度）、Name（按钮的描述），是给屏幕阅读器看到的；Role 标识是这个元素的属性，它是一个按钮，Keyboard focusable 则表明能否被键盘的 Tab 按钮捕获。

3.5 分析使用非可聚焦元素模拟的按钮

这里随便选取了我们业务中一个使用 span 模拟按钮的场景，是一个面包屑导航，点击可进行跳转：

HTML 代码：

<span class="ssc-breadcrumb-item-link"> Inbound </span>

基本上可访问性为零。作为一个按钮，它不可被聚焦，无法被键盘用户选中，没有具体的语义，色彩对比度太低，可能视障用户无法看清。并且，作为一个能进行页面跳转的按钮，它没有 <a> 标签，没有 href 属性。

对于面包屑导航，我们可以不将它改造成 <a> 标签，但也需要做到最基本的一些可访问性改造：

<span role="button" aria-label="goto inbound page" tabindex="0" class="ssc-breadcrumb-item-link"> Inbound </span>

不要忘了再改一下颜色，达到最低色彩对比度以上，再看看：

这样，一个最最最基本的，满足最低可访问性需求的按钮算是勉强达标。当然，这个按钮可以再更进一步进行改造，涉及了更深入的可访问性知识，本文不详细展开。

3.6 分析组件库的可访问性

最后，我们来看看常用的 ant-design 在提升可访问性上的一些相关功能。

以 Select 选择框组件为例，ant-design 利用了大量的 WAI-ARIA 属性，使得用 div 模拟的下拉框不仅仅在表现上符合一个下拉框，在语义和行为上也都符合一个下拉框。

看看使用 div 模拟下拉框的 DOM 部分：

再看看在交互体验上：

上述操作完全在键盘下完成，看着平平无奇，实际上组件库在正常响应可获焦元素切换的同时，给用 div 模拟的 select 加了很多键盘事件的响应，可以利用回车、上下键等对可选项进行选择。其实下了很多功夫。

对于可访问性相关的内容非常多，本文无法一一展开，这里有一份简单的指南：

• 通过 Web 内容无障碍指南（WCAG 2.0）了解可访问性涉及的内容；
• 通过 WAI-ARIA 了解如何改造页面；
• 不断了解最新的规范，通过浏览器最新的功能持续增强可访问性。

4. 总结

本文从页面展示、交互细节、可访问性三个大方面入手，列举了一些在实际开发过程中积攒的有益经验。虽然不够全面，主要是一些可能有用但是容易被忽视的点，也算是一个不错的查缺补漏小指南。

提升用户体验并非易事，但也不难：

• 页面呈现 + 注重细节的交互设计 + 完善的可访问性 + 性能（性能本文没有过多提及） = 良好的用户体验；
• 用户体验是可以被提升的，而且并不难；
• 良好的用户体验设计，是产品开发每一个环节共同努力的结果；
• 提升用户体验也不是能够一蹴而就的，在不同的细节发力，积少成多。

以上观点和想法可能有一些理解存在问题，一些概念没有解读到位，也希望大家参与交流并指正。

参考资料

• WAI-ARIA basics
• WAI-ARIA 1.1
• Web 中的焦点管理
• 无障碍功能
• 功能性动画设计：优秀的转场效果
• 前端基础知识概述
• 图片加载失败后 CSS 样式处理最佳实践
• 你所不知道的 CSS 动画技巧与细节
• Web 动画原则及技巧浅析
• 如何设计产品的空白页面？
• 助你轻松做好无障碍的 15 个 UI 设计工具推荐
• Improve Your UI With Winning & Losing A/B Tests

本文作者

Coco，前端开发工程师，来自 Shopee 供应链仓储管理（Warehouse management system, WMS）团队。

加入我们

Shopee WMS 支撑着 Shopee 所有自营业务和越来越多 Shopee 平台商家的仓储业务，是供应链核心系统之一，目前服务范围覆盖整个东南亚市场，支撑日百万级别包裹出库履约。我们致力于打造一套能面向不同市场不同文化能差异化操作的，支持药品、生鲜等多垂直领域的，未来能支撑日千万级包裹出库履约的仓储系统；我们持续优化流程、算法、升级系统架构，引入自动化设备，以达到降本增效的目的，同时使某些新的商业模式成为可能。

目前团队大量岗位持续招聘中，海量 HC 涵盖后端、前端、测试、产品等，感兴趣的同学可将简历发送至 kingsley.huang@shopee.com （亦可进行咨询，注明来自 Shopee 技术博客）。