企业官网建设流程全解析

你可能意识不到，一个电商网站如果购物流程存在可访问性障碍，流失的不只是几位特殊用户，而是整整一个用户群体。我见过太多团队把可访问性测试当成“最后的合规检查”，结果首页评分高得漂亮，真正的下单转化率却低得吓人。

我自己在帮多个电商项目做审计时发现，购物流程往往是最容易暴露可访问性问题的地方，也是修复收益最高的地方。原因很简单，购物流程涉及大量表单、交互弹窗、动态内容更新和页面跳转，每一步都可能成为某类用户无法跨越的坎。这篇文章我就围绕“购物流程”这条主线，把我实际测试中用到的思路、步骤、坑和经验一次性讲清楚。

市面上关于可访问性的资料大多停留在理论和规范层面，真正能指导你把“从登录到支付成功”这条链路完整测一遍的内容很少。我写这篇文章的目的，就是把整套实操方法掰开揉碎，让你既能理解背后的原理，也能直接拿去落地复现。

1. 内容整体设计与思路拆解

可访问性测试在电子商务场景下有一个显著特点：它不是单项检查，而是流程级测试。单看首页轮播图有没有alt文本，或者按钮对比度是否达标，意义不大，因为用户在购物流程中要连续完成多个操作，任何一环断了都会导致交易失败。

1.1 核心需求解析

“测试可访问性电子商务：购物流程”这个主题，本质需求是三个：找出购物流程中的访问障碍、评估障碍对用户完成购买的影响、给出可复现的修复路径。

这意味着测试不能停留在静态页面层面，必须从用户真实行为出发，走完完整的“浏览商品 → 加入购物车 → 结算 → 填写信息 → 支付 → 确认订单”链路。

与普通内容站或官网的可访问性测试相比，购物流程测试的独特性体现在几个方面：

• 表单密度极高，字段校验和错误提示的交互复杂度远超普通页面
• 涉及多种输入方式，键盘、读屏软件、屏幕放大器、语音控制等都会被用到
• 异步内容频繁，购物车数量更新、优惠券加载、支付状态轮询都是动态操作
• 情境信息重要，用户需要随时知道自己在第几步、下一步是什么、当前状态是什么

任何产品经理、开发工程师、测试工程师或无障碍专员，只要想让电商网站真正“人人可用”，都能从这套方法中获得直接帮助。

1.2 为什么选购物流程作为测试主轴

我接触过不少团队，他们一开始做可访问性测试时习惯按页面逐个来：首页测完测列表页，列表页测完测详情页。这种思路不能说错，但很容易漏掉最关键的问题——跨页面和跨交互的连续性。

举一个最常见的例子：用户在商品详情页把一个商品加入购物车，页面上方的购物车图标用数字实时更新了数量。用鼠标操作完全没问题，但读屏用户通过虚拟光标浏览时，屏幕阅读器有没有自动播报“购物车中现有1件商品”？如果用的是aria-live区域，这个播报时机是否合适？这些问题在单页面测试中几乎测不出来，只有沿着购物流程完整走一遍才能暴露。

再比如，很多网站会在用户离开结算页时弹出“确定要离开吗”的对话框。对话框用鼠标没问题，但键盘用户如果焦点没有被正确管理，Tab键可能把焦点移出模态框，直接跳到背后的页面元素上，这种情况不测完整流程同样发现不了。

所以我常用的做法是：先画出一条核心购物路径，以这条路径为骨架，再逐步扩展分支路径和异常路径。这种思路保证测试有主次，也保证覆盖足够全面。

1.3 适用的测试级别与方法矩阵

购物流程的可访问性测试，应该结合多种测试方法，我整理了一个矩阵供参考：

没有任何一项测试是充分的，组合使用才是正解。自动化检测负责兜底，键盘走查负责验证基础可操作性，读屏测试负责验证内容感知，真实用户测试负责发现设计与代码层面的深层问题。

2. 购物流程各环节细节解析与实操要点

