可访问性测试中的用户画像：从构建到落地

很多人一听到“可访问性测试”，第一反应就是打开自动化扫描工具，跑一遍对比度、Alt 文本、ARIA 标签，输出一份报告就算完事。真正把可访问性测试做成体系之后，你会发现自动检测只是起点。我真正开始重视“可访问性测试中的用户画像”，是在一次做产品无障碍改造的时候。当时团队拿着扫描报告改了一轮又一轮，盲人用户一测还是点头摇头，要么找不到入口，要么读屏顺序完全乱套。后来我们停下来复盘，发现缺的不是工具，而是对“到底为谁做”这件事缺少一个具体的判断标准。用户画像这个概念就在这个背景下被正式引入了测试流程，而且它起到的效果比我预想中要明显得多。

这篇文章我想聊的不是理论，而是我自己从踩坑到梳理出方法的过程。内容包括：可访问性测试里画像和普通用户画像的区别、画像素需要包含哪些关键维度、怎么才能快速产出一份能真正指导测试的画像、以及怎么把它嵌进日常的测试执行里。这些内容适合做落地的测试同学、前端开发、产品经理和质量负责人参考，不涉及高深的技术门槛，只要你手里有要测的产品，就能照着搭起来。

1. 为什么可访问性测试要单独谈“用户画像”

1.1 传统用户画像的盲区

传统意义上的用户画像，核心是描述人口属性、使用习惯、消费场景和产品目标。比如“25-35 岁的办公室白领，常用手机端处理工作任务，偏好高效率工具”，这已经很清晰了。但这类画像放到可访问性测试里，会漏掉最关键的一层，就是角色如何使用界面、用什么设备去访问、在什么障碍条件下完成同样的任务。

举个例子。普通画像关心用户“会用鼠标还是触屏”，可访问性画像必须更细地关心“用户是否完全依赖键盘操作”“读屏软件会不会把导航栏和主内容区的顺序搞混”“色彩对比度能否支持低视力用户在室外强光下识别信息”。没有这些信息，测试用例的编写就只能靠猜测，改出来的界面往往也只是“看起来合规”，而不是“用起来顺畅”。

我见过不少团队在可访问性测试里还是套用普通画像的做法，把“年龄在 60 岁以上”等同于“需要大字号”，把“低视力”等同于“放大页面就完事”。这种简化看起来合理，实际上离真实用户的行为路径差得很远。可访问性用户画像的价值，就是把这些被忽略的操作细节、障碍条件和辅助工具重新拉回到测试设计里，让测试跟着真实的人走，而不是跟着文档化的标准走。

1.2 画像驱动的测试与需求转化

可访问性测试有一个天然难点：很多问题不是“绝对不可能用”，而是“用起来特别费劲”。一个按钮可能能被键盘聚焦到，但三下 Tab 才能切换过去，旁边还有两个不可见的装饰性控件。这种问题自动化工具发现不了，单纯对照规范逐条检查效率也不高。如果先有一个明确的用户画像，再带着画像去测，判断标准就会变成“这位用户在完成核心任务时，操作路径是否足够短、是否有干扰、是否有预期反馈”。

画像驱动的测试设计并不复杂。核心逻辑是先把用户描述转化成可验证的问题列表。比如画像是低视力用户，那么问题就是：他能否在弱对比环境下看清当前焦点？能否通过快捷键直接跳过重复导航？屏幕放大到 200% 时，表单布局会不会错乱？这些验证点直接成为用例的骨架，比从几十条规范里翻找要灵活，也更能贴合产品的实际业务。

可访问性不是把 WCAG 的 A、AA、AAA 逐条打勾，而是让特定的用户能够完整地完成他们想做的事。画像在其中充当的是“翻译层”，把抽象的人群描述转译成可测试的行为路径。这也是我后来一直在团队里推画像方法的原因，它能让讨论从“标签缺失”升级到“入口流程不清晰”“当前焦点没有视觉反馈”“提交按钮和表单内容距离太远”，这些才是产品真正需要改的东西。

