先沿真实购物任务找障碍

“网站要照顾所有人”听起来正确，却不足以指导修改。电商团队更容易落地的起点，是挑一个真实任务，从入口开始走一遍：搜索一款指定型号、比较两个规格、加购物车、修改数量、填写收货信息，最后确认订单。记录每一步用户要看什么、选择什么、页面给出什么反馈。可访问性检查不是另开一条抽象设计线，而是验证这些常见任务是否能被不同感官、输入方式和设备设置下的人理解并完成。

先把用户需求写成可观察的条件，不假定某个群体只有一种使用方式。低视力用户可能放大文字或调整对比；盲人可能通过屏幕阅读器听取标题、控件和状态；手部活动受限的用户可能使用键盘、开关或语音操作；有阅读或注意力困难的人，可能需要短句、明确步骤和可预期反馈。年龄、障碍和技术经验都不是统一标签。最好邀请有不同使用经验的人参与测试，并征得同意；团队内部模拟只能发现一部分问题，不能代替真实用户反馈。

先选一个优先旅程，再约定完成标准。例如参与者应能找到商品、选中合适规格、看清价格和库存状态、理解配送条件，并在确认前知道操作会造成什么结果。测试人只读，不教用户“正确路径”；发生停顿时记录页面给出的线索，而不是把失败归因于个人。这样取得的是一条可复查的体验证据，不是笼统的“用户不方便”。

不只看颜色：文字、放大和窄屏布局

商品页与结算页常用颜色标出库存、促销、必填项和错误。如果红色缺货提示是唯一信号，不能辨认颜色差异的人可能只看到一个变色标签。把文字状态、图标含义或位置提示一起给出，再用灰度或模拟不同色觉的方式复核。关键说明也尽量不要烘焙进商品图片；图像无法被放大和朗读时，价格、规格或使用条件就可能漏掉。商品图应有与任务相关的文字替代说明，纯装饰图则不必重复商品名。

让页面在浏览器文字放大或窄视口下仍可操作。实际检查时逐步放大字体和页面，留意规格选择器、价格、优惠说明、数量控件、购物车浮层和固定底栏是否遮挡或互相覆盖；按钮文本有没有被裁掉；焦点或错误提示是否跑出视野。WCAG 的 reflow 检查可作为技术参考：大多数纵向阅读内容在等效 320 CSS 像素宽的视口下应能呈现，不丢失信息和功能，也不要求用户同时水平、垂直滚动；地图、复杂表格等确实需要二维布局的内容另有例外。将这一条当作测试锚点，不等于对整站作出合规认证。

文字对比度可以用自动工具做初筛，关键组件还要人工看状态和背景。WCAG 2.2 的普通文本对比度标准通常为至少 4.5:1，大字至少 3:1，并有特定例外。数字达标也不保证整个界面易读：字体过细、行距过紧、促销文字贴在复杂图片上，仍可能让信息难以识别。把商品名、当前选择、原价与实付价等内容放在清晰背景上，避免只靠颜色或装饰表达重要差别。W3C：WCAG 2.2 对比度说明 W3C：重排与窄屏呈现说明

让键盘和辅助技术能找到并操作控件

团队可以先暂时收起鼠标，用键盘完成整个旅程：从导航进入搜索框，提交关键词，筛选商品，选择规格，修改数量，进入购物车，再走到结算确认。观察焦点是否始终可见、顺序是否符合页面阅读逻辑、弹出层打开后焦点是否进入其中并在关闭后回到合理位置。若键盘走到一个控件后无法离开，或焦点被固定促销条遮住，任务便会中断。自定义下拉框、颜色圆点、数量加减器和弹窗尤其值得逐项检查。

屏幕阅读器测试不只问“页面有没有朗读”。听商品名称、价格、促销条件和规格控件的名称是否足以分辨；选中规格后，状态有没有变化反馈；购物车数量更新、表单错误、订单提交结果是否被适时告知。图标按钮需有可理解的名称，例如只显示放大镜时，应能听出它用于搜索。标题层级、列表和区域地标也应帮助用户跳到想去的位置。自动扫描器可以提示缺少标签或语义属性，但无法判断某个标签说得是否准确，也无法判断流程是否令人困惑。

把表单和支付前确认作为重点

结算通常是连续表单，微小问题可能迫使用户重新输入。姓名、电话、地址、发票和配送时段等每个输入项，都应有一直可识别的文字标签；只把“请输入手机号”放在占位符里，用户开始输入后提示便消失，辅助技术也可能无法据此识别字段。必填与选填规则、可接受的格式和用途，在填写之前说清楚。能够从地址簿选择时，也保留清楚的手动输入路径，避免只支持拖动地图或复杂手势。