从用户视角出发，购物流程可以拆解为几个核心环节。每个环节的可访问性要点都不同，我把它们逐一拆开讲。

2.1 商品浏览与筛选

商品列表页常见的可访问性问题集中在“筛选”和“排序”功能上。

先说筛选。很多电商网站的筛选区默认是一个折叠面板，标题按钮触发展开收起。开收起操作本身能通过键盘完成，但如果展开的内容没有正确的ARIA状态提示，读屏用户就不知道筛选区是开还是关。测试时重点检查筛选标题按钮的aria-expanded属性是否动态更新。

再说筛选条件的反馈。用户选了一个品牌，选了一个价格区间，页面可能通过JavaScript局部刷新列表。如果这个刷新区域的aria-live设置不当，读屏用户会完全察觉不到列表已经变化，还以为是页面卡住了。我通常要求开发团队在商品列表容器上设置“aria-live=polite”，并配以“已为您筛选出X件商品”的提示文本，这样读屏用户就能获得清晰的反馈。

排序功能也有典型问题。常见做法是下拉菜单（select）或者一组按钮。若是select，要注意原生select的键盘操作性本身不错，但如果使用了自定义下拉框，必须自己实现完整的方向键支持、Enter/Space确认、Esc关闭等逻辑。测试时仔细走一遍键盘，几乎所有自定义下拉框的问题都能暴露出来。

分页组件同样容易出问题。不少分页组件的当前页码是靠“高亮颜色”区分的，色弱用户根本分不清。我给电商团队的建议是，当前页码除了颜色差异外，必须同时加粗并配上当前读屏语境下的aria-current=page。

2.2 商品详情与加入购物车

商品详情页的可访问性重点有三个。

第一个是商品图片的alt文本。这个问题看似简单，但信息价值很重要。电商商品图不能写“商品图片”这种空泛描述，应该写“黑色休闲双肩包，正面视角”，这样才能让依赖读屏的用户获取关键信息。

第二个是数量选择器。我见过太多数量选择器是用“+”和“-”两个自定义按钮实现的，问题是开发者在点击后只是改变了视觉数字，却没有把新数值同步告知读屏用户。正确的做法有两种：要么在输入框上设置aria-live并播报实际数量；要么直接使用原生input type=number，利用浏览器自带的无障碍支持。

第三个是加入购物车按钮的反馈。用户点击“加入购物车”后，通常页面会有几个变化：按钮文字变成“已加入”、页面顶部购物车图标数字+1、可能出现一个“打开购物车”的提示条。读屏用户需要的反馈，是在点击按钮后立即听到“商品已加入购物车，购物车中共2件商品”。如果没有这层反馈，用户往往要重复点击，导致重复加购。测试时重点验证点击后焦点是否保持在按钮上、动态反馈是否被正确播报。

2.3 购物车与结算入口

购物车页面常见的问题更复杂，因为这里默认支持“编辑场景”：用户可以修改数量、删除商品、使用优惠券、选择物流方式等，每一步都在改变页面总价。

最核心的可访问性问题是总价更新。用户删掉一件商品后，页面下方总金额会变化，如果总价区域没有aria-live设定，读屏用户就不知道金额变了。测试时检查组这几个位置：商品促销总价、运费、最终应付金额。合理的方案是给最终应付金额区域加上aria-live=polite，并在金额变化时播报“当前应付总额为259元”。

购物车的删除操作同样有讲究。删除一个商品，如果没有二次确认，用户误删后要花很大功夫找回。如果有二次确认对话框，就要确保对话框能正确聚焦、能通过键盘关闭、焦点在关闭后能回到触发删除按钮的位置。

去结算入口还有一个特别容易出恶性bug的点：优惠券输入框和“使用”按钮分离过多页。合理的做法是把输入框和按钮放在同一行，键盘焦点顺序保持输入框 → 按钮 → 提示结果的自然顺序。很多团队会把优惠券使用入口放在页面底部，用户结算才发现忘了用，这个交互设计本身就形成了访问障碍。

