做功能测试时我们习惯对着用例一步步点可一旦切换到可访问性测试尤其是面对一个完整的电子商务购物流程很多人会突然卡住——不知道从哪儿开始也不知道做到什么程度算合格。我这两年参与过几次电商项目的大规模无障碍审计最深的感受是购物流程是最能暴露问题的路径也是最容易让测试方案变得混乱的场景。这篇文章我就以一条完整的购物流程为主线聊聊测试可访问性电子商务站点时真正需要关注哪些环节、用什么工具、怎么做人工验证以及最常见的坑。在往下走之前先说清楚这篇文章不是讲“怎么把网站做得好看”而是讲“怎么把一个电商购物流程做得让所有人都能走通”。视觉正常的用户觉得“顺手”的页面对使用键盘导航、屏幕阅读器的用户来说可能是死路。下面这些内容适合正在做Web端测试的测试工程师、前端开发、无障碍负责人也适合想知道“你们到底在测什么”的产品经理。1. 可访问性测试中的购物流程为什么它是不可跳过的验收环节1.1 购物流程的完整链路一个标准电商购物流程通常包含这样几个节点访问首页或活动页、搜索或浏览商品、查看商品详情、加入购物车、查看购物车并修改数量、填写收货地址和发票信息、选择支付方式并完成支付、查看订单结果。这一路下来每一步都涉及不同的交互组件图片链接、商品卡片、价格标签、数量选择器、下拉菜单、单选按钮、文本输入框、弹窗、倒计时、自动推荐、结算按钮、支付网关跳转等等。可访问性测试不应该是抽样点几个页面而是要把这条核心链路完整走一遍。我见过不少团队只测了首页和商品详情页结果在购物车和结算环节被用户投诉“无法完成购买”。因为购物车里的数量调整、删除、优惠券输入和结算表单恰恰是键盘操作和读屏器最容易出问题的区域。所以第一条经验就是把购物流程当成一个不可拆分的整体来测而不是割裂地测页面。1.2 功能测试与可访问性测试的差异功能测试问的是“这个功能能不能用”可访问性测试问的是“这个功能对所有人都能一样用吗”。举个例子一个加入购物车的按钮功能测试只要确认点击后商品进入购物车就行但可访问性测试还要确认键盘用户能不能聚焦到这个按钮按回车能不能触发屏幕阅读器读出来的按钮名称是什么焦点会不会在触发后被丢到奇怪的地方整个过程中有没有给用户足够的反馈这就意味着测试思路要变。如果只靠自动化工具跑一轮能扫出很多对比度和缺失标题的问题但扫不出“读屏器用户能不能完成支付”这种真实使用问题。所以购物流程的可访问性测试必须是“自动扫描 手动键盘测试 读屏器走查 真实操作验证”的组合四层都过了一遍才算真正覆盖。1.3 用WCAG标准拆解购物流程WCAG 2.1是我们常用的参考基准它分四个原则可感知、可操作、可理解、健壮性。放到购物流程里这四个原则会落到非常具体的验收点上。可感知商品图片有替代文本视频有字幕价格和促销信息与背景对比度足够不要只用颜色表示“已售罄”。可操作所有交互可以键盘操作焦点可见交互区域足够大没有超时导致突然丢失购物车。可理解表单标签和错误提示文字清晰按钮文字说明动作付款金额和账户信息容易识别。健壮性使用合理的HTML语义和ARIA读屏器能正确解读组件状态在不同浏览器和辅助技术组合下不会崩。我会在后面的章节里把这些验收点一一落到测试动作上。这里先提一句不要试图在一个阶段做完所有标准检查最好的做法是按照用户旅程拆成小任务逐个任务去套标准。2. 测试环境与工具链准备没有合适的“患者”测试就是白做2.1 搭建电商测试站点Demo和真实环境的取舍如果你手头没有现成的电商项目不建议直接用公开网上乱抓的页面来练手状态不稳定还没有测试数据。更好的选择是搭一个可控的demo站点。我自己常用的是一个React HackerShop风格的演示商城几类典型页面都有商品列表、详情、购物车、结算表单、订单确认。如果没有类似环境也可以用浏览器打开一个主流的开源商城Demo比如Saleor Storefront或Medusa的前端示例配合mock数据即可。真实项目测试时重点要放在预发布环境但在预发布环境里要注意支付网关是否被mock、用户数据是否干净、优惠券和配送逻辑是否可复现。我之前遇到过一次测试时支付接口返回了随机错误导致读屏器走查时页面连续报错误以为是无障碍缺陷排查了半天才发现是环境问题。2.2 准备测试账号、商品和订单状态准备数据是很多人忽略的一步。购物流程涉及多个登录态和订单状态至少要准备一个正常登录账号可以走完整购买最好带默认地址一个新注册账号用来测试首次登录、地址填写、错误校验一个“没有地址”的账号用来测试结算时地址缺失的提示情况一个库存紧张或已售罄的商品用来测试售罄状态的可访问性表达一个可以应用优惠券的订单用来测试折扣输入区域一个已经下单但未支付的订单用来测试“继续支付”流程。把这些数据跑一遍后你会发现很多问题其实跟页面样式无关而是和业务状态相关。比如“库存不足”的提示如果没有关联到商品数量输入框读屏器用户就不知道到底哪个商品出了问题。2.3 工具全景键盘、读屏器、自动化扫描和颜色校验我常用的工具组合比较固定没必要追求工具多关键是知道在什么场景下用哪把刀工具用途什么时候用键盘Tab / ShiftTab / Enter / 方向键验证焦点顺序和可操作性每一步都要做NVDAWindows Firefox/Chrome读屏器走查手动验证信息语义macOS VoiceOverSafari/Chrome读屏器走查苹果用户交叉验证axe Browser Extension自动扫描WCAG违规每个页面快扫Lighthouse Accessibility审计自动扫描与性能结合整站评分WAVE工具可视化颜色对比度与结构问题辅助排查Stark / Contrast Checker手动颜色对比度计算设计验收一个提醒读屏器的表现差异很大同一个页面在NVDA下读得好在VoiceOver下可能完全乱掉。如果团队资源允许至少要在Windows和macOS各测一遍核心购物流程。没有条件的也要在NVDA Chrome和VoiceOver Safari这两个主流组合里选一个主测、一个抽查。3. 手动测试的第一关全程键盘导航不碰鼠标能不能买下商品3.1 焦点管理Tab顺序和可见焦点的检验方法键盘测试是整个可访问性测试的骨架。我不建议上来就开屏幕阅读器因为阅读器会把复杂问题混在一起反而难定位。先只用键盘把购物流程当成“盲走”来测。具体做法从首页开始连续按Tab键进入页面元素观察焦点是否按照视觉顺序移动是不是跳进了一个不可见的漂浮层按下回车/空格后能不能触发交互以及焦点是不是落到了毫无意义的地方。购物车是一个重点区域。我几乎每次都能在这类页面上发现两个问题一种是修改数量后焦点丢回页面顶部用户必须重新Tab一遍才能到达更新按钮另一种是“删除商品”的按钮没有可访问名称读屏器会念出一串像“button”或空的内容。正确的做法是删除按钮上要有类似“删除商品黑色运动鞋”的文本或aria-label并且删除操作完成后焦点应该落到下一个商品的名称上或者落到一个“商品已删除”的提示区域。这一轮键盘测试可以通过浏览器开发者工具观察焦点位置或直接在页面里录屏。录屏时我会把系统鼠标指针隐藏避免下意识依赖视觉这样能更真实地模拟键盘用户的操作习惯。3.2 弹窗、下拉菜单、自动补全的键盘陷阱购物流程里弹窗简直是无障碍重灾地。最常见的是“收藏失败”“优惠券码无效”或者“确认删除”这类弹窗触发后焦点仍然留在背景页面上键盘用户要么根本不知道弹窗出现了要么Tab会直接跑到弹窗后面的背景元素里。一个合格的弹窗在设计上应当满足打开后焦点移入弹窗、弹窗内Tab键顺序循环、关闭后焦点回到触发它的按钮。下拉菜单和自动补全也有类似问题。在填写收货地址时很多页面会用“省市区”三级联动下拉菜单键盘用户以为Tab聚焦到了选项结果方向键没有作用自动补全输入框会实时显示候选项但读屏器不知道这个动态列表出现了也没有任何语音提示。对于这类组件标准做法是每个下拉菜单都要用键盘方向键可以选择同时要有aria-expanded状态和列表关联测试时需要逐一确认状态变化。3.3 实操记录模板一页纸梳理购物流程键盘问题为了让测试结果可复用我习惯用一个简单的表格来记录每一步的操作结果。下面是一个我常用的记录模板你可以直接照搬步骤操作预期行为实际结果是否通过首页搜索框Tab进入输入框有可见焦点框焦点跳到了推荐区块否搜索结果商品卡片Tab移动到“加入购物车”按钮读屏名等于“加入购物车商品名”只听到“加入购物车”否详情页数量选择器方向键调整数量数值变化并播报当前值无法用方向键操作否结算表单姓名输入Tab从上一项移入焦点高亮并显示标签焦点没有样式变化否结算“提交订单”回车提交空表单错误提示关联到字段并说明原因在页面底部出现提示焦点未移动否购物车删除第一项回车删除焦点移到第二项提示“已删除”焦点回到页面顶部否支付成功页检查标题和主要内容标题为“订单支付成功”标题为空白否这张表既是测试记录也是写bug报告的基础。提交问题的时候我通常会附带键盘操作录屏和实际播放的内容开发者定位起来速度会快很多。4. 屏幕阅读器实测从商品列表到支付成功的听感检查4.1 读屏器选型与环境设置屏幕阅读器测试是购物流程可访问性测试中最有价值、也最容易被做砸的部分。做砸的原因通常是测试人员一边看页面一边让读屏器朗读最后什么都读不出来。正确做法是简化操作多听少看记录下听到的内容。Windows上我推荐NVDA免费且使用人群大。macOS就用内置的VoiceOver。为了减少干扰测试时建议关掉读屏器的“显示视觉焦点高亮”功能不要盯着屏幕看浏览器又显示什么强迫自己的耳朵去理解页面信息。NVDA下测试购物流程优先用FirefoxChrome虽然也能用但某些历史版本的Chrome对动态内容的播报会慢半拍。VoiceOver则建议用Safari。不同读屏器在不同浏览器上的表现差异本身也是可访问性测试的一部分。4.2 从商品列表到加入购物车读屏器下需要听到什么读屏器不会像视觉用户那样“看一眼就知道”它会把页面元素按顺序朗读。在商品列表页我需要听到这样的信息每个商品卡片有明确的标题例如“无线降噪耳机价格999元618大促价899元还剩3件”“加入购物车”按钮的可访问名称包含商品名或明确的动作描述商品的折扣信息不会在普通用户有视觉提示的情况下被漏读轮播图里的促销内容不是被一股脑连读出来。实际测试中我发现商品卡片是最容易读得混乱的地方。原因往往是开发者用了太多浮层和定位布局导致读屏器朗读顺序与视觉顺序不一致。比如视觉上先看到图片再到标题再到价格但读屏器会先读收藏按钮再读链接最后才读商品标题。这种序顺问题很容易通过屏幕阅读器走查发现。从商品详情页加入购物车时还需要验证“加入后”的反馈。正确做法是在加入购物车后页面宣布“商品已加入购物车购物车中共有3件商品”并且把焦点移动到购物车图标或消息区域。有些网站用的是角落里浮出小卡片键盘和读屏器用户完全察觉不到这就是典型的失败。4.3 动态内容播报加入购物车提示、购物车数量与错误提示动态内容是屏幕阅读器测试的重点。购物流程中几乎所有交互都需要实时反馈加入购物车后数量变化、优惠券验证结果、库存变化、支付错误提示。这些反馈需要用到aria-live区域或者通过rolestatus来播报。测试时我通常会连续做三次操作来验证动态播报第一次正常加入购物车听是否有“已加入”的提示。 第二次连续点击两次加入购物车同款商品听数量变化是否被播报。 第三次在购物车页面减少商品数量到1再把数量改为0或超出库存听错误信息是否准确。动态播报还要注意播报时机和打断问题。如果一个话题还没播完就被另一个动态提示打断用户会觉得很混乱。尤其是结算时优惠码验证的loading状态和“请输入正确优惠码”的错误提示必须等用户提交动作完成后才播报而不是在页面加载时就默认全部讲一遍。4.4 需要人与工具配合的验证只听不看能完成支付吗读屏器走查到最后我会做一次“端到端盲操”戴上耳机、关闭屏幕从商品列表选一件商品加入购物车进入结算填写所有字段完成支付。全程只听读屏器播报依靠键盘完成所有动作。如果过程中因为缺少提示、按钮不可操作、焦点丢失而卡住就能真实还原残障用户遇到的困难。我在一次项目中做过这样的盲操测试结果卡在了支付页面。页面有一个“同意用户协议”的单选框读屏器也能读到标签但键盘用户永远无法勾选因为真正的input元素被透明层覆盖了鼠标可以点但键盘焦点根本不上去。这种问题在自动化扫描里基本扫不出来只有真人走查才能发现。5. 自动化扫描实战用axe和Lighthouse把人工验证撑大5.1 在浏览器里快速跑一轮axe检查自动化扫描没法替代人工但能把人工从重复劳动里解放出来。我每次做完手动键盘和读屏器测试后都会再用axe对整个购物流程页面扫一遍用来发现遗漏的对比度问题、缺失的标题、不规范的表单标签等基础问题。具体做法有两种。一种是直接用axe DevTools浏览器扩展打开页面后点击“Scan ALL violations”会列出所有违规项、影响级别和DOM节点。另一种是通过自动化脚本注入axe适合需要批量跑多个页面。下面是一个最简脚本示例适合配合Selenium或Playwright使用const { chromium } require(playwright); const axe require(axe-core/playwright); (async () { const browser await chromium.launch(); const page await browser.newPage(); await page.goto(https://your-ec-site.example); const results await new AxeBuilder({ page }).analyze(); results.violations.forEach(v { console.log([${v.impact}] ${v.id}: ${v.description}); }); await browser.close(); })();使用这类脚本时如果扫到颜色对比度大量失败不要急着改页面。先看完整扫描结果因为颜色对比度会受按钮disabled、hover状态影响需要区分真实用户遇到的情况和页面刚加载时的默认状态。5.2 Lighthouse在商品页、购物车和结算页的评分解读Lighthouse内置的无障碍审计是快速批量化页面的好帮手。它会在“Accessibility”面板给出0到100的分值并列出需要人工复查的通过项和失败项。以购物流程为例我会重点关注几个Lighthouse能扫出的点图片有没有alt属性alt为空是否合理表单控件的label是否存在页面是否有唯一的h1页面标题是否描述当前场景链接有没有可读文本元素对比度是否达到AA标准aria-hidden元素是否还包含可聚焦元素。但Lighthouse的分数只是参考不同路由下分数波动很正常。比如商品详情页图片少、信息集中通常分数会比购物车高购物车页面有一堆图标按钮和商品缩略图很容易掉分。不要只盯着总分要逐个看失败项并对应到购物流程的那一个具体步骤。5.3 自动化能扫出来的问题与扫不出来的问题这个区别如果不说清楚团队很容易被一份自动扫描报告带偏。自动化扫描能稳定发现的问题主要是“静态规则”问题缺alt、缺label、对比度不足、结构层级错误、ARIA属性写错等。这类问题很容易修也适合做回归拦截。但自动扫描扫不出来的包括焦点顺序是否符合人类直觉屏幕阅读器朗读顺序是否和视觉一致键盘操作后焦点是否丢失动态内容播报是否及时弹窗和下拉菜单是否真的能键盘操作到底用户的紧张情绪和困惑程度。所以在提交测试结论时我通常会把自动化扫描结果作为“已知清单”把人工测试结果作为“验收结论”。人工测试里发现的任何键盘和读屏器问题都要逐字写清楚复现步骤不要只丢一个axe警告列表给开发。5.4 在CI流程里布置可访问性回归测试如果你的团队已经有自动化测试平台比如基于Playwright或Selenium的回归体系完全可以把axe扫描嵌入进去。最简单的方式是每次核心购物流程回归跑完在关键页面执行一次axe分析失败数超过阈值就让流水线告警。这样至少能防止“再开发一个版本后又把图片alt删了”这类问题。我在项目中踩过一次坑直接在构建脚本里跑Lighthouse把所有低于90分的构建都拦下来结果发现很多缓慢的第三方广告内容会影响性能却没有真实反映页面可访问性水平。后来我改成在发布前的测试环境里对固定的一组商用SKU页面跑axe和Lighthouse并人工审查扫描结果而不是只看一个总分。6. 购物流程里总在反复出现的可访问性问题与修复思路6.1 商品图alt文本、链接文本和可访问名称商品图片的alt文本不是“放一句话就完事”。缩略图、商品主图、带有价格的促销图的处理方式各不相同。我见过一个严重问题商品主图和“加入购物车”按钮是两个相邻的元素读屏器读完图片描述后直接跳到另一个无关区块用户完全不知道这个商品是什么。正确的alt文本应当描述商品关键信息按钮的可访问名称也要包含商品名和动作。举个修复前后的例子!-- 不合规按钮只叫“加入购物车” -- button加入购物车/button !-- 合规可访问名称明确指向当前商品 -- button aria-label加入购物车无线降噪耳机H800加入购物车/button这里的关键不光是加一个aria-label而是让读屏器用户听到足够的信息来做决策。网店商品成百上千只听到“加入购物车”不知道是哪件商品等于没听到。6.2 价格与促销标签的对比度购物流程里价格是用户最关心的内容但电商页面特别喜欢用浅色小字表示原价和折扣价尤其是“¥299”加“划线价 ¥499”这种组合。颜色对比度不足会让低视力用户和色弱用户很难分辨价格。用计算对比度的工具比如Stark或axe内置的对比度检查将价格文字和背景颜色一起检查。要注意促销标签的hover态和选中态有些促销标签平时对比度合格鼠标悬停时变成浅色背景白字就完全看不清了。6.3 表单标签和错误提示占位符永远不够结算页是表单问题集中地。常见的错误写法是只给input加placeholder属性而不加label标签。视觉用户可以看懂占位符写的“请输入姓名”但读屏器用户听不到这个信息就算能听到在开始输入后文本也会消失用户就会忘记自己要在哪个框里输入什么。至少要做到label forname收货人姓名/label input typetext idname namename required错误提示也不要简单地用“error”字段抽象表达。如果用户没有填写姓名错误提示应当同时说明“这里是必填项”和“该字段是收货人姓名”。比如“请填写收货人姓名”不能只输出“请输入正确的格式”而不告诉用户是哪个字段。在测试时我还会清空一次所有字段直接提交再看一遍所有错误信息是否被读屏器依次读出。6.4 轮播图、无限滚动和购物车弹窗的ARIA误用ARIA用得好是帮助用错了比没有更糟。电商首页几乎都有轮播图有些开发者给轮播图的所有图片都加上aria-label和tabindex0导致键盘Tab在同一个轮播图上要按十几下才能离开。正确的做法是轮播图本身作为一个可操作组件通常只需要一个区域按钮组如果轮播内容不是核心信息可以用aria-hidden隐藏装饰性图片让用户快速跳过。无限滚动也是购物流程中的大坑。商品列表页越往下滚自动加载越多商品如果新增内容没有插入到正确DOM位置读屏器焦点可能会悬空当用户采用键盘导航时发现按Tab到了页底却没有新的焦点无法加载后面的商品。这时候一般要给“加载更多”按钮提供一个可聚焦入口并配合aria-live播报“已加载更多商品”或给予明确的“加载中”状态。购物车弹窗我已经在上文提到过一次但是ARIA的误用会在弹窗里放大。比如用roledialog但漏写aria-modal会让读屏器用户仍然访问后台元素关闭按钮用aria-label写“关闭”但导致读屏器用户以为会关闭整个网页而非关闭弹窗。这类细节在人工走查中几乎都能发现自动化规则很难抓到。6.5 我在项目里最后会做的一次“真人验收”自动化扫描、键盘导航、读屏器走查都做完之后我会跳出测试用例本再做一次自由摸索式的真人验收。不是按固定顺序操作而是把自己当成一个“行动不便的普通用户”可能不用标准Tab键而是用屏幕键盘逐字母输入可能不进入商品详情页而直接在推荐位点击加入购物车可能因为手抖误触了删除按钮。这种不按套路出牌的操作经常能发现流程里的边缘问题。有一次就是在自由验收时发现地址簿里的“设为默认地址”单选按钮选中后没有状态变化读屏器也不会播报“已选中”导致用户反复点击也以为没有生效。修复后加了一个aria-checked状态整个购物流程才真正算是闭环。这也正是我在可访问性测试里学到的最重要一件事不要把测试当做一个“找漏洞”的任务而要把它理解成一次对用户信任感的检查。购物流程中的任何一个小障碍都可能让一个本可以顺利成交的用户转身离开。把这些障碍找出来才是这篇文章真正想让大家带走的经验。