← 返回信息流
AI 资讯Hacker News·3 天前

与盲人客户合作揭露的隐形无障碍障碍

原标题:How working with a blind client revealed invisible accessibility gaps

速览

项目团队与一位完全失明的客户合作开发网站,通过实际使用和反馈,发现许多看似正常的功能对盲人用户不可用,例如复杂的导航和图像描述。研究结果显示,这些差距不仅影响用户体验,还凸显了开发者在设计时的常见盲区。通过这一过程,团队意识到了无障碍设计的必要性,并调整了后续项目以提升包容性。这一案例为科技公司提供了重要启示,提醒他们应优先考虑不同用户的实际需求,避免技术先进但忽视残障人士的解决方案。

AI 深度解读

背景

这篇帖子出自 Hacker News,用户是一位为微软 Power Automate 开发的购买审批工作流项目负责人。她描述了一次与盲人客户合作的过程:合同中明确要求详细的可访问性规范,针对盲人和失聪员工使用的工具。客户由一名盲人资深可访问性专家亲自领导审查工作,专家本人也是最终用户之一。作者原计划只需2小时左右的审查,但实际花费18小时,才发现平台本身就构成了巨大障碍,最终构建了定制培训材料并绕过部分不可修复的问题。

核心内容

作者最初以为可访问性审查会很简单——找一位盲人专家登录浏览器账号,跑一遍流程,几处调整即可完成。结果失败了:微软浏览器应用对屏幕阅读器支持极差,专家无法按需导航。作者调整策略,让专家使用桌面应用独立账号测试,两人尚未正式查看工作流本身,平台就已经成为最大障碍。

随后他们决定通过 Zoom(作者曾用 Teams 和 Google Meet,但专家认为 Zoom 是最可访问的视频会议工具)进行测试。专家分享屏幕,作者跟随她实时听屏幕阅读器逐字念出页面内容,理解她如何通过听觉定位、决定下一步。这种互动让原本抽象的问题变得具体起来。

项目核心页面是 SharePoint 上用户查看请求审批状态的页面。页面设为只读模式,防止用户误操作,但在 SharePoint 中,所有字段都会自动追加“(read only)”后缀。这意味着屏幕阅读器会反复听到这句话,视障用户不仅听起来烦人,还会因冗余字符占用设备空间而导致实际内容被挤压。作者花大量时间尝试寻找隐藏标签、替代分享方式等解决方案,最终得出结论:无法解决,只能任由平台处理。

类似问题反复出现。Power Automate 原生审批应用在 Teams 中完全不被屏幕阅读器识别;Outlook 中的审批邮件兼容性问题;SharePoint 单页面出现多个 H1 标题,这直接破坏了屏幕阅读器的导航逻辑(标题对视障用户是唯一定位工具,多个 H1 制造假幻灯片)。作者强调这些是行业普遍现象,而非只针对微软。

作者在有控制权的部分进行了改进:移除不必要标签,添加准确描述性 alt 文本,重构标题结构,并在 SharePoint 跟踪页面彻底重构——不再让用户与不可访问页面对抗,而是改为每阶段自动发送邮件通知(每请求4-5封邮件),让专家用户完全绕过该页面。

在无法修复的地方,作者与专家共同开发了针对其特定屏幕阅读器和操作习惯的培训材料,并撰写了诚实的文档,说明哪些问题不可解决,但用户仍可通过哪些方式应对。作者本人也亲自使用屏幕阅读器测试,真正体会到视障用户的“噪音”体验:成堆的标签、状态提示、重复短语和结构杂乱,让用户必须逐字“坐等”才能到达核心内容。作者指出,多数软件由可视人士构建、由可视人士测试,包容性差距直到实际使用者亲身经历时才显现。

文章最后呼吁开发者从一开始就融入可访问性标准、公司内倡导工具评估、用户主动报告问题,并列出 W3C、WCAG、Pa11y 等资源供进一步学习。

关键要点

  • 合同明确要求可访问性规范,但浏览器和平台工具本身成为最大障碍,专家无法按预期导航。
  • SharePoint 只读页面因重复“(read only)”后缀导致屏幕阅读器用户听力疲劳,视障用户还受空间占用困扰。
  • 多个 H1 标题破坏导航逻辑,Power Automate 审批应用和 Outlook 邮件兼容性问题普遍存在。
  • 平台问题占多数,可通过重构页面(改邮件通知)、移除标签、添加 alt 文本等方式改进。
  • 视障用户会“听”到大量无关噪音,作者亲自测试后深刻体会“噪声”问题。
  • 可访问性不仅是事后审计,更应从开发阶段融入,行业需重视实际使用者反馈。
  • 微软工具成为许多开发者依赖的基础,平台差距直接影响开发者工作。

意义与影响

这篇案例深刻揭示了软件行业长期忽视可访问性导致的“隐形差距”:大多数开发者和测试者都来自视觉群体,缺乏亲身体验,问题直到盲人用户亲自参与时才暴露。专家在合同中投入时间审查,迫使项目在开发阶段就面对真实需求,最终促使作者主动改进界面并创建绕过方案。这证明,合同级可访问性要求并非多余,它能强制团队从头构建包容性产品,而非事后补救。

对于开发者而言,该案例提供了实用路径:优先在 SharePoint、Teams 等 Microsoft 工具上应用 WCAG 标准,移除冗余标签并优化结构;对于公司而言,建议定期评估日常办公软件是否适合全员(包括盲人同事),将可访问性纳入采购和开发流程;对于用户和报告机制,它鼓励主动反馈,推动 Microsoft 等平台加速修复“(read only)”等问题。

更广义地说,这篇文章提醒行业:包容性不应是“别人问题”,而是核心竞争力。作者最终无法修复所有平台问题,但通过培训材料和绕过方式让专家用户获得可行体验,展示了即使在约束条件下,也能将可访问性转化为真正可用的产品。长期来看,它会推动整个科技生态从“可查看”转向“人人可参与”,减少隐形偏见,让更多人平等享受数字化服务。

查看原文 →iinteractive.com