2.4 信息填写与支付流程

这是整个购物流程中可访问性问题的重灾区，几乎每个项目都能在这里发现一堆问题。

表单字段的label关联是基础中的基础。我有一次审计一个服装电商项目，发现结算页有十几个字段，其中三成的字段没有正确的label for关联。搜索那位开发为什么这样做，他说“用placeholder当提示不也一样吗”。这就是典型的认知误区。placeholder会在输入后消失，用户输入过程中大概率记不住自己正在填的是名字还是电话；而且读屏软件对placeholder的读取依赖性强，很多读屏组合根本不播报placeholder。购物场景下必须保证每字段都有持久可见的label标签。

错误提示的可访问性是另一个高频问题。表单提交出错时，视觉上往往用红色文字提示，位置在字段下方。这种做法的直接后果是，读屏用户填完表单点提交，页面刷新后光标被弹回顶部，错误提示在页面下方，用户完全不知道发生了什么。正确方案总结起来就三条：

• 错误提示文本要关联到对应输入框，通常用aria-describedby
• 提交出错时把焦点移到第一个出错的字段，并播报“第1个字段填写有误”
• 页首设置一个错误汇总区，列出所有出错字段的链接，方便用户点击跳转

支付环节的动态性问题最多。很多网站的支付方式切换是纯JavaScript交互，切到“银行卡支付”时展开一个表单，切到“二维码支付”时隐藏表单。如果展开/隐藏没有正确的状态宣告，读屏用户就不知道当前看到的信息是否还有效。我一般建议在切换容器上用aria-live=polite，切换后播报当前支付方式的名称。

个还有大量网站有“自动跳转”问题，典型的如支付成功后自动跳转回订单列表页。视觉用户能自然感知页面变化，但读屏用户常常被困在旧的上下文中。规范的做法是：跳转前提供倒计时链接“3秒后自动返回订单列表，如未跳转请点击此处”，这样即使用户读速慢，也有兜底方案。

2.5 订单确认与售后路径

订单确认页相对简单，但有一个细节值得注意：确认信息应当既能全局浏览，也能段落跳读。读屏用户通常会开启“逐项跳转”模式，用标题或列表快速浏览订单条目。所以订单概要最好使用语义化的标题层级，而不是全靠视觉上的一张表格。

售后路径我只要提醒一点：让用户能够方便地找到客服入口和退换货入口。这项功能对无障碍的影响，往往出现在键盘操作路径上。很多网站的客服入口藏在“帮助中心”的多级悬停菜单里，键盘用户根本打不开。这个问题不算复杂，却直接影响用户遇到问题时的求助能力。

3. 实操过程与核心环节实现

理论讲再多，不落地复现一遍，价值就打折。下面我给出一次完整的购物流程可访问性测试实操记录，从工具准备到最终报告输出，每一步都可以直接参考。

3.1 测试环境的搭建

我测试电商网站时，准备的环境分三层：

第一层是当前最新的Chrome或Edge浏览器作为主测试浏览器，开着开发工具里的可访问性检查面板实时观察。第二层是屏幕阅读器，Windows上我首选NVDA，macOS上首选VoiceOver，两者都免费且市场占有率高。第三层是自动化工具，axe-core通过浏览器扩展或npm包运行，Lighthouse用来跑综合性能和无障碍分。

如果被测网站是移动端电商，还需要准备TalkBack或VoiceOver对应的移动端模拟器。移动端的可访问性测试思路与桌面端不完全相同，比如TalkBack的滑动手势和焦点机制差异很大，实操时不要把它当作桌面读屏的简化版，而是要当成一个独立的测试平台。

提前把测试账号的收货地址和支付方式补齐，能显著提升效率。我在测试时通常会准备常用的收货地址，并把支付方式预先绑定好，否则每趟流程都要重新输入一遍全地址，耗时且容易分心。

3.2 键盘走查实操

键盘走查是成本最低但收益极高的起点。我把键盘走查过程做了细分，确保不遗漏：