2. 可访问性用户画像的核心维度

2.1 障碍场景与功能受限

构建可访问性画像，第一步不是写名字和年龄，而是定义“用户障碍场景”。视觉障碍、听觉障碍、行动障碍、认知障碍是最常听说的分类，但实际做画像的时候还需要继续细分。

视觉障碍里就有全盲、低视力、色弱、光敏感等不同情况。全盲用户依赖屏幕阅读器和盲文设备，低视力用户可能使用屏幕放大软件、高对比度主题，色弱用户遇到红色错误提示可能完全无感。这些细分不是文字游戏，因为不同细分直接影响测试工具的选择和关注点。

行动障碍也需要拆开。有人是手部震颤，难以精确操作小目标；有人是肌无力，需要减少操作次数；有人只能靠眼动追踪或头部追踪来交互。这类画像和视觉障碍画像的关注点完全不同，前者测焦点顺序和快捷键，后者更要测目标尺寸、操作力度和响应时间。认知障碍又包含注意力缺陷、记忆力下降、阅读障碍等，对应的是信息密度、文案复杂度、确认流程和错误恢复机制。

一个可访问性画像必须明确“限定了哪种障碍”，并且写清楚这种障碍在具体使用场景下如何影响操作。模糊地写“视障用户”等于没写，因为盲人用户和低视力用户面对的设计方案差别实在太大。

2.2 辅助工具链与操作方式

画像的第二个关键维度是“辅助工具链”。同样的视觉障碍，用户可以选择不同的工具组合。Windows 上常见的读屏软件是 NVDA，macOS 上是 VoiceOver，移动端有 iOS 的 VoiceOver 和安卓的 TalkBack。低视力用户可能用 ZoomText、Windows 放大镜，也可能只用浏览器自带的缩放功能。操作方式的差异会带来非常具体的问题，比如 NVDA 对某些网页元素的朗读方式与 VoiceOver 不同，按钮的可用名称有时会在读屏中被误读为两段。

除了软件，还要考虑硬件。有人使用普通键盘，有人使用单手键盘，有人通过开关控制设备，有人依赖语音输入。这些辅助工具链决定了测试时该模拟什么输入方式，也决定了关注哪些交互细节。比如一个只支持双击操作的应用，对只能使用单击的用户就完全不友好；一个需要高精度的拖拽组件，对手部控制能力有限的用户就是不可逾越的障碍。

画像是测试的“用户代称”，更是工具链的“输入参数”。我在实际测试时，会把同一张画像复制成几张细分卡片，分别标注“使用 NVDA + Chrome”“使用 VoiceOver + Safari”“使用 Windows 放大镜 + Edge”，然后带着每一张卡片去走一遍同样的核心任务。这样能暴露出很多单一工具测试发现不了的问题。比如某个提示文案在某个读屏环境中会被重复朗读，另一个环境中却完全被跳过，实测结果差距很大。

2.3 上下文、任务目标与应急场景

可访问性画像不能脱离场景来写。用户使用产品的环境、心情、身体状态和任务目标，决定了测试用例的优先级。

有的用户是长期残障，已经形成固定操作习惯；也有用户是临时性障碍，比如手臂受伤、在嘈杂环境中听不清声音、在强光下看不清屏幕。这两类人群对同一产品的诉求往往不同。长期用户渴望稳定、可预测的交互流程，临时用户更需要快速上手的提示和容错机制。

任务目标也应区分主次。对于一张登录页面，低视力用户的首要任务是快速找到用户名输入框，其次才是记住密码、切换登录方式这类次级操作。画像是用来挑选核心用户旅程的，不需要把每个功能都列入高频路径。只有把有限的高频任务定义清楚，测试执行才不会摊大饼。

应急场景通常包括网络不稳定、设备性能偏低、后台临时故障等。可访问性画像如果只在“理想状态”下构建，测试就会漏掉很多现实问题。低视力用户可能在弱网环境下等待图片加载，如果替代文本没有提前设计好，得到的反馈就是一片空白。认知障碍用户遇到页面加载缓慢，缺少明确等待状态，就可能反复刷新，形成恶性循环。好的画像会写清楚“用户当前状态、所处环境、正在完成什么任务、最怕什么中断”，这四个信息能让测试设计师获得很清楚。