错误发生后，把错误写成具体、可修复的提示，指出哪一项以及如何改；不要只把边框变红或显示“提交失败”。将提示与对应控件关联，并让焦点或页面位置便于找到错误。信息校验要保留用户已填内容；银行卡、验证码或配送信息输入错时，不应无故清空整张表。验证码和倒计时还需考虑视力、记忆、手部操作和切换辅助工具所需时间，提供可理解的重新获取方法，并避免把额外的视觉谜题当作唯一验证方式。

在最后确认之前，逐项复述商品、规格、件数、优惠、运费、配送地址、预计安排与应付总额。让用户有机会修改，而不是一个含糊的“继续”按钮就触发付款。完成后给出明确状态：订单已提交、支付待确认、支付失败或需要联系渠道，不能用相同的“成功”提示覆盖不同结果。支付渠道可能有自己的页面或验证流程，商户要实际检查跳转、返回、超时和辅助技术反馈；不要只靠商城内部一个静态截图判断完整支付体验。W3C 的表单教程介绍了表单控件标签、输入说明和错误通知，可作为研发验收时的参考。W3C WAI：表单可访问性教程

建立覆盖设备与旅程的验收表

可以用一张轻量表格记录每项检查：页面和任务、设备与视口、输入方式、辅助技术、观察事实、影响步骤、严重程度、复现条件、负责人、修正版本和复测结论。例如：“窄屏商品页，文字放大后固定优惠条遮住规格数量；无法确认当前件数；修正底栏布局；相同设备复测可读且可操作。”这类记录能让设计、前端、商品运营和客服讨论同一件事，也比“适配老人需求”更容易转成修复项。

覆盖面可以按风险安排。先查搜索、商品详情、规格选择、购物车和付款确认等高频且涉及金额的步骤，再检查注册、优惠券、客服入口、订单查询和退款表单。每个关键路径至少用触摸操作完成一次，使用键盘走一次，并选用团队实际支持的屏幕阅读器做有针对性的人工验证。测试不同屏幕尺寸、横竖屏、系统字体放大和常见浏览器；若支付在第三方页面继续，还要把跳转和返回列入范围。版本更新、活动皮肤、模板更换或组件升级后重新跑关键路径，尤其要检查折扣样式和弹窗对焦点及文字缩放的影响。

验收时将工具检查、专家检查和参与者任务观察分开记录。扫描器发现的问题可快速定位，但“零问题”报告不是可访问性保证；少数参与者发现的问题也不自动等于所有顾客都有同样体验。通过清楚记录环境、步骤和局限，团队能决定先修哪些阻断购买、哪些影响理解，哪些需要更广泛验证。对外避免宣称“完全无障碍”或“全部符合标准”，除非对范围、标准版本、评估方法和证据有正式支撑。

先修阻断任务的问题，再做视觉微调

问题排队时，可按“是否阻断任务、是否影响金额或重要决定、出现范围、是否有可行替代路径”记录，而不是只按视觉严重程度排序。比如用户无法选中规格、读不到应付金额或错误后无法修改，通常先处理；一个装饰图缺少描述但不影响商品判断，也许需要补充替代文字，却不应与支付流程被遮挡混作同一级别。每个问题附一个最短复现步骤、预期结果和实际结果，设计与研发能更快确认它是文案、结构、控件、浏览器还是第三方页面的问题。

修复后用相同设备、相同设置和相同任务复测，避免只检查新截图而没有重走流程。再做一次相邻路径回归：修规格按钮时也检查购物车总价与当前选择；改结算表单时检查错误提示、返回路径和订单确认。若问题只能在特定系统字体、读屏版本或支付渠道环境复现，把已测环境写清楚并保留未测范围。这样不会把一次局部通过夸大成全站可访问，也能让后续版本知道哪些回归项不能漏。

把设计检查与经营资料衔接起来

可访问性修复会触及商品信息、库存状态、优惠条件和顾客沟通，产品、运营与技术要共同确认页面展示的业务事实。企雀公开电商产品介绍提及顾客管理、进销存管理和数据分析，可作为了解电商经营资料的入口；这些公开介绍本身不能证明具体页面组件、辅助技术支持或WCAG合规，也不能替代前端和支付渠道的实际测试。涉及企雀产品的具体部署、套餐与使用方式，需要再按实际配置核实。企雀电商产品公开介绍

完成一轮验收后，把已修问题、尚未解决障碍和复测范围留在版本记录中。页面后来增加新的规格、浮层促销或地址字段时，按任务影响回归测试。这样积累的不是一张“无障碍认证”标签，而是可复核的购物路径：用户在哪一步需要什么信息，页面是否允许他用熟悉的方式完成操作，以及商家是否把价格、库存和提交结果讲清楚。