1. 从商品列表页开始，按Tab键，观察焦点是否按视觉顺序移动
2. 在筛选区操作，确认Space或Enter能展开收起面板，Esc能正常关闭
3. 进入商品详情页，用Tab定位到“加入购物车”，按Enter或Space触发
4. 跳转到购物车，尝试修改数量、删除商品、使用优惠券
5. 进入结算页，用Tab逐字段填写，用Shift+Tab反向移动，确认焦点顺序不跳乱
6. 故意不填某个必填字段，提交表单，检查错误提示的焦点管理
7. 完成支付，等待订单确认，确认焦点不会丢失

键盘走查最常见的发现是“焦点掉进黑洞”。所谓焦点黑洞，就是Tab按着按着焦点突然不见了，页面滚动也没反应。遇到这类问题，通常是某个动态插入的容器没有可聚焦元素，或者某个隐藏元素还残留着tabindex=0。定位方式是打开开发者工具，在控制台执行document.activeElement，看看焦点到底落在哪个节点上。

另一个高频问题是焦点可见性。很多电商主题为了让按钮更“干净”，故意去掉了焦点框或者把焦点框设成和背景相同的颜色。这样键盘用户按Tab时完全无法判断当前焦点在哪。测试标准很简单：页面所有可交互元素的焦点框必须用显眼的对比色，且不能仅依赖hover。

3.3 读屏软件实操

键盘走查通过后，用读屏软件走一遍，重点验证“看不见的信息”。我以NVDA为例记录操作路径：

1. 打开NVDA，从商品列表页开始，按B键浏览按钮，确认读屏能正确播报所有筛选、排序、分页控件
2. 按H键浏览标题，确认商品名称是正确层级的标题结构
3. 使用Ctrl+Home回到页面顶部，手动Tab到搜索框，输入关键词后按Enter，确认搜索结果页能被正常识别
4. 进入商品详情页，确认商品图片有有效alt文本，加入购物车时能听到明确反馈
5. 进入购物车，按数字键盘的上下键逐行收听商品条目，确认删除操作有反馈
6. 结算时，按Tab进入表单，确认每字段的label都能被读屏读出，输入错误后能听到错误描述
7. 提交支付，确认订单成功信息能被感知

用屏幕阅读器测试时，我特别关注一个细节：动态内容的播报顺序。不少网站的aria-live区域设置得太激进，页面一加载就连续播报大量内容，或者播报顺序错乱，用户根本听不出重点。实操时留意听，如果读屏播报的内容顺序和视觉呈现不一致，说明应该是aria-live区域乱用导致的，需要调整。

在macOS上用VoiceOver测试时，很多操作逻辑和NVDA不一样。比如NVDA下跳行用Down Arrow，VoiceOver也要用到Ctrl+Option+Down Arrow。好在这两种读屏软件的使用逻辑并不冲突，关键是掌握“浏览模式”和“焦点模式”的切换，这才是理解读屏操作的钥匙。读屏用户的操作精髓在于模式切换：浏览模式下用方向键快速扫读全文，焦点模式下用Tab精准操作控件。测试时熟练切换两种模式，能极大地提高效率。

3.4 自动化审计实操

自动化测不了所有问题，但能快速暴露一批低垂果实。我在实际项目里把自动化审计分为两层：

第一层是页面级审计，用Lighthouse跑桌面和移动端的无障碍总分，优先修复分数低于90的项目。Lighthouse的检查项覆盖了对比度、HTML语义、标签完整性等，虽然不深，但作为门槛是合格的。

第二层是组件级审计，用axe-core在集成测试里跑关键交互组件，比如购物车、结算表单、支付弹窗。我在写自动化测试时，会在每个关键交互后强制插入axe遍历，例如点击“加入购物车”后，立刻跑一次axe.run()，检查新增DOM元素是否引入了新的可访问性问题。这种做法能在每次代码变更时实时拦下不少回归缺陷。