2.4 画像的优先级与组合策略

你不可能为一个功能创建几十张画像，时间、预算和开发资源都扛不住。因此优先级排序很重要。

我的方法是先按两个维度给画像排序：一个是“该用户群体在真实产品的占比”，另一个是“该画像覆盖的障碍问题严重程度”。用户量较大、问题破坏性较高的画像排最前面，作为主画像；用户量较小但问题严重、需要专门验证的，作为补充画像。主画像用来驱动的用例数量和执行深度最高，补充画像用于关键页面的专项验证。

组合策略上，不需要让一张画像覆盖所有障碍类型。真实用户确实可能同时有视障和行动障碍，但测试设计里把两种障碍放在一张画像上，会让问题定位变得困难。我更倾向于让主画像保持单一障碍主线，比如“低视力 + 屏幕放大 + 键盘操作”，避免一次塞进太多条件。如果产品有支付流程这类高风险场景，再额外设计一张复合画像做专项测试，兼顾真实性和复杂度。

画像的优先级不是固定不变的。产品迭代到不同阶段，核心任务的权重会变，画像的排列组合也需要跟着调整。比如刚上线时，注册登录是主任务，画像重心落在表单交互；进入内容消费阶段后，阅读、搜索、播放变成主任务，画像就要重新定义核心路径。

3. 从零构建一份可用的画像

3.1 字段设计：一个实操模板

构建可访问性画像时，我习惯用一套固定字段，字段太多写起来累，字段太少不具备指导性。下面这个模板是我结合多个项目经验整理出来的版本：

这个模板的好处是既能看到“用户是谁”，又能看到“测试时具体该做什么”。画像代号用贴近生活的名字而不是“用户A”“用户B”，团队讨论时会更具体。比如“低视力老周”明显比“视障用户组”更能触发设计上的代入感，但注意代号不要包含真实身份信息，纯粹用于内部沟通。

模板写完之后，最好再用一句话把画像浓缩成一个场景描述：“老周在通勤地铁上用手机看配送进度，手机开到了最大字体，太阳光线导致屏幕过亮。他想知道包裹还有多久到，但发现除了抬头看全屏提示，找不到任何文字型的状态更新。”这样一句话主测、开发、设计看到后，都能立刻明白这次的测试目标是什么。

3.2 数据来源与匿名化处理

画像字段怎么填，不能靠拍脑袋。常见的数据来源有三类：第一类是线上产品行为数据，比如辅助功能使用率、用户反馈中的障碍相关关键词、客服工单里提到的操作困难；第二类是用户访谈和可用性测试，找真正使用辅助工具的用户来聊操作路径；第三类是间接数据，比如可访问性论坛、用户社区中针对同类功能的大量反馈。

在实际操作中，组织资源有余力的团队会让一位“用户研究员”专门整理画像，小团队则可以让测试人员兼职。我的经验是，不需要一次性投入太多资源去搞正式用户访谈。先把现有渠道里能拿到的反馈和数据拉出来，拼出第一版画像，然后带着画像去找 3 到 5 位符合画像的真实用户做一轮简短的走查，修正偏差。这样成本低，准确率也足够高。

涉及真实用户信息时，必须做匿名化处理。给用户分配代号，抹掉姓名、住址等身份信息，只保留与测试直接相关的障碍类型、辅助工具、偏好设置和任务背景。不需要在画像素中记录任何可用于定位个人的信息。企业如果有更严格的合规要求，可以只保留聚合描述，比如“有 35% 的被访用户反馈表单验证码难识别”，而不是引用某一位用户的原话。

3.3 一份完整画像示例

下面给出一个我在模拟项目中实际用过的画像素，字段内容做了脱敏处理，只保留结构和核心信息，方便你参考复现。

