无障碍设计(三)-听觉与行为无障碍设计

发表于: UI设计者 – 一个免费自学UI设计APP · 2018-1-30  · UI设计师投稿  ·  728 views  · 

四. 听觉无障碍设计

「听觉障碍」包括:听不清/听不到到界面发出的声音。

设计要点:

  • 让文本内容容易被理解,适当使用「文字替代」( text alternatives )。
  • 确保界面上的所有空间,在没有声音时(without sound),仍可正常使用。

五. 行动无障碍设计

「行动障碍」包括:不能操作鼠标、键盘、或触屏。

设计要点:

  • 确保所有界面控件交互都可只通过键盘完成 或者只使用鼠标;
  • 确保界面控件被辅助技术 正确标记;这些用户可能会使用诸如语音控制软件 和物理切换控制 等技术,这些技术一般使用与屏幕阅读器 等其他辅助技术相同的API。

1. 提供可用键盘控制的「获得焦点」显示状态

有些用户在使用web 产品时,不方便使用鼠标,如果 web 产品可以仅通过键盘操作,会为其带来更好的使用体验。

设计师可以设计一种符合本网站风格、同时能提供明显视觉线索的「获得焦点」状态指示,而不是仅仅使用浏览器的默认样式。

Focus highlighting 应该只被用于页面中的可交互元素,如输入框、按钮等。

 

但问题是许多网站并没有自己设计一种「获取焦点」状态的视觉样式,这对于以使用键盘为主要浏览方式的用户来说,体验很不好。主要因为效果太丑,而非不满足「无障碍设计规范」。

 

下面例子是 BBC 的,用「blue bar」指示哪一个tab是当前的「获取焦点」状态。

 

下面是 Twitter 的例子,采用了3中方式结合的办法,显示「获取焦点」状态:

  • 默认蓝框框。
  • icon由灰变绿。
  • tooltip。

提供了充足的视觉指示。

 

2. 弹窗

使用弹窗时注意,焦点元素要在弹窗内,而非在弹窗背后。

左边错误做法:用户没法与弹窗交互;

右边正确做法:焦点落在2个按钮上,用户可选择相应操作,或者关闭弹窗。

3. hover 时的焦点状态

如果一个元素需要hover 才能显示更多操作,那么当键盘控制焦点落在该元素上时,要显示出hover 触发的更多操作

好范例:facebook。

 

keyboard only users 把焦点落在 「like」上时,会显示出 hover 时展示的更多表情。

反例:Product Hunt。焦点落在「share」「save」控件上时,不显示任何hover触发的更多操作。

 

下面是正误两种做法的比较:

左边错误做法:Focus states 完全忽视 hover actions,直接跳到下一个 focus element。

右边正确做法:Focus states 允许用户与hover 触发的动作交互。

还有一个比较好的例子是 Gmail:

 

每个条目在「焦点状态」时:

  • 都有特定的、明显的状态区分(左侧的 blue bar)。
  • hover 时的更多操作,在「焦点状态」时自动显示。
  • 只有可操作控件有「焦点状态」。

4. 快捷直达内容的操作

对于仅用键盘的用户,如果每次都让他们依次选中每个控件才能到达内容,使用起来是很痛苦的。

比如这个blogging 平台:

 

比较好的做法是在最开始,提供一个捷径,让焦点直接跳转至内容。

比如 AirBnB 这样:

 

左边:获得焦点之前的普通状态。

右边:激活「获得焦点」在最开始提供一个选项,直接跳转至内容,无需依次路过每一个tab菜单。

5. 重新获得焦点的场景(re-focus)

当一个控件从界面上被删除后,焦点应该显示在「周围与被删除相关」的控件上。

不好的做法是删除一个元素后,让焦点从当前元素消失,回到页面顶部。这样的话,用户得重新走一遍 focus 从顶部移动到当前位置的过程。

左边错误做法:的删除「1」后,焦点消失。

右边正确做法:删除「1」后,焦点显示在「2」上。

6. 保持使用的一致性

这是「无障碍设计」中一个很重要的问题。

详细可参考 W3C’s Authoring Practices for Design Patterns有做详细解释。这是关于如何创建许多常见设计组件的「无障碍设计」指南,包括菜单、对话框、自动完成内容、树形结构等。每种组件模式都有一套相应的 HTML 语言、键盘操作,和 ARIA 属性。 ARIA 属性说明了用户如何使用键盘与屏幕上的组件交互。

