惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
Docker
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
A
About on SuperTechFans
博客园 - 【当耐特】
Microsoft Security Blog
Microsoft Security Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The GitHub Blog
The GitHub Blog
雷峰网
雷峰网
博客园_首页
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
IT之家
IT之家
博客园 - 叶小钗
Google DeepMind News
Google DeepMind News
aimingoo的专栏
aimingoo的专栏
博客园 - 聂微东
B
Blog RSS Feed
H
Help Net Security
Recent Announcements
Recent Announcements
阮一峰的网络日志
阮一峰的网络日志
D
DataBreaches.Net
L
LangChain Blog
Vercel News
Vercel News

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
如何进行 UX 障碍性评估?
TCC翻译情报局 · 2024-10-16 · via 人人都是产品经理

在数字无障碍性成为法律要求的今天,确保数字界面的可访问性对于服务残障用户至关重要。本文提供了一个全面的框架,包括自动化工具、手动评估、可用性测试和辅助技术测试,以评估和提升用户体验的无障碍性。

译者推荐:在数字无障碍日益成为法律要求的今天,确保数字界面的可访问性对于服务残障用户至关重要。

本文提供了一个全面的框架,包括自动化工具、手动评估、可用性测试和辅助技术测试,以评估和提升用户体验的无障碍性。推荐给所有致力于提升数字产品无障碍性的设计师和开发者。

数字无障碍正在兴起。自从满足基本无障碍标准成为一项法律要求,而不仅仅是锦上添花的条件以来,越来越多的组织开始质疑他们的数字界面能否能很好地服务于残障用户。

1.无障碍案例

事实是,除非你的产品专门针对身体或认知能力受损的用户(例如老年人),否则你很可能没有认真考虑过该界面的无障碍性。

我们经常将用户理想化,将他们当成完美无缺、完全可以胜任的人,想象他们在生活中只有一个问题,那就是我们的产品要解决的问题。

因此,我们很少将残障视为潜在的需求点来考虑,从而无法设计出好的无障碍解决方案,这意味着残障人士不太可能使用我们的产品。

这就导致在考虑目标受众时,我们更不会考虑他们……这是一个恶性循环,但 合乎道德的设计流程和定期的无障碍审查是打破这一循环的最佳途径。

残障问题很复杂,它会以多种方式、不同程度地影响一系列技能,且其表现形式因人而异,并随着情况和时间的变化而变化。

因此,无障碍评估并不是一个简单的测试,相反,它是针对一组最常见的障碍对内容、设计和代码进行的整体评估,旨在突出用户最有可能遇到挑战的领域。没有一个界面是 100% 无障碍的,因此无障碍审查是一个持续或完善的过程。

但你所做的每一个改变和解决的每一个问题都会为更多用户打开新的大门。这是一段值得走的旅程!

2.定义框架

无障碍审查通常是依据《 网页内容无障碍指南》 (WCAG)进行的,这是一套国际公认的改善网页无障碍的指南。所有数字界面必须符合 AA 级标准,部分界面甚至需要达到 AAA 级。

WCAG 2.2 原则的基础是:界面必须始终可感知、可操作、可理解。这些原则涵盖界面的内容和设计,以及其背后的代码,这意味着审查将需要项目团队所有成员的参与。

审查的目的是了解视力、听力、行动能力和/或思维和理解能力受损的用户使用界面的能力。它涵盖了最常见的残障类型,但在某些情况下,你可能希望缩小用户范围,研究某类特定用户群体面临的具体挑战。

同样重要的是要记住,并非所有残疾都是永久性的,你应该考虑用户的视觉、听觉或运动技能会受到何种情况的影响。

为此,你应该审查用户旅程的背景,例如:是否有任何任务通常是在旅途中(行动不便)、在黑暗中(视力)、在嘈杂的地方(听力)执行的,从而影响他们的思考和理解。

3.选择正确的方法