画像代号：低视力老周 障碍类型：低视力，视力约 0.1，可使用残余视力 辅助工具：iOS 系统“放大镜”+ 系统字体放大 150%，开启“减弱动态效果” 输入方式：触屏 + 简单的语音听写 使用环境：主要在室内 WASD 光线环境下使用，偶尔在室外强光下查看 核心任务： 1. 查看当日订单配送进度 2. 查找历史订单并申请售后 3. 在收货时确认签收 主要痛点： 1. 表单字段对比度低，焦点高亮不明显 2. 验证码图片难以辨认，无法放大 3. 订单状态按钮区域过小，难以精准点击 成功标准： 1. 在 3 分钟内查看配送进度 2. 在 6 分钟内完成售后申请 3. 签收步骤三步内完成，并收到明确成功提示 反例限制： 1. 不使用纯色块表示状态 2. 不使用双击展开这种手势要求过高的交互 3. 不使用仅依靠颜色的错误提示

这样一张画像写完，大概用时两小时，足够支撑一轮完整的测试执行。至于具体怎么从画像里提取用例，接下来展开说。

4. 把画像落地到测试执行

4.1 从画像出发提取核心测试场景

画像不是写出来给人看的，是用来给测试设计提供输入的。我的做法是先把画像中的核心任务拆成具体操作步骤，再针对每一步列出验证点。

以“查看订单配送进度”为例。画像里老周的路径是：打开 App 首页，找到“订单”入口，进入订单列表，找到目标订单，查看当前配送状态。那对应到测试场景，就有五个需要验证的环节：首页入口是否容易发现，订单入口按钮是否足够大，订单列表的排序和区分度是否清晰，目标订单的状态文字是否可读，配送状态更新后有没有显著的提示。

每个场景继续往下拆验证点。比如“首页入口是否容易发现”，可以拆成三个验证级问题：首页上是否有文字标签能说明这是订单入口，而不是单纯图标；焦点是否能快速落在入口区域；入口区域的对比度在放大模式下是否仍然足够。这样一层层拆下来，一张画像自动会带出几十个验证点，基本不会出现“不知道测什么”的情况。

拆解完后，给每个验证点打上严重等级。阻断性问题优先修，比如“无法进入订单列表”“读屏完全跳过关键状态”这类直接挡住任务完成的问题，必须第一时间暴露。次级问题像“入口对比度不理想”可以跟随迭代优化。分级能保证测试报告不是一份无差别的清单，而是有行动顺序的排期表。

4.2 用例矩阵怎么组织

测试用例的组织方式，直接影响执行效率和报告可读性。我推荐按“场景 × 画像”的矩阵结构来组织。纵向是每个核心场景，横向是不同画像，矩阵交叉处放该画像能不能完成这条场景的结论和证据。

矩阵本身不复杂，但要注意三点：

1. 每个场景对应至少一个主画像和一个补充画像，保证覆盖广度和专业深度。
2. 每条结论必须附实测细节，比如“NVDA 下可以正确朗读按钮名称，但在 VoiceOver 下序号被跳过”，不能只写“失败”。
3. 遇到“有争议”的情况，比如工具版本差异导致结果不同，把环境和复现步骤记录下来，方便开发定位。

我通常会在矩阵里额外加两列：一列是“障碍严重程度”，一列是“预计修复成本”。这样产品经理看报告时能直接判断哪些问题应该进当前迭代，哪些可以排在后续优化里，不至于因为一份长报告而陷入决策瘫痪。

4.3 辅助技术与工具的选择

画像定义了“用什么测”，工具则解决“怎么测”。实际执行里，我一般会同时使用自动扫描、手动操作和读屏验证三条线。

自动扫描工具适合做第一轮“普查”，快速找出对比度不足、缺少替代文本、ARIA 使用不规范等规则明确的问题。但它的输出不能直接当成最终结论，因为很多问题依赖上下文判断，比如图片的替代文本是否准确、组件的语义是否恰当，这些必须由人来判断。