这里的易踩坑在于，自动化测试依赖选择器稳定。很多前端框架的动态生成类名会让选择器频繁失效，好在相关方案已经成熟，优先使用role、label或data-testid，尽量避免直接使用样式类名。同时，axe的规则可以按需禁用部分低价值项，但不得大面积剔除核心规则，否则审计就失去了意义。

3.5 测试报告的整理与修复优先级

测试结束，数据要整理得能直接指导开发，否则一堆问题清单会让团队不知道该先修什么。

我把购物流程的可访问性问题分成三个优先级：

这里我要给一个建议：优先修复所有“表单错误提示”相关的问题。因为结算表单是用户完成购买的必经之路，而这个环节的障碍往往直接决定用户是否能成功下单。不同于首页轮播图那种可回避的问题，表单错误提示的问题是“用户只要出错就走不下去”，必须当作P0来对待。

报告格式本身不用太花哨，每个问题都要包含：复现步骤、影响用户群体、建议修复方案、涉及文件或组件。我习惯在报告里附上操作录屏或读屏录音，这样开发同学不用重新构造复现步骤，修复效率能翻倍。

4. 常见问题与排查技巧实录

长期做购物流程可访问性测试，我积累了一些反复出现的“老面孔”。这里整理成速查表，并附上排查思路。

有几个排查技巧是我平时工作中反复用到的：

第一个是对付“读屏报错信息模糊”的问题。单靠读屏复述往往不够，直接打开开发者工具，选中报错文本节点，查看它的属性和关联关系。如果它没有被任何aria-describedby引用，那基本可以确定开发只做了视觉展示，没有建立辅助技术关联。

第二个是“焦点消失类bug”的百试百灵定位法。打开开发者工具控制台，跑setInterval(() => { console.log(document.activeElement) }, 500)。点击或操作触发bug后，看控制台输出的最后一个activeElement是什么，就能快速锁定焦点在哪里消失的。这个技巧，曾经帮我定位过许多看似玄学的前端焦点bug。

第三个是“动态内容不播报”问题的经典误判。很多人以为是aria-live设错了，其实大多数时候是播报内容在DOM变更前就被移除了，或者是变化太快、读屏来不及合成语音。在这些情况下，重点检查内容插入的时机。通常的做法是：内容先插入DOM，再移除旧内容；或者合理使用setTimeout微延时，让读屏稳定捕捉变化。

还有个容易被我忽略但出现频率很高的“重复播报”问题，原因是开发给多个元素分别设置了aria-live，当一处更新时多个区域同时播报。治理思路是，全页面用到的aria-live区域数量越少越好，关键动态信息统一放一个“状态播报区”，避免碎片化播报。

最后说一下“无障碍测试如何与开发协作”的经验。我发现最好的办法不是测试结束后甩一份报告，而是在开发阶段就把可访问性规则嵌进需求验收标准里。比如每个新建的表单字段，定义好label关联和出错提示关联；每个动态弹窗提交前，必须过一遍键盘操作。这个动作看起来增加了开发工时，但实际上会大幅减少后期修bug的时间成本。

5. 购物流程可访问性测试的自动化与持续集成

一次性的手动测试只能解决当下问题，无法保证下次迭代不会引入回归。购物流程既然是电商产品的核心链路，它的可访问性测试应当被纳入持续集成体系，让每次代码变更都能自动跑一遍关键检查。

5.1 在CI流水线中集成axe-core

我在做自动化集成时最常用的方案是Playwright或Cypress加上axe-core的适配库。核心思路就是：让自动化测试脚本遍历完整购物流程，每到达一个关键节点就调用axe接口做一次可访问性审计。

以Playwright为例，流程大致是：

1. 启动浏览器，访问商品列表页
2. 用axe扫描当前页面，收集违规项
3. 点击加入购物车，等待购物车更新，再次扫描
4. 进入结算页，逐项填写表单，每填写完一个section扫描一次
5. 提交支付，扫描订单确认页
6. 所有扫描结果汇总，若存在P0级违规则阻断构建

