1. 重新理解可访问性测试中的用户画像我一直觉得，可访问性测试里最容易被低估、也最容易被做坏的环节，就是用户画像。很多团队做可访问性测试，上来就铺自动化扫描工具，跑一轮 Axe、Lighthouse，把报错列表贴给开发，就算交差了。这种打法不是没用，但离真正的可访问性测试差得很远。我之前参与过一个某B端管理后台的改造项目，产品经理拉了一个用户画像文档，里面写了三类角色：财务审核员、仓库管理员、系统运维。看着挺像那么回事，但你把文档翻到底，会发现所有画像里没有任何一个提到“这位用户是否使用屏幕阅读器”、“他是否有运动障碍导致难以精确操作鼠标”、“他是否在弱光环境下使用高对比度模式”。这就是典型的传统用户画像和可访问性测试“两张皮”——画像画的是业务角色，不是使用障碍维度的用户。1.1 传统用户画像在可访问性场景下的三大盲区第一，它默认用户是“完整的、标准的、无差异的”。传统画像会写年龄、岗位、使用频率、核心任务，但很少描述视觉能力、听觉能力、操作能力、认知能力上的差异。可现实是，真实用户里很大比例存在不同程度的障碍，而且这些障碍不一定是先天性的，更多是情境性的：抱着孩子单手操作手机的家长、在嘈杂环境里听不清提示音的运维工程师、刚做完眼科手术暂时看不清屏幕的财务人员。这些都属于可访问性用户画像需要覆盖的范畴，传统画像完全不接这个轨。第二，它只会描述“用户想干什么”，不会描述“用户能怎么干”。可访问性测试关心的是交互路径本身——用户是通过键盘Tab键逐个跳转来导航，还是通过屏幕阅读器直接从标题列表跳转，还是通过语音识别软件把语音转成鼠标点击指令？同样一个“提交报销单”任务，不同障碍类型的用户走的是完全不同的操作路径。传统画像不记录这些，导致测试人员设计用例时只会用常规鼠标点击路径去验证，结果测出来一片绿灯，真实用户一用就卡死。第三，它没有与辅助技术建立映射关系。可访问性测试的最终落脚点是让产品与辅助技术兼容。辅助技术五花八门，屏幕阅读器有 NVDA、JAWS、VoiceOver、TalkBack，放大软件有 ZoomText，替代输入设备有开关控制器、眼动仪、头控鼠标。传统画像不关心用户用哪类辅助技术、用什么版本、在什么操作系统上跑，而这些恰恰是可访问性测试最关键的组合参数。没有这些信息，你连测试环境都搭不对。1.2 画像在测试链路中的正确位置我踩过几次坑之后，越来越倾向于把可访问性用户画像放在整条测试链路的最前端。它不是一个后续补充文档，而是决定测试范围、测试环境、用例设计、结果优先级排序的源头输入。你画出来的画像越贴近真实场景，后面的自动化扫描、手动走查、真实用户测试就越有靶子可打。打个比方，用户画像之于可访问性测试，相当于剧本之于电影拍摄。你不先把人物设定清楚，摄影师、灯光师、演员全凭感觉来，出来的片子大概率是散的。可访问性测试里的“人物设定”，就是用户画像。它至少要为后续三个环节提供输入：一是自动化测试中需要覆盖的辅助技术组合，二是手动测试中需要模拟的操作路径，三是埋点监控中需要关注的关键行为指标。所以我坚持认为，可访问性测试项目启动的第一件事，不是选工具，而是把用户画像做扎实。2. 构建可访问性用户画像的核心维度与方法以前我们画画像，主要靠访谈和问卷，但是对可访问性来说，这个远远不够。你不能只问用户“你平时用什么设备”，你得知道他在真实环境下如何与数字产品交互。我用了几年时间慢慢打磨出一套自己的画像体系，这里直接分享出来。2.1 画像的五大信息块我把可访问性用户画像拆成五个信息块，每一块缺了，后面的测试设计都会漏洞。第一块是个人基本信息，注意不是年龄、性别这些人口学指标，而是会影响数字交互的关键信息：年龄范围用来判断视力和操作能力的自然衰退程度，职业和日常任务用来理解上下文场景，数字产品使用经验用来区分新手和熟练用户对界面反馈的需求差异。第二块是障碍类型与程度描述。这一块我建议按照功能受限维度来划分，而不是按照医学诊断分类。功能受限维度包括视觉、听觉、操作、言语、认知、对光敏感等。比如“完全失明”和“低视力”虽然都属于视觉障碍，但对测试的要求差异非常大，前者依赖屏幕阅读器，后者依赖放大软件和高对比度支持。描述障碍程度时，尽量用可操作的语言：是否依赖辅助技术、依赖哪些、使用频率如何。第三块是辅助技术使用详情。这块是画像的技术内核，具体要记录：主要使用的辅助技术类型，比如屏幕阅读器、屏幕放大器、语音输入、替代鼠标等；具体软件名称和版本，比如 NVDA 2024.2、JAWS 2023；搭配的操作系统和浏览器，比如 Windows 11 + Chrome、macOS + Safari；辅助技术的自定义配置，比如语音速率、颜色方案、字体大小。这些信息直接决定你的测试环境矩阵长什么样。第四块是典型使用场景与任务。写清楚用户通常在什么环境下使用产品：是安静的办公室、嘈杂的公共区域，还是光线不稳定的户外？主要完成哪些核心任务？这些任务的频率和紧急程度如何？我见过一个团队把“无障碍通道”设计得很完善，但实际用户多是在嘈杂环境下用语音输入操作，结果语音指令反馈被环境音干扰，基本不可用。这就是场景没画到位。第五块是痛点和挫败点。这一块是画像里最有血的肉的部分。用户在用同类产品时遇到的最大障碍是什么？哪些操作会让他完全卡住？哪些反馈方式会让他迷茫？这些信息在做测试用例设计时是金矿，直接可以转成回归测试的重点项。2.2 画像构建的具体步骤实际操作中，我通常按四步来构建画像。第一步，数据收集，打出组合拳。不仅仅是做访谈，还要做实际观察。访谈容易把用户说的和用户实际做的混为一谈，很多用户自己也不太清楚自己怎么操作的，你问他他可能就说“我就点点点”，但你在旁边看他操作，你会发现他是通过语音识别加键盘快捷键混合操作的。所以有条件的话，一定安排用户在自己的真实设备上完成几个任务，你在旁边记录操作路径。另一个容易被忽略的数据来源是客服工单和用户反馈评论，这些地方藏着大量真实痛点的口语化描述，比如“那个下拉框我根本选不了”、“字太小看不清，只能放大到300%”。把这些原始描述收集起来，比问卷答案有价值得多。第二步，归纳聚类，按功能受限维度分组。把收集到的信息按照视觉、听觉、操作、认知等功能维度归组，注意不要简单按诊断归组。诊断相同不代表交互障碍相同，两位同为低视力的用户，一位习惯放大软件配和高对比度，另一位依赖系统的“深色模式”，测试需求就不一样。归组之后看看每一组的行为模式有没有一致性，有的一致性的组就可以凝聚成一个画像角色。第三步，画像描述，格式要标准化。我给团队建过一个模板，每个画像角色固定包含：角色名称，比如“键盘操作用户李先生”；一句话简介；功能受限描述；辅助技术栈；典型任务；用户目标；痛点场景。标准化格式的好处是，开发、测试、产品各方能快速找到自己关心的信息，而不是在一大段描述文字里翻找。第四步，评审与验证。画像建完不能直接扔给测试组，要组织评审。至少要有三类人参与：产品经理确认业务任务是否覆盖完整，开发确认技术配置是否可实现，测试确认画像对应的测试场景是否可执行。评审通过之后再作为基线存档，后续每次测试迭代前检查画像是否需要更新。2.3 画像的精度控制：该细分到什么程度这里要泼一盆冷水：画像不是越细分越好的。见过有些团队把画像画了十几种障碍类型排列组合，看着很周全，实际执行起来测试用例爆炸，根本跑不完。我的经验是，画像粒度要与产品形态和测试资源匹配。如果你的产品是一个内部工具，用户群相对固定，画像控制在三到五个角色就够，重点覆盖用户占比最高的前两类障碍，剩下的可以做轻度覆盖。如果是面向公众的消费级产品，用户群极其多样，画像可以做到八个左右，但每个画像必须有明确的数据支撑，不能靠想象硬凑。另外有个判断标准：凡是无法直接映射到一条可执行的测试路径上的画像，都算过度设计。可访问性用户画像的终点不是描述用户，而是告诉测试人员“这条路径需要测什么、用什么方式测、在什么环境里测”。如果你的画像角色画得花团锦簇，但测试人员看完不知道接下来该干什么，这个画像就是废纸。3. 从画像到测试用例的落地执行画像建好了，接下来才是硬仗——怎么把画像里的信息真正转成可执行的测试用例。这一步做不好，画像就又变成了抽屉里的文档。3.1 画像驱动测试场景设计的两种方法我常用的第一种方法是任务路径法。每个画像角色都有典型任务，我把每个任务拆成一条完整操作路径，路径上的每个节点就是一个测试点。举个例子，某个角色的画像描述是“低视力用户，使用 Windows 系统下的放大软件，主要任务是从列表中找到指定订单并提交审核”。这条任务的路径可以拆成：登录系统 → 导航到订单列表 → 定位到指定订单 → 点击进入订单详情 → 核对信息 → 点击审核按钮。测试用例就以这条路径为基线，分别考察放大软件下的界面可用性、文本可读性、颜色对比度、操作命中率、信息定位效率。第二种方法是探索式测试法，适合无法完全枚举路径的场景。基于画像的辅助技术栈，设置一个开放性任务，比如“请通过键盘完成一笔订单的修改”，然后观察实际操作路径，记录卡点。这个方法不需要预先设计所有步骤，但前提是测试人员对辅助技术操作足够熟练，否则你连用户卡在哪都看不出来。3.2 自动化测试工具与画像数据的结合自动化和用户画像不是互斥的，关键在于怎么把画像信息注入自动化测试配置。我在实践中常用的方法是维护一份画像-环境映射表。每一行是一个画像角色，列是操作系统、浏览器、辅助技术、配置参数等。比如：画像角色操作系统浏览器辅助技术关键配置键盘操作用户李先生Windows 11Chrome无开启高对比度主题屏幕阅读器用户王姐Windows 11ChromeNVDA 2024.2语速60%，使用左耳音频输出VoiceOver 用户林同学macOSSafariVoiceOver使用盲文显示器交互模式放大软件用户张工Windows 11EdgeWindows 放大镜缩放比例200%，跟随键盘焦点这张表的价值在于，它让自动化测试工具的配置不再拍脑袋。跑无头浏览器测试时，我会同时设置视口尺寸、颜色方案强制模式、以及必要的 ARIA 模拟，而且会跑两遍：一遍默认状态，一遍强制高对比度模式。对比两份结果差异，你就能发现很多控件在常规视觉下没问题，但高对比度模式下状态指示丢失了。3.3 人工测试环节的画像走查方法自动化工具毕竟只能覆盖技术性合规问题，大量真实体验问题还是得靠人工走查。我推荐一种叫“画像角色走查”的方法。测试人员一个人，按照画像角色的方式操作整个产品。不是你自己平时习惯的鼠标点来点去，而是严格模拟画像的交互方式。如果是键盘用户，就拔掉鼠标，只用 Tab、Shift+Tab、方向键、回车和空格完成所有操作。如果是屏幕阅读器用户，就关掉屏幕，戴上耳机，只听 VoiceOver 或 NVDA 的朗读。如果是放大软件用户，就把屏幕缩放开到200%，配合鼠标或键盘完成操作。这里有一个很关键的技巧：走查过程中必须记录“操作时间”。一个任务，普通鼠标操作两分钟完成，键盘操作十分钟还没走完，这本身就是严重的可访问性问题。很多团队只看“能不能完成”，不看“完成效率”，但真实用户对效率的敏感度极高，一个操作路径拖得太长，用户就会放弃这个产品。所以我在走查笔记里单独列了一栏“路径耗时”，作为与功能通过率同等重要的判断指标。另外，人工走查一定要录音录屏。别只靠脑子记，辅助技术朗读速度快的时候，你根本来不及记录。录屏文件后期回放时可以逐帧分析焦点移动是否合理、朗读顺序是否符合阅读逻辑、操作反馈是否有遗漏。4. 常见问题与排查技巧实录做可访问性测试这几年，我积累了不少实战踩坑经验。这里挑几个最典型的分享出来。4.1 问题一：画像角色和真实用户对不上最尴尬的场面是，画像文档画得一丝不苟，测试也按画像执行完了，但把产品拿给真实用户一测，用户说“我平时根本不是这样用的”。后来我复盘发现，问题出在数据采集环节。之前的画像数据主要来自产品经理的假设和部分问卷，没有经过真实用户的操作验证。比如说我们给某个角色设定的是纯键盘操作，但实际访谈发现，这位用户其实是键盘与鼠标混合操作——能用鼠标指到的地方用鼠标，指不到的就用键盘导航。很多患有关节炎的用户不是完全不用鼠标，而是用得很慢很吃力，他们会自己开发出一套省力的混合工作流。这个问题的解药只有一个：画像必须有真实观察数据做底。如果预算有限做不了大规模用户研究，至少找三到五个真实目标用户，做一两次任务观察，把操作路径录下来，再回来校准画像。宁可用小样本的真实数据，也好过大样本的臆测。4.2 问题二：自动化扫描扫不出动态内容的问题自动化工具对静态页面的可访问性错误识别率挺高，比如缺少 alt 文本、颜色对比度不足、按钮没有可见焦点等。但遇到动态交互内容，自动化工具经常失灵。最常见的是弹窗和下拉菜单：弹窗出现时，焦点没有自动移入弹窗内；弹窗关闭后，焦点没有返回触发按钮。这类问题严重影响键盘用户和屏幕阅读器用户，但自动化工具很难有效覆盖。针对这个问题，我的做法是，把动态交互场景单独列一个问题清单，凡是涉及弹窗、抽屉、下拉菜单、轮播图、自动补全列表的组件，全部必须走人工键盘走查。代码层面可以加一个定制的自动化脚本，用 Playwright 模拟键盘操作触发这些组件，第二部分检查焦点状态。但说实话，这类交互的最终把关，还是要靠人工走查加屏幕阅读器实测。4.3 问题三：团队对可访问性缺陷的优先级分歧测试提了一堆可访问性问题，开发那边觉得“这些又不影响正常人使用”，拒绝修复。这种扯皮我经历过不止一次。后来我改变了汇报方式：把可访问性问题与用户画像关联起来，用用户规模说话。每次提缺陷时，都标注这个缺陷影响了哪几类画像角色，对应的用户场景是什么。比如“导航菜单的焦点顺序错乱，导致键盘操作用户李先生的订单审核任务路径耗时从2分钟拉长到15分钟”，这个陈述方式比“导航菜单缺少正确的焦点管理”有力得多。同时我会在缺陷单里附上一条复现操作路径，让开发自己按这种方式试一遍。说实话，很多开发人员从来没有用键盘操作过自己的产品，你让他模拟一次用户体验，比贴十行说明文档都有效。4.4 问题四：辅助技术组合太多，测试环境维护成本过高屏幕阅读器和操作系统的组合种类繁多，不可能全部覆盖。我的建议是维护一个主流矩阵，并且有一个清晰的取舍逻辑：优先覆盖使用占比最高的前三组合。根据我接触到的数据，Windows 上 NVDA 加 Chrome、macOS 上 VoiceOver 加 Safari、Windows 上 JAWS 加 Chrome 是几个高占比组合。把这个矩阵写进测试计划，明确说明为什么只覆盖这些组合，可以避免后续测试无休止地加组合，导致成本失控。还需要注意辅助技术的版本锁定。辅助技术更新频繁，版本一变，测试结果可能就要重跑一遍。建议在一个测试周期内锁定辅助技术版本，测试报告里写清楚使用的版本号，等到下一个周期再统一升级。这样至少保证测试结果在一个周期内是可比的。5. 一些额外的提醒可访问性用户画像不是一次性工程。产品迭代了、功能新增了、用户群体变了，画像就要跟着更新。我习惯在每个迭代周期结束前做一个快速检查：这轮改动有没有引入新的交互方式？有没有新增高频功能？有没有用户反馈新的操作障碍？如果三个问题里有一个“有”，画像就要调整。另外提醒一件事：画像文档的存储位置和可访问性也要注意。我知道有个团队把画像文档放在一个只有内网可达的共享盘里，外部测试人员根本访问不到，结果每次需要画像信息时，都要靠项目助理人工转发。这看起来是小事，但对测试节奏的拖累非常明显。画像文档应该作为项目知识库的一部分，随项目仓库存放，保证所有参与方随时可以访问。我个人的体会是，可访问性测试中的用户画像真正做扎实了，带来的回报不仅仅是测试更有效率，更在于产品团队所有人的认知转变。当你把“屏幕阅读器用户王姐”当成一个真实存在的角色去讨论需求时，开发写代码时会主动考虑焦点逻辑，交互设计师画稿时会主动思考语义结构，产品经理评审需求时会主动问一句“这个功能键盘用户怎么操作”。这种改变，比测试本身多发现几个 Bug 重要得多。
1. 重新理解可访问性测试中的用户画像我一直觉得，可访问性测试里最容易被低估、也最容易被做坏的环节，就是用户画像。很多团队做可访问性测试，上来就铺自动化扫描工具，跑一轮 Axe、Lighthouse，把报错列表贴给开发，就算交差了。这种打法不是没用，但离真正的可访问性测试差得很远。我之前参与过一个某B端管理后台的改造项目，产品经理拉了一个用户画像文档，里面写了三类角色：财务审核员、仓库管理员、系统运维。看着挺像那么回事，但你把文档翻到底，会发现所有画像里没有任何一个提到“这位用户是否使用屏幕阅读器”、“他是否有运动障碍导致难以精确操作鼠标”、“他是否在弱光环境下使用高对比度模式”。这就是典型的传统用户画像和可访问性测试“两张皮”——画像画的是业务角色，不是使用障碍维度的用户。1.1 传统用户画像在可访问性场景下的三大盲区第一，它默认用户是“完整的、标准的、无差异的”。传统画像会写年龄、岗位、使用频率、核心任务，但很少描述视觉能力、听觉能力、操作能力、认知能力上的差异。可现实是，真实用户里很大比例存在不同程度的障碍，而且这些障碍不一定是先天性的，更多是情境性的：抱着孩子单手操作手机的家长、在嘈杂环境里听不清提示音的运维工程师、刚做完眼科手术暂时看不清屏幕的财务人员。这些都属于可访问性用户画像需要覆盖的范畴，传统画像完全不接这个轨。第二，它只会描述“用户想干什么”，不会描述“用户能怎么干”。可访问性测试关心的是交互路径本身——用户是通过键盘Tab键逐个跳转来导航，还是通过屏幕阅读器直接从标题列表跳转，还是通过语音识别软件把语音转成鼠标点击指令？同样一个“提交报销单”任务，不同障碍类型的用户走的是完全不同的操作路径。传统画像不记录这些，导致测试人员设计用例时只会用常规鼠标点击路径去验证，结果测出来一片绿灯，真实用户一用就卡死。第三，它没有与辅助技术建立映射关系。可访问性测试的最终落脚点是让产品与辅助技术兼容。辅助技术五花八门，屏幕阅读器有 NVDA、JAWS、VoiceOver、TalkBack，放大软件有 ZoomText，替代输入设备有开关控制器、眼动仪、头控鼠标。传统画像不关心用户用哪类辅助技术、用什么版本、在什么操作系统上跑，而这些恰恰是可访问性测试最关键的组合参数。没有这些信息，你连测试环境都搭不对。1.2 画像在测试链路中的正确位置我踩过几次坑之后，越来越倾向于把可访问性用户画像放在整条测试链路的最前端。它不是一个后续补充文档，而是决定测试范围、测试环境、用例设计、结果优先级排序的源头输入。你画出来的画像越贴近真实场景，后面的自动化扫描、手动走查、真实用户测试就越有靶子可打。打个比方，用户画像之于可访问性测试，相当于剧本之于电影拍摄。你不先把人物设定清楚，摄影师、灯光师、演员全凭感觉来，出来的片子大概率是散的。可访问性测试里的“人物设定”，就是用户画像。它至少要为后续三个环节提供输入：一是自动化测试中需要覆盖的辅助技术组合，二是手动测试中需要模拟的操作路径，三是埋点监控中需要关注的关键行为指标。所以我坚持认为，可访问性测试项目启动的第一件事，不是选工具，而是把用户画像做扎实。2. 构建可访问性用户画像的核心维度与方法以前我们画画像，主要靠访谈和问卷，但是对可访问性来说，这个远远不够。你不能只问用户“你平时用什么设备”，你得知道他在真实环境下如何与数字产品交互。我用了几年时间慢慢打磨出一套自己的画像体系，这里直接分享出来。2.1 画像的五大信息块我把可访问性用户画像拆成五个信息块，每一块缺了，后面的测试设计都会漏洞。第一块是个人基本信息，注意不是年龄、性别这些人口学指标，而是会影响数字交互的关键信息：年龄范围用来判断视力和操作能力的自然衰退程度，职业和日常任务用来理解上下文场景，数字产品使用经验用来区分新手和熟练用户对界面反馈的需求差异。第二块是障碍类型与程度描述。这一块我建议按照功能受限维度来划分，而不是按照医学诊断分类。功能受限维度包括视觉、听觉、操作、言语、认知、对光敏感等。比如“完全失明”和“低视力”虽然都属于视觉障碍，但对测试的要求差异非常大，前者依赖屏幕阅读器，后者依赖放大软件和高对比度支持。描述障碍程度时，尽量用可操作的语言：是否依赖辅助技术、依赖哪些、使用频率如何。第三块是辅助技术使用详情。这块是画像的技术内核，具体要记录：主要使用的辅助技术类型，比如屏幕阅读器、屏幕放大器、语音输入、替代鼠标等；具体软件名称和版本，比如 NVDA 2024.2、JAWS 2023；搭配的操作系统和浏览器，比如 Windows 11 + Chrome、macOS + Safari；辅助技术的自定义配置，比如语音速率、颜色方案、字体大小。这些信息直接决定你的测试环境矩阵长什么样。第四块是典型使用场景与任务。写清楚用户通常在什么环境下使用产品：是安静的办公室、嘈杂的公共区域，还是光线不稳定的户外？主要完成哪些核心任务？这些任务的频率和紧急程度如何？我见过一个团队把“无障碍通道”设计得很完善，但实际用户多是在嘈杂环境下用语音输入操作，结果语音指令反馈被环境音干扰，基本不可用。这就是场景没画到位。第五块是痛点和挫败点。这一块是画像里最有血的肉的部分。用户在用同类产品时遇到的最大障碍是什么？哪些操作会让他完全卡住？哪些反馈方式会让他迷茫？这些信息在做测试用例设计时是金矿，直接可以转成回归测试的重点项。2.2 画像构建的具体步骤实际操作中，我通常按四步来构建画像。第一步，数据收集，打出组合拳。不仅仅是做访谈，还要做实际观察。访谈容易把用户说的和用户实际做的混为一谈，很多用户自己也不太清楚自己怎么操作的，你问他他可能就说“我就点点点”，但你在旁边看他操作，你会发现他是通过语音识别加键盘快捷键混合操作的。所以有条件的话，一定安排用户在自己的真实设备上完成几个任务，你在旁边记录操作路径。另一个容易被忽略的数据来源是客服工单和用户反馈评论，这些地方藏着大量真实痛点的口语化描述，比如“那个下拉框我根本选不了”、“字太小看不清，只能放大到300%”。把这些原始描述收集起来，比问卷答案有价值得多。第二步，归纳聚类，按功能受限维度分组。把收集到的信息按照视觉、听觉、操作、认知等功能维度归组，注意不要简单按诊断归组。诊断相同不代表交互障碍相同，两位同为低视力的用户，一位习惯放大软件配和高对比度，另一位依赖系统的“深色模式”，测试需求就不一样。归组之后看看每一组的行为模式有没有一致性，有的一致性的组就可以凝聚成一个画像角色。第三步，画像描述，格式要标准化。我给团队建过一个模板，每个画像角色固定包含：角色名称，比如“键盘操作用户李先生”；一句话简介；功能受限描述；辅助技术栈；典型任务；用户目标；痛点场景。标准化格式的好处是，开发、测试、产品各方能快速找到自己关心的信息，而不是在一大段描述文字里翻找。第四步，评审与验证。画像建完不能直接扔给测试组，要组织评审。至少要有三类人参与：产品经理确认业务任务是否覆盖完整，开发确认技术配置是否可实现，测试确认画像对应的测试场景是否可执行。评审通过之后再作为基线存档，后续每次测试迭代前检查画像是否需要更新。2.3 画像的精度控制：该细分到什么程度这里要泼一盆冷水：画像不是越细分越好的。见过有些团队把画像画了十几种障碍类型排列组合，看着很周全，实际执行起来测试用例爆炸，根本跑不完。我的经验是，画像粒度要与产品形态和测试资源匹配。如果你的产品是一个内部工具，用户群相对固定，画像控制在三到五个角色就够，重点覆盖用户占比最高的前两类障碍，剩下的可以做轻度覆盖。如果是面向公众的消费级产品，用户群极其多样，画像可以做到八个左右，但每个画像必须有明确的数据支撑，不能靠想象硬凑。另外有个判断标准：凡是无法直接映射到一条可执行的测试路径上的画像，都算过度设计。可访问性用户画像的终点不是描述用户，而是告诉测试人员“这条路径需要测什么、用什么方式测、在什么环境里测”。如果你的画像角色画得花团锦簇，但测试人员看完不知道接下来该干什么，这个画像就是废纸。3. 从画像到测试用例的落地执行画像建好了，接下来才是硬仗——怎么把画像里的信息真正转成可执行的测试用例。这一步做不好，画像就又变成了抽屉里的文档。3.1 画像驱动测试场景设计的两种方法我常用的第一种方法是任务路径法。每个画像角色都有典型任务，我把每个任务拆成一条完整操作路径，路径上的每个节点就是一个测试点。举个例子，某个角色的画像描述是“低视力用户，使用 Windows 系统下的放大软件，主要任务是从列表中找到指定订单并提交审核”。这条任务的路径可以拆成：登录系统 → 导航到订单列表 → 定位到指定订单 → 点击进入订单详情 → 核对信息 → 点击审核按钮。测试用例就以这条路径为基线，分别考察放大软件下的界面可用性、文本可读性、颜色对比度、操作命中率、信息定位效率。第二种方法是探索式测试法，适合无法完全枚举路径的场景。基于画像的辅助技术栈，设置一个开放性任务，比如“请通过键盘完成一笔订单的修改”，然后观察实际操作路径，记录卡点。这个方法不需要预先设计所有步骤，但前提是测试人员对辅助技术操作足够熟练，否则你连用户卡在哪都看不出来。3.2 自动化测试工具与画像数据的结合自动化和用户画像不是互斥的，关键在于怎么把画像信息注入自动化测试配置。我在实践中常用的方法是维护一份画像-环境映射表。每一行是一个画像角色，列是操作系统、浏览器、辅助技术、配置参数等。比如：画像角色操作系统浏览器辅助技术关键配置键盘操作用户李先生Windows 11Chrome无开启高对比度主题屏幕阅读器用户王姐Windows 11ChromeNVDA 2024.2语速60%，使用左耳音频输出VoiceOver 用户林同学macOSSafariVoiceOver使用盲文显示器交互模式放大软件用户张工Windows 11EdgeWindows 放大镜缩放比例200%，跟随键盘焦点这张表的价值在于，它让自动化测试工具的配置不再拍脑袋。跑无头浏览器测试时，我会同时设置视口尺寸、颜色方案强制模式、以及必要的 ARIA 模拟，而且会跑两遍：一遍默认状态，一遍强制高对比度模式。对比两份结果差异，你就能发现很多控件在常规视觉下没问题，但高对比度模式下状态指示丢失了。3.3 人工测试环节的画像走查方法自动化工具毕竟只能覆盖技术性合规问题，大量真实体验问题还是得靠人工走查。我推荐一种叫“画像角色走查”的方法。测试人员一个人，按照画像角色的方式操作整个产品。不是你自己平时习惯的鼠标点来点去，而是严格模拟画像的交互方式。如果是键盘用户，就拔掉鼠标，只用 Tab、Shift+Tab、方向键、回车和空格完成所有操作。如果是屏幕阅读器用户，就关掉屏幕，戴上耳机，只听 VoiceOver 或 NVDA 的朗读。如果是放大软件用户，就把屏幕缩放开到200%，配合鼠标或键盘完成操作。这里有一个很关键的技巧：走查过程中必须记录“操作时间”。一个任务，普通鼠标操作两分钟完成，键盘操作十分钟还没走完，这本身就是严重的可访问性问题。很多团队只看“能不能完成”，不看“完成效率”，但真实用户对效率的敏感度极高，一个操作路径拖得太长，用户就会放弃这个产品。所以我在走查笔记里单独列了一栏“路径耗时”，作为与功能通过率同等重要的判断指标。另外，人工走查一定要录音录屏。别只靠脑子记，辅助技术朗读速度快的时候，你根本来不及记录。录屏文件后期回放时可以逐帧分析焦点移动是否合理、朗读顺序是否符合阅读逻辑、操作反馈是否有遗漏。4. 常见问题与排查技巧实录做可访问性测试这几年，我积累了不少实战踩坑经验。这里挑几个最典型的分享出来。4.1 问题一：画像角色和真实用户对不上最尴尬的场面是，画像文档画得一丝不苟，测试也按画像执行完了，但把产品拿给真实用户一测，用户说“我平时根本不是这样用的”。后来我复盘发现，问题出在数据采集环节。之前的画像数据主要来自产品经理的假设和部分问卷，没有经过真实用户的操作验证。比如说我们给某个角色设定的是纯键盘操作，但实际访谈发现，这位用户其实是键盘与鼠标混合操作——能用鼠标指到的地方用鼠标，指不到的就用键盘导航。很多患有关节炎的用户不是完全不用鼠标，而是用得很慢很吃力，他们会自己开发出一套省力的混合工作流。这个问题的解药只有一个：画像必须有真实观察数据做底。如果预算有限做不了大规模用户研究，至少找三到五个真实目标用户，做一两次任务观察，把操作路径录下来，再回来校准画像。宁可用小样本的真实数据，也好过大样本的臆测。4.2 问题二：自动化扫描扫不出动态内容的问题自动化工具对静态页面的可访问性错误识别率挺高，比如缺少 alt 文本、颜色对比度不足、按钮没有可见焦点等。但遇到动态交互内容，自动化工具经常失灵。最常见的是弹窗和下拉菜单：弹窗出现时，焦点没有自动移入弹窗内；弹窗关闭后，焦点没有返回触发按钮。这类问题严重影响键盘用户和屏幕阅读器用户，但自动化工具很难有效覆盖。针对这个问题，我的做法是，把动态交互场景单独列一个问题清单，凡是涉及弹窗、抽屉、下拉菜单、轮播图、自动补全列表的组件，全部必须走人工键盘走查。代码层面可以加一个定制的自动化脚本，用 Playwright 模拟键盘操作触发这些组件，第二部分检查焦点状态。但说实话，这类交互的最终把关，还是要靠人工走查加屏幕阅读器实测。4.3 问题三：团队对可访问性缺陷的优先级分歧测试提了一堆可访问性问题，开发那边觉得“这些又不影响正常人使用”，拒绝修复。这种扯皮我经历过不止一次。后来我改变了汇报方式：把可访问性问题与用户画像关联起来，用用户规模说话。每次提缺陷时，都标注这个缺陷影响了哪几类画像角色，对应的用户场景是什么。比如“导航菜单的焦点顺序错乱，导致键盘操作用户李先生的订单审核任务路径耗时从2分钟拉长到15分钟”，这个陈述方式比“导航菜单缺少正确的焦点管理”有力得多。同时我会在缺陷单里附上一条复现操作路径，让开发自己按这种方式试一遍。说实话，很多开发人员从来没有用键盘操作过自己的产品，你让他模拟一次用户体验，比贴十行说明文档都有效。4.4 问题四：辅助技术组合太多，测试环境维护成本过高屏幕阅读器和操作系统的组合种类繁多，不可能全部覆盖。我的建议是维护一个主流矩阵，并且有一个清晰的取舍逻辑：优先覆盖使用占比最高的前三组合。根据我接触到的数据，Windows 上 NVDA 加 Chrome、macOS 上 VoiceOver 加 Safari、Windows 上 JAWS 加 Chrome 是几个高占比组合。把这个矩阵写进测试计划，明确说明为什么只覆盖这些组合，可以避免后续测试无休止地加组合，导致成本失控。还需要注意辅助技术的版本锁定。辅助技术更新频繁，版本一变，测试结果可能就要重跑一遍。建议在一个测试周期内锁定辅助技术版本，测试报告里写清楚使用的版本号，等到下一个周期再统一升级。这样至少保证测试结果在一个周期内是可比的。5. 一些额外的提醒可访问性用户画像不是一次性工程。产品迭代了、功能新增了、用户群体变了，画像就要跟着更新。我习惯在每个迭代周期结束前做一个快速检查：这轮改动有没有引入新的交互方式？有没有新增高频功能？有没有用户反馈新的操作障碍？如果三个问题里有一个“有”，画像就要调整。另外提醒一件事：画像文档的存储位置和可访问性也要注意。我知道有个团队把画像文档放在一个只有内网可达的共享盘里，外部测试人员根本访问不到，结果每次需要画像信息时，都要靠项目助理人工转发。这看起来是小事，但对测试节奏的拖累非常明显。画像文档应该作为项目知识库的一部分，随项目仓库存放，保证所有参与方随时可以访问。我个人的体会是，可访问性测试中的用户画像真正做扎实了，带来的回报不仅仅是测试更有效率，更在于产品团队所有人的认知转变。当你把“屏幕阅读器用户王姐”当成一个真实存在的角色去讨论需求时，开发写代码时会主动考虑焦点逻辑，交互设计师画稿时会主动思考语义结构，产品经理评审需求时会主动问一句“这个功能键盘用户怎么操作”。这种改变，比测试本身多发现几个 Bug 重要得多。