可访问性、适老化与包容性设计
我见过最典型的场景：一个产品团队讨论"无障碍"，把无障碍理解成"给少数人准备的额外功能"。比如给图片加替代文本、把字号调大一点、把颜色对比度提高一点。这些都对，但太窄了。1
1. 导读
可访问性真正要解决的是：让不同能力、不同年龄、不同设备、不同使用情境下的人，都有机会理解产品、操作产品，并完成自己的任务。上线前补标签、调颜色只是其中很小的一部分。更深一层，它是产品质量的一部分。
想象一位老人用手机银行给子女转账。字号只是入口。他还可能担心点错收款人，可能不理解"实时到账"和"普通到账"的差别，也可能看不清浅灰色说明。验证码倒计时会让他紧张，风险提示又让他不知道该停下来还是继续。这个体验里有视觉、认知、操作、信任和错误恢复——字号放大只能解决其中一小块。
再想象一个临时受限的年轻用户。地铁里一只手抓扶手，只能用另一只手操作；开会时不能开声音，只能看字幕；手机屏幕在阳光下发白，低对比度文字几乎看不清；网络很差时页面加载一半，用户不知道任务是否提交成功。这些人未必是长期残障用户，但他们同样会遇到访问、理解和操作障碍。
可访问性、适老化和包容性设计可以放在同一条工作线上理解。可访问性让产品能被更多人访问、理解和操作；适老化提醒我们关注老年用户在感知、理解、操作和信任上的变化；包容性设计把视野进一步扩展到能力、文化、语言、设备、情境和身份差异。
如何让产品不只对"理想用户"好用，也能在真实世界的复杂情境中，被更多人顺利使用。
2. 核心问题
核心问题是：产品是否把真实用户的能力差异和情境限制纳入了设计。无障碍扫描结果可以提供线索，但它只是问题入口。
设计会议里默认的用户，常常像一个条件完美的样板：看得清、听得见、手很稳、懂术语、手机新、网络好、时间充裕、心情平静。但真实任务现场往往不是这样。用户可能一边排队一边办医保，可能在阳光下看不清浅色说明，可能刚收到"操作失败"却不知道钱有没有扣，可能第一次看到"风控校验"这样的词，也可能因为手抖点错了收款人。
如果团队只按理想用户设计，产品看起来会很干净，流程也会显得很顺。但一旦进入真实世界，问题就会出现。键盘无法操作弹窗，屏幕阅读器读不出按钮含义，错误提示只说"参数异常"。低对比度文字在户外看不清，验证码时间太短，表单要求用户重复输入同一信息，拖拽上传也没有替代操作。
从业者应能把可访问性从"视觉检查"扩展到结构、语义、操作、反馈、内容和测试。客户和管理者应能判断一个团队是在认真建设可访问体验，还是只是在交付一份看起来合规的检查结果。2
3. 关键概念与定义
可访问性，英文是 Accessibility，中文常译为"可访问性"或"无障碍"。它关注不同能力的用户能否访问、理解和操作产品。W3C 的 WCAG 2.2 将网页内容可访问性组织为四个原则：可感知、可操作、可理解、稳健，也就是常说的 POUR 框架。
这四个词听起来像标准术语，但放到产品场景里并不难理解。
可感知，是用户要能接收到信息。图片需要可理解的文字替代，重要声音需要视觉或文字提示，关键文字要在真实屏幕和光线下看得清。比如订单状态如果只用颜色区分"待支付"和"已取消"，色弱用户可能无法判断；视频教学配上字幕后，听障用户和开会时不能开声音的用户都能继续学习。
可操作，是用户要能完成动作。界面需要支持键盘、鼠标、触控、语音或其他替代输入方式，并让焦点在弹窗、表单和菜单里有清楚路径。比如一个后台系统的日期选择器，如果只能用鼠标点日历，键盘用户就可能无法填写日期；上传组件同时提供拖拽和按钮选择文件，会让更多用户完成任务。
可理解，是用户要知道产品在说什么、下一步会发生什么、出错后怎么办。比如金融产品只提示"本次交易暂不可继续"，用户并不知道是身份证信息不一致、银行卡状态异常、单日限额不足，还是这笔交易需要人工确认。更好的提示应该告诉用户问题发生在哪里、能否继续、如何修正。
稳健，是产品要能和不同设备、浏览器、辅助技术协同工作。比如按钮应有正确的名称、角色和值，状态变化应能被辅助技术感知，页面结构应有清楚的标题层级。否则视觉上看起来像按钮的元素，屏幕阅读器可能读不出它是按钮。
适老化设计，是面向老年用户感知、理解、操作和信任需求的设计。它与可访问性高度重叠，但不完全相同。老年用户可能出现视力下降、听力下降、精细操作能力下降、记忆和理解负担增加，也可能对欺诈、隐私、资金安全和复杂规则更敏感。W3C 关于老年用户的资料明确指出，老年用户的许多需求与残障用户的可访问性需求重叠；面向残障用户更可访问的网站、应用和工具，也会更有利于有相关需求的老年用户。
包容性设计，英文是 Inclusive Design，关注的不只是残障或年龄，而是能力、文化、语言、设备、情境和身份差异。Microsoft Inclusive Design 的公开资料强调从能力差异出发理解人与技术之间的不匹配，并通过包容性方法扩展产品可用范围。 对产品团队来说，包容性设计不是"替所有人设计一个完全一样的界面"，而是承认用户差异，并提供足够清楚、灵活、可恢复的体验路径。3
辅助技术，是帮助用户访问和操作数字产品的技术，例如屏幕阅读器、屏幕放大器、语音输入、开关控制、字幕、替代输入设备等。辅助技术不是少数人的"特殊工具"，而是很多用户完成任务的主要入口。产品如果没有正确语义、焦点顺序和状态反馈，就会让辅助技术无从发挥作用。
4. 概念边界与相近概念区别
字体放大只是可访问性的入口。字体大小很重要，但它只是可感知的一部分。真正的问题可能在信息结构、任务步骤、输入方式、错误恢复、验证码、身份验证、语义标签和操作时限里。
对比度合格只是起点。对比度检查能发现很多视觉问题，但一个页面即使对比度达标，也可能因为标题结构混乱、表单标签缺失、焦点不可见、文案含糊而难以使用。把可访问性缩小成颜色检查，就忽略了信息结构、焦点路径、文案理解和任务流程等更关键的问题。
适老化要进入核心任务。很多产品会把适老化理解成单独做一个大字版入口。大字版有时有用，但如果主流程仍然复杂，规则仍然模糊，风险提示仍然吓人，支付确认仍然不可撤销，用户只是更容易看见一条难走的路。真正有用的适老化要进入注册、登录、认证、支付、查询、取消、求助和异常处理。
包容性设计关注不必要的排除。任何产品都有目标用户、业务边界和技术约束，无法满足所有人的所有需求。包容性设计要做的是尽可能减少因为设计默认过窄而产生的排除。比如要求所有用户必须拖拽上传文件，就是不必要的排除；要求所有用户必须在 30 秒内完成验证码输入，也可能是不必要的排除。
合规提供底线。WCAG、Section 508、EN 301 549 等标准和规范能提供重要依据，尤其在公共服务、采购、平台产品和国际业务中非常关键。 标准通过之后，还要回到真实任务里验证：一段提示是否真的让老人放心，一个复杂报销流程是否让屏幕阅读器用户顺利完成。
标准是底线，真实任务是验证，用户差异是设计输入。
5. 方法、流程或框架
可访问性和包容性设计可以从 WCAG 的四个原则展开。落地到产品工作里，可以转化成一条更容易执行的链路：
识别用户差异 → 梳理关键任务 → 设计可访问结构 → 提供多种操作方式 → 降低理解负担 → 测试辅助技术和真实用户 → 持续治理。
第一步，识别用户差异，不是给用户贴标签，而是看任务会遇到哪些能力要求。
比如在手机上预约一次门诊，并不是点一个按钮这么简单。用户要分清科室和专病门诊，理解上午号、下午号、加号和停诊，确认就诊人身份，完成医保或自费支付，还要知道就诊前是否需要取号。这个任务同时考验视觉、阅读理解、记忆、时间管理和支付安全感。团队如果只看页面是否美观，就会忽略很多障碍。4
第二步，梳理关键任务。可访问性不能只检查静态页面，而要检查用户完成任务的全过程。
以手机银行转账为例，关键路径包括登录、选择转账入口、输入收款人、输入金额、确认手续费和到账时间、风险确认、二次验证、提交、查看结果。任何一步不可访问，整个流程都可能失败。WCAG 2.2 也强调"完整过程"的一致性：如果一个过程需要多个页面完成，那么每个页面都要满足要求，不能只让其中一页可访问。
第三步，设计可访问结构。结构不是给开发看的技术细节，它决定用户和辅助技术能不能理解页面。
一个看起来很漂亮的页面，如果标题只是加粗文字而不是标题结构，屏幕阅读器用户就无法快速跳转；如果按钮没有名称，用户只会听到"按钮、按钮、按钮"；如果错误提示只在视觉上变红，而没有文本说明和语义关联，用户就不知道哪里错了。
第四步，提供多种操作方式。默认用户会用不同身体能力、设备和输入方式完成任务。
如果一个筛选器只能拖动滑块，手部动作不稳定的用户会困难；如果一个验证码必须看图识别，视觉障碍用户会困难；如果一个客服入口只能电话联系，听障用户会困难；如果一段视频没有字幕，很多不能开声音的人也会困难。多通道不是重复建设，而是让用户能用适合自己的方式完成任务。
第五步，降低理解负担。这一点对适老化和认知可访问性尤其重要。
W3C 的认知可访问性资料指出，认知和学习障碍会影响信息处理，包括感知、记忆、语言、注意、问题解决和理解等方面；并且有些用户需求并未被现有标准充分覆盖，需要额外指导。 对产品来说，清晰语言、稳定结构、可预测反馈、可撤销操作和逐步引导都很重要。
第六步，测试辅助技术和真实用户。
自动化工具可以快速发现一部分问题，人工测试负责看见更贴近任务现场的问题。一个页面可能没有自动化错误，但键盘焦点顺序混乱，屏幕阅读器读起来像迷路，老人看到风险提示后不敢继续。可访问性测试至少应覆盖键盘、屏幕阅读器、颜色对比、缩放、表单错误、状态变化和关键任务完成情况。
第七步，持续治理。可访问性不是上线前最后一轮检查，而应进入设计系统、组件库、内容规范、研发验收、测试流程和采购要求。否则，一个项目修好了，下一个项目又会重新产生同样问题。
6. 实际工作场景
在消费产品中，可访问性常常出现在"用户快要完成任务"的关键时刻。
电商结账就是典型场景。用户已经选好商品，准备付款，但页面只用红色标出错误字段，没有文字解释；优惠券不可用，却只提示"规则不满足"；退换货说明颜色很浅，手机在阳光下几乎看不见；支付失败后不说明是否扣款。对普通用户来说，这些问题已经很烦；对视力下降、认知负担较重或第一次使用平台的人来说，这些问题可能直接导致放弃。5
在企业后台中，可访问性往往表现为效率和错误风险。
比如一个审批系统要求财务人员每天处理大量报销单。如果焦点顺序混乱，键盘用户就要在页面里反复绕路；如果状态标签只靠颜色区分"待补充材料"和"已驳回"，色弱用户容易误判；如果错误原因只写"附件异常"，员工不知道该重传发票、补充说明还是联系财务。这些问题最后会变成返工、培训、工单和投诉。
在公共服务中，可访问性和适老化更像基本服务能力。
用户打开政务或公共服务产品时，通常不是为了体验新产品，而是要把一件重要事务办完：缴费、预约、补材料、查结果、改信息、拿凭证。流程越重要，用户越不能被排除在外。对这类服务来说，页面清楚、键盘可达、屏幕阅读器可读、材料要求明确、错误可恢复、线下或人工协助路径清楚，都不是锦上添花。
在 AI 产品中，可访问性还会出现新的形态。
比如 AI 助手给出一段长回答，视觉上看起来完整，但屏幕阅读器用户很难快速跳到结论；图片生成工具只用缩略图展示结果，没有可理解的文字描述；语音助手没有文本替代；AI 输出不确定却没有清晰提示，老年用户或专业知识不足的用户可能过度信任。AI 产品也不能绕过可访问性、理解负担和信任设计。
7. 案例
Microsoft Inclusive Design 把包容性设计从"照顾少数人"转化成"理解人与技术之间的不匹配"。
比如一个人永久失去一只手、临时手臂受伤、或者抱着孩子只能单手操作，处境不同，但都会遇到单手操作限制。包容性设计的价值在于，它提醒团队不要只按最理想的身体状态设计。产品如果为单手、键盘、语音、替代输入等方式留出空间，受益的人群往往比最初想象的更大。
U.S. Web Design System 是另一个可核查案例。美国联邦数字服务需要面对广泛公众，因此 USWDS 把可访问性作为设计系统的重要组成部分，提供组件、模式和可访问性文档。
商业产品可以参考 USWDS 的做法，同时结合自身用户群体、技术栈、品牌和业务流程来做适配。
W3C 的认知可访问性资料也值得作为案例使用。
不是所有可访问问题都能被自动化扫描工具发现。认知障碍、学习困难、注意力困难、记忆负担、复杂语言和错误恢复，都需要内容设计、交互设计、信息架构和用户测试共同处理。比如用户申请一笔消费分期，即使每个按钮都有标签、对比度也合格，页面仍可能让人紧张。如果它连续出现"授信额度""综合年化成本""提前结清规则"，却不解释会扣多少钱、什么时候能撤回、提交后能否修改，用户仍然可能无法安心完成。
W3C 资料能支撑原则和指导方向，但具体产品是否有效，还需要在真实任务中测试。
8. 数据、指标或衡量方式
可访问性需要用多类证据衡量。
最常见的指标是可访问性通过率，也就是某一组检查项中通过的比例。它可用于审计、改版跟踪和设计系统治理。比如团队可以检查关键页面是否满足文本替代、标题结构、表单标签、焦点可见、颜色对比、键盘操作、错误提示等要求。6
但通过率有局限。检查项通过，不代表真实用户一定顺利。自动化工具能发现一部分代码和视觉问题，例如缺少替代文本、表单没有标签、颜色对比不足；但它很难判断医保报销材料说明是否让人看懂，风险提示是否让用户放心，复杂流程出错后是否还能回到正确路径。
第二类指标是键盘可达率。
如果一个后台系统有 120 个需要操作的控件，其中 20 个无法通过键盘访问或操作，那么键盘可达率就暴露了很直接的问题。它适合发现弹窗、下拉菜单、日期选择器、上传控件、分页和表格操作中的障碍。对 B2B 和企业后台来说，这个指标尤其重要，因为高频用户常常依赖键盘提高效率。
第三类指标是对比度通过率。
它适合检查文字、图标、输入框边界、状态提示和关键视觉元素是否足够清晰。对比度不是审美妥协，而是为了让信息在不同屏幕、光线和视力条件下仍能被识别。阳光下的公交查询、夜间的手机银行、低端屏幕上的政务表单，都需要这条底线。
第四类指标是任务表现。
对适老化和包容性设计来说，任务成功率、完成时间、错误率、求助次数、重复输入次数、撤销次数、客服咨询量，比单纯检查页面更接近真实体验。比如测试老年用户查询医保个人账户余额，团队不仅要看他最后有没有看到数字。还要看他是否知道入口在"医保电子凭证"还是"个人账户"，是否读懂"统筹基金"和"个人账户"的区别，是否担心截图泄露隐私，以及是否知道结果已经保存到哪里。
第五类指标是反馈和风险指标。
投诉率、客服电话量、辅助技术用户反馈、无障碍邮箱反馈、应用商店差评、错误提交率、误操作率，都可能提示可访问问题。但这些指标需要谨慎解释。投诉少不一定代表无障碍做得好，也可能是用户已经放弃反馈；客服量下降不一定代表流程更清楚，也可能是客服入口变难找。
比较稳妥的衡量方式是组合证据：标准检查给底线，辅助技术测试给可操作性，真实任务测试给体验质量，运营数据给上线后信号。
9. 常见误区
第一个误区，是认为可访问性只服务残障用户。残障用户当然是核心受益者，但可访问性也帮助老年用户、临时受伤用户、低网速用户、单手操作用户、不能开声音的用户、阳光下看屏幕的用户。可访问性设计常常让产品整体更稳、更清楚。
第二个误区，是把可访问性当成前端工程师的事。前端实现很关键，但很多问题在更早阶段就已经产生。信息架构不清、按钮文案含糊、错误流程不可恢复、任务步骤过长、业务规则难懂，这些都不是前端最后加几个属性就能解决的。7
第三个误区，是只依赖自动化扫描。自动化工具很有价值，但它只能发现一部分问题。它可能发现图片缺少替代文本，却判断不了替代文本是否有用；它可能发现表单缺少标签，却判断不了用户是否理解字段含义；它可能看不出老人面对风险提示时是否敢继续。
第四个误区，是把适老化做成"大字模式"。字号只是入口。适老化还要处理更深的任务压力：少让用户记住上一屏的信息，关键操作前给确认和撤销，解释资金、隐私和医疗风险。它还要减少密集术语，保留人工帮助，避免倒计时催促，并尽量保护用户免受误导和欺诈。
第五个误区，是认为通过标准就等于体验好。标准是底线，不是终点。WCAG 自身也说明，即使遵循指南，也不能满足所有残障用户的所有需求。 团队仍需要结合产品任务、用户群体和真实测试继续优化。
第六个误区，是把包容性设计写成口号。"我们面向所有用户"听起来很好，但如果没有用户差异分析、替代操作路径、辅助技术测试和反馈闭环，就只是姿态。包容性设计需要进入需求、设计、研发、测试和运营，而不是停在价值观表达里。
10. 小结
可访问性、适老化和包容性设计，本质上都在提醒团队：真实用户很少处在理想条件里。
可访问性让产品能被更多人访问、理解和操作。适老化让团队关注老年用户在感知、理解、操作和信任上的变化。包容性设计则进一步提醒我们，能力差异、文化差异、设备差异和情境限制都会影响体验。
对从业者来说，最重要的不是把标准条款背熟，而是建立一种工作习惯：从关键任务出发，识别能力要求，设计多通道路径，降低理解负担，测试辅助技术，并持续治理。
判断可访问性质量：不光看分数和通过项，更要看能否解释真实用户如何完成任务、哪里可能被排除、如何验证改进、哪些结果不能过度承诺。
标准提供底线，案例提供启发，测试提供证据。三者结合，产品才可能真正从"看起来可用"，走向"更多人真的能用"。
11. 延伸阅读
W3C Web Content Accessibility Guidelines 2.2 适合产品、设计、前端、测试和管理者共同阅读。它是网页可访问性的核心标准资料，但正式项目需要结合具体地区法规、行业要求和产品类型理解。
W3C Understanding WCAG 2.2 适合从业者在执行检查和设计修复时阅读。它比标准条文本身更容易理解，能帮助团队把成功标准转化为设计和实现判断。
W3C Older Users and Web Accessibility 适合做适老化设计的团队阅读。它能帮助读者理解老年用户需求与可访问性需求之间的重叠。
W3C Cognitive Accessibility Guidance 适合内容设计、交互设计、AI 产品和复杂业务流程团队阅读。它提醒团队关注理解、记忆、注意、错误恢复等问题。
Microsoft Inclusive Design 适合设计负责人、产品经理和管理者阅读。它能帮助团队把包容性设计从口号转化为"识别不匹配、扩大可用范围"的方法。
U.S. Web Design System Accessibility 文档适合设计系统团队阅读。它展示了公共服务设计系统如何把可访问性纳入组件、模式和治理。
注释 1 W3C, Web Content Accessibility Guidelines 2.2, 2024。🔗 https://www.w3.org/TR/WCAG22/
2 W3C WAI, Older Users and Web Accessibility。资料较早，正式出版前需复核其当前版本和适用性。 🔗 https://www.w3.org/WAI/older-users/
3 Microsoft Inclusive Design / Inclusive Tech Lab。🔗 https://inclusive.microsoft.design/
4 U.S. Access Board, Revised 508 Standards and 255 Guidelines。🔗 https://www.access-board.gov/ict/
5 ETSI / CEN / CENELEC, EN 301 549。最新正式版本和适用范围需正式出版前复核。 🔗 https://www.etsi.org/human-factors-accessibility/en-301-549-v2-the-harmonized-european-standard-for-ict-accessibility
6 W3C WAI, Cognitive Accessibility Guidance。原则和指导不能替代具体产品用户测试。 🔗 https://www.w3.org/TR/coga-usable/
7 U.S. Web Design System Accessibility。🔗 https://designsystem.digital.gov/