进行无障碍评估的方法有四种,可单独使用或结合使用:

  1. 自动评估
  2. 人工评估
  3. 可用性测试
  4. 辅助技术测试

1)自动评估:

有许多免费和付费工具可帮助简化评估流程。有些工具专注于数字无障碍的特定方面,例如 a11y 颜色对比度验证器。

其他工具(如 WAVE) 则可进行全面检查,帮助突出显示复杂界面上难以发现的主要结构问题。W3 还提供了一份全面的网络无障碍性评估工具清单,适用于所有级别和用途的界面。

虽然这些工具是评估过程的良好起点,但它们目前并未涵盖所有的无障碍性性问题,也不应该完全取代人工评估。

2)人工评估:

这是一个根据标准清单对界面进行人工检查和评估,并提出改进建议的过程。我根据 WCAG 关于创建可感知、可操作、可理解的原则,创建了一份内容广泛的检查清单。每个类别都有自己的一套审查任务,例如:

可感知 ,即用户必须能够用他们现有的感官识别和使用界面。

  • 提供音频和视频的文字记录
  • 不要把颜色作为传达某种信息的唯一方式
  • 为非文本内容提供替代文本,或将其标记为装饰性内容
  • 使用在背景颜色下清晰显示的文字颜色

可操作 ,即用户必须能够找到并使用内容,即使他们选择使用键盘或语音命令访问。

  • 确保仅使用键盘的用户也能访问所有功能
  • 让用户可以播放、暂停和停止任何移动内容
  • 不要使用闪烁或闪光的内容 ,或者让用户可以自主选择禁用动画效果
  • 使用描述性链接

可理解 ,即用户必须能够理解内容和功能。

  • 使用常规英语(或其他语言)
  • 明确内容是用什么语言编写的,并说明是否有变化
  • 解释所有缩写和首字母缩略词
  • 确保所有表单字段都有可见和有意义的标签,并正确标注

稳健 ,确保内容能够被各种用户代理可靠地解读,包括合理的、过时的、当前和预期的浏览器和辅助技术。

  • 使用有效的 HTML,以便用户代理(包括辅助技术)可以准确地解释和解析内容
  • 确保代码能让辅助技术了解每个用户界面组件的用途、当前状态以及是否发生变化
  • 确保重要的状态消息或模式对话框以某种方式标记,以便告知用户他们的存在和目的,并允许他们使用辅助技术与他们与之交互

3)可用性测试

通过自动可访问性检查器运行界面可以获得很多信息,而让专家进行逐步审查则可以获得更多信息,但没有什么比观察能力受损的人使用你的界面并获得关于他们所面临挑战的反馈更有意义了!

该过程类似于标准可用性测试:每个用户都需要在界面上执行一系列常见任务,并对效果好的地方和可以改进的地方发表意见。这些环节应亲自进行,以便让观察者准确了解更广泛的背景以及任何屏幕外的工具或交互。

4)辅助技术测试

许多能力受损的用户将依赖辅助技术来帮助他们浏览界面,因此你必须了解这一过程可能是怎样的,以及用户可能面临的挑战。这可以作为人工评估过程、可用性测试或两者的一部分来完成。

4.结论

要获得利益相关者对广泛的无障碍性审核的支持是很有挑战性的,尤其是当你的用户角色不能反映真正的社会多样性时。

虽然对整个界面进行全面的人工审核可能会发现许多无障碍问题,但即使是简短的自动测试也能帮助你更好地服务于更多样化的用户群。

不要被各种可用的工具和技术难倒——这些资源可以让你的团队真正做到以用户为中心,而每一次无障碍性审核、审查或测试都会让你离包容性产品设计的愿景更近一步。祝您好运!

作者:Tiina Golub 译者:章欣怡
审核:李泽慧 编辑:林庭婷
本文由人人都是产品经理作者【TCC翻译情报局】,微信公众号:【TCC翻译情报局】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。