手动操作验证是第二层。按照画像里的输入方式，我会开系统放大镜、调高字体、切到高对比度主题，然后用键盘完整走一遍核心任务，记录焦点顺序、焦点可见性和操作反馈。这一层能发现自动化工具完全无感的问题，比如某个自定义组件的焦点逻辑在键盘操作时出现死循环，或者下拉菜单展开后焦点被弹窗遮挡。

读屏验证是第三层，也是最不可省的。不同读屏工具对同一段代码的解析结果不一样，真实用户的分歧也很大。主测人员不必成为读屏专家，但至少要会用 NVDA 或 VoiceOver 走一遍核心路径。启动读屏后，从头到尾听完一遍页面即可听到很多问题：标题层级混乱、提示信息重复、焦点位置不明等。这个动作能最快地还原“看不见界面”的体验。

5. 实践中的常见问题与排查心得

5.1 画像过于“标准”，落不了地

第一个常见问题，是把画像写成了“标准人群”。比如“低视力用户需要使用高对比度界面”，这句话看起来正确，实则没有指导意义。

可访问性测试的画像一定要避免“正确但无用”的表述。我会要求团队给每个画像至少填一个反例限制和一个具体操作方式。比如反例限制写到“不允许用纯色块表示配送状态”，操作方式写到“用户通过系统放大镜将界面放大到 150% 后，需要横向滑动才能看到完整状态栏”。有了这种具体描述，主测才能真的去执行，而不是停留在字面理解上。

如果发现画像写完无法转成任务或验证点，多半是字段太抽象。此时退回上一步，把核心任务拆细，列出具体操作步骤，就能很快让画像重新落地。

5.2 回避“特殊人群”的测试偏见

团队在测可访问性时会无意识地把这类测试当成“附加题”，提交结果时甚至会轻描淡写地说“特殊用户数量较少，优先级放低”。这种偏见很危险。可访问性是基础体验的一部分，不是小众福利。

我常用的破除偏见的方法，是刻意把可访问性画像放进每一个常规功能的验收门槛里。新增一个页面，默认就要先跑一遍老周画像的核心路径；新增一个重要按钮，默认就要验证它在键盘操作下可用。把可访问性测试从“定期专项”改成“常规流程标配”之后，团队对这类问题的重视程度会提高很多，修复成本也在持续下降。

另外注意，不要拿“我们没那么多真实用户”当借口。画像本来就是一种替代方案，它建立在收集到的真实反馈之上，不需要每一次都做大量用户招募。只要画像依据的数据来源是真实的、更新是及时的，已经足以支撑一轮有效测试。

5.3 效率提升与可持续迭代

可访问性用户画像不是一锤子买卖。产品每更新一轮，核心任务和页面结构会变，画像也要跟着微调。我在实际操作中会按季度做一次画像回顾，把上个季度的用户反馈补充进画像素里，再删掉那些已经不再对应的场景。

效率方面的另一个心得是，不要试图让所有测试人员都执行全部画像。更高效的做法是给每个测试人员分配一两个固定画像，让他在这个画像上积累深度的工具使用经验。经过两三个迭代，这位测试人员对读屏软件的操作熟练度、对放大模式的细节敏感度，都会比每次都轮换画像高出不少。后续再遇到类似问题，他能直接判断是哪一层出了问题，不需要翻文档、查工具。

如果你所在的团队刚刚开始做这件事，建议第一个月只挑两个画像，一个主画像一个补充画像，把它们跑顺了再扩展。可访问性测试的核心不在数量多，而在每个画像真的能指导测试，每条测试结果真的能推动产品改进。工具是越用越熟，画像也是越用越贴近真实。

我个人这几轮做下来最强烈的一个感受是：可访问性测试里最难的从来不是技术，而是把“用户”这个抽象概念转成可执行的测试路径。用户画像在这里就像一张地图，有它你不会迷路，没有它你只是拿着一堆工具原地打转。如果你也正处在“规则测了但用户还是不好用”的阶段，强烈建议先停下来，花两天时间把画像素建起来，再带着它跑一遍核心流程，实验结果会说明所有问题。