这个方案落地后的收益非常直接：之前发版前要人工花半天走查的购物流程无障碍，现在每次提交都能自动跑完一套基础检查，大幅降低了回归风险。

不过我提醒一句：自动化只能验证“代码层面是否合规”，验证不了“真实用户是否顺畅”。所以自动化测试更适合当一道快速防线，替代不了人工键盘走查和读屏测试。

5.2 自定义断言与回归保护

跑过一段时间自动化后我发现，光靠axe的通用规则还不够，购物流程有一些业务特有的无障碍规则需要自定义断言来保护。我举两个实际例子：

第一个是“加购成功必有播报”。我在测试脚本里加了一个断言：点击“加入购物车”后，检查页面中是否存在aria-live区域，且该区域的文本包含“已加入购物车”或“购物车中现有”。如果断言失败，说明开发改动了反馈机制，这往往是可访问性回归的前兆。

第二个是“错误提示必须有文本关联”。我在结算表单测试里断言：故意提交空表单后，页面中必须存在“aria-describedby”指向的错误提示文本。这个断言能直接拦截“只在视觉上红了边框但读屏读不到”的典型问题。

这些自定义断言的设计并不复杂，但需要测试人员对购物流程的无障碍要求有比较清晰的理解。建议团队在自动化构建里把这两类断言作为硬性门槛，比什么都晚。

6. 从合规到体验：购物流程可访问性测试的长期价值

顺着购物流程做完整轮可访问性测试之后，很多团队会发现一个意想不到的现象：修复无障碍缺陷带来的收益，往往超出了“合规达标”本身。

6.1 可访问性修复如何同步提升整体转化率

我参与过的一个案例，服装类电商网站，结算页表单的label补充完整后，整体支付成功率提升了近6个百分点。原因不难理解：表单字段说明更清晰、错误提示更直白，对手机端用户和键盘用户同样友好，转化率的提升自然会反映在这些人群中。

对比度调整也一样。许多电商网站的浅灰色文字让年轻用户在屏幕上看着都费劲，调深之后，不但老年用户的阅读体验提升，在户外强光下用手机购物的用户也大幅受益。

这背后的逻辑是，可访问性测试本质上是在优化信息的可达性和操作的高效性，受益对象从来不只是残障用户。一个购物流程如果能被键盘顺畅操作、被读屏清晰播报、被色弱用户准确识别，那么绝大多数普通用户使用起来都会更顺畅。

6.2 合规评测之外的体验文化

有些团队把可访问性测试做成“每年应付一次评测”的工作，这种思路我不太认同。评测体系本身提供的是底线标准，但购物流程的体验优化没有天花板。

我比较推崇“把无障碍意识日常化”的做法：每次产品设计评审时，附带一个“可访问性走查”环节；每次代码评审时，附带检查“新交互是否能用键盘操作”；每次发版前，让测试同学快速念一遍购物流程的读屏路径。这套机制实施起来成本不高，但会让可访问性从一份静态报告变成一种开发习惯。

我自己在实际操作中的一个感受是，每轮做购物流程的可访问性测试都能发现几个“为残障用户修复、被普通用户叫好”的改变。这是一份极有成就感的工作，因为它直接改善真实用户的生活质量，也给产品带来正向的长期收益。

如果你所在的团队还没有建立购物流程的可访问性测试机制，我建议就从今天开始，挑一个下午，走一遍键盘，开一次读屏，把购物路径完整测一轮。你会发现那些早就存在的短板正在以惊人的速度浮出水面，也会庆幸这个发现来得不算晚。

最后再分享一个小技巧：给购物流程做可访问性测试时，不要只盯着“能不能完成下单”这个终极目标。你还要关注用户在下单路上的每一步是不是顺畅。因为只要有一个环节让用户“迟疑一下”，都可能意味着一次流失。把注意力放到每一个细小的操作反馈上，你的购物流程才能真正经受住不同用户群体的考验。