自动完成输入模式 :用户在输入框输入一些内容,下面自动显示一列经过筛选的相关结果。用户可以用上下箭头或者鼠标定位或选择列表中的一个项目。

下面看下「自动完成输入」的例子:

 

下面这种是前面加了 icon 的自动完成输入显示的列表:

 

下面是个混乱的自动完成模式案例:用户不仅可以从过滤的列表中选择一个项目,还可以通过点击「铅笔」或「垃圾桶」图标来编辑或删除每个列表项。 这两个按钮的添加让「自动完成」输入模式变得混乱。

 

问题主要因为:打乱了自动完成输入模式的键盘使用行为。「选择」+「操作」的双重操作容易造成使用混淆,也不便于键盘控制。

相似的规则也适用于menu。

下面的2个例子中,右边的才是真正的 menu,左边的其实是个 non-modal dialog(非模态对话框)。(根据 W3C’s WAI)

Menu 是一种 为用户提供一列选择的 widget。如果我们为每一行加进多重操作(像左边例子),那它就不再是 menu 了。这也会改变键盘的操作行为,从单纯使用 arrow key,到 还需使用 tab key;同时也会改变键盘获取焦点的处理方式,比如当 dropdown 收起后,键盘获取焦点的显示位置就不同。

若能弄清两者区别,以及对用户体验的影响,非模态对话框也可以做到满足「无障碍设计」标准。理解一个微小的设计变化,如何改变用户交互模式,会帮助你为自己的产品选择合适的交互模式。

六. 认知无障碍设计

「认知障碍」意味着用户可能需要辅助技术 来帮助他们阅读文本,因此文本替代方案 的存在非常必要。

设计要点:

  • 避免重复或闪烁的显示方式,因为这可能会为认知障碍用户造成使用不便 。
  • 给用户留出充足的时间操作 。

七. 「无障碍设计」自查清单

 

  • Visual:界面上的控件、文字的对比度是否满足 WCAG 最低标准?界面去掉颜色后是否可以正常使用? 确保你的 UI 组件可以被不能辨识颜色的用户使用。 一个叫 SEE 的 Chrome 扩展程序可以模拟色盲用户看到的界面,Daltonize extension 也有类似功能。
  • Visual:界面组件可以在「高对比度模式」下工作吗?现在时下常用的操作系统都支持高对比度模式。「High Contrast」是一个 Chrome extension ,可以模拟测试。
  • Visual:可以用「屏幕阅读器」使用所有 UI 控件吗?是否提供了所有可见文本信息的 文本替代方案 ?你用 ARIA 增加了语义信息吗?
  • Hearing:你的用户界面组件可以无声地工作吗? 关闭扬声器全工程使用测试下。
  • Motion:所有 UI 控件,是否可以只通过键盘操作?是否能避免用户陷入「焦点陷阱」(focus traps)?能否对键盘操作做出合适响应?

最后

Web 的一大作用就是更好地实现了人与人之间的交流与合作,「无障碍设计」在其中扮演着重要的角色。

也许你觉得在你的设计中要考虑这些种种规则,限制了你的创造力。

但如果这些规范限制将你的创造力推向极限,你就很有可能会做出既美观,同时还能满足更广泛人群使用的设计。如果关注点正确,你就会发现在任何挑战面前,都可以去寻找一系列解决办法,去满足主管、营销团队、Dribbble followers、等所有用户包括残疾人的需求。

将问题分解为可实施的小任务,可以一步步接近终极目标。比如,使用「对比度测试工具」测试你的色板,进而选用对比度更科学的颜色;写容易理解的文字;使用容易看清的字体;把内容规划得清清楚楚,让不同模块之间一致连贯;尽量减少设计中的杂乱等分散注意力的东西;写有用的说明文案……

改善所有你能改善的,影响团队中的其他人,很快,你就会感觉到你的产品越来越好。不要低估自己所能做的改变。

Angelaaa 产品设计 | 公号「漫声细语」UI设计者APP整理

本文链接: http://www.shui-mai.com/wuzhangaishejisan-tingjueyuxingweiwuzhangaisheji/