vs wps用户界面设计_面对视障用户，交互设计该如何应对？

2019年是游戏行业无障碍意识的突破性一年。

我们看到了一些大型系列游戏跃上了新闻出版物的头版(如Forza, Gears of War, Spiderman & Tom Clancy)。我们看到平台所有者也加入了行动，微软甚至将“当每个人都玩的时候，我们就都赢了”的口号融入到它的商业战略中。

对我来说，19年4月的游戏UX欧洲峰会是一个转折点。Ian在会议上发表了演讲，内容是关于2017年游戏发行版中可访问性的最新进展，其中包括一些有趣的数据，关于可访问性游戏设计如何惠及所有玩家，而不仅仅是那些需要它的人。

我想讨论一下菜单屏幕的交互设计，让那些没有视力或有严重视觉障碍的玩家可以访问。这样，我们的交互设计师就可以创建一个界面，任何人都可以使用它来实现自己想要的功能。

存在的问题

在对没有视力的游戏玩家进行了一些初步研究后，我们发现，当视觉受损的玩家与菜单屏幕交互时，他们会面临一系列挑战:

- 我现在在什么菜单屏幕上?

- 我当前正在选择什么选项，我如何与它交互?

- 我在这个屏幕上还有其他可用的操作吗?

- 按钮有什么作用吗?

Icon Artwork in the Background from Microsoft Design’s Inclusive Design website

无论我们设计的解决方案是什么，都必须尽可能地消除这种摩擦，这样用户才可以舒适地使用，而不需要视觉上的帮助或猜测。

解决方案

我们选择建立一个“解说系统”，根据当前的屏幕信息和当前选择的项目，向播放器大声朗读菜单文本作为音频。这个概念并不新鲜，因为web、桌面和移动应用程序已经尝试过一段时间了，但是在使用focus并不能获得所有需要的信息的情况下，正确地使用focus是一种挑战。

在用户体验中，渐进式公开是这样一个概念:当用户较少使用的功能在视觉层次结构中被回推，或者被推到次要屏幕上，以确保主要功能在前面和中间。我们可以把这个概念应用到我们的叙事系统设计中;我们计划首先揭示所有最简单和最重要的信息，然后如果玩家仍然在等待正确的信息，我们才会添加额外的内容。

进入新屏幕

当玩家进入一个新屏幕时，他们需要知道自己在哪个屏幕上，有哪些选项需要导航或与之交互，以及需要按哪些按钮，他们还需要确认他们之前的操作是否正确。

考虑到渐进式披露，新玩家在进入屏幕时可以从容应对更多的上下文信息，而有经验的玩家则可以通过提前采取行动来快速打断叙述并快速浏览菜单。这对菜单屏幕意味着什么呢?

让我们来看看一个假想的设置屏幕: 动画GIF的设置屏幕，显示所有领域的信息。

Image of Settings screen, showing all areas of information we need to read for the player when entering a new screen.

当玩家进入屏幕时，它应该首先阅读屏幕标题。这是为了确认它们在屏幕流中的实际位置。

如果有一个子菜单或标签系统，它应该阅读选择标签类别标签和如何改变它，以便玩家知道有更多的内容在这个屏幕上比简单的导航会显示。

在我们的UI中，默认情况下列表中的第一个元素是焦点。这意味着默认的焦点交互元素将叙述文本标签、UI控件类型、值和工具提示说明(如果可用)。

一旦所有的集中叙述都完成了，我们就会在这个屏幕上添加所有可用的全局上下文动作的叙述，这样玩家就知道当他们拥有所有信息时该如何继续下去。

全局上下文操作显示在按钮提示的容器中，通常称为屏幕底部的操作栏。这告诉玩家按下哪个按钮来与当前聚焦的项目进行交互，或者如何访问一个全新的子菜单。例如，如何更改选定设置的值，或如何打开全局文本聊天覆盖。

下面是一个系统图，它是如何工作的:

重新选择

在任何时候，玩家可以通过将他们的选择移动到屏幕上的一个新项目来打断之前的叙述。当这种情况发生时，我们便会停止叙述，转而只播放新的重点项目信息，然后再次出现动作栏提示，以防玩家在跳过导航时错过它们，也以防提示根据所选项目而发生变化。

Image of Settings screen, showing what we need to read when the player changes their selection.

下面是另一张图表，展示了它是如何工作的:

Systems diagram for how the narration system works when a player selects a new option.

更改选项的值

如果玩家可以改变一个选项的值，并且他们这么做了，那么新值应该被读出，然后是与新值相关的工具提示信息(如果这是可用的)。在这里，我们可以更详细地了解每个值的作用，因为我们知道如果玩家在这个级别进行交互，那么他们将寻找关于新设置的信息。

Image of Settings screen, showing what we need to read when the player changes a value for an option.

我们确保再次读取操作栏提示，以防出现与值相关的新提示(虽然这是一种罕见的用例，但是再次提供信息没有害处；大多数不需要它的玩家这时已经完成了交互)。

Systems diagram for how the narration system works when a player changes an option.

UI状态改变

在UI中可能会发生一些事件，这些事件可能会在某个不确定的时间点触发状态更改，例如好友邀请或安装过程。这些内容应该对视觉受损的玩家开放，但是当玩家在你的界面上做其他事情的时候，这些内容应该如何被描述是一个挑战。

我们应该中断当前播放的叙述，告诉他们这个新的状态变化吗?在叙述不确定进程的情况下，我们应该多久提醒玩家一次更新的值?是否应该平等对待所有的状态变化?

这种方法可能会根据你的游戏而有所不同，但我们决定对它们一视同仁，以建立与玩家期望叙述在UI中的表现相一致的方法。详见下图：

Systems diagram for how the narration system works when a state in the UI changes.

我们不会选择中断播放器，因为我们觉得我们的状态变化没有实时导航更新重要。如果状态更新表示不确定的进度，比如加载栏，我们还可以选择基于计时器的状态更新。这使得UI能够在进度条快速移动时提供给玩家常规更新而不会让他们感到压力。

屏幕阅读器支持vs综合叙述

我想简要地讨论一下我们为实现旁白所采取的一些方法，包括设计者应该注意的两种系统的优缺点。

屏幕阅读器支持

屏幕阅读器支持允许外部第三方程序，如NVDA或微软的内置叙述者，访问你的界面的UI树信息，并尝试代表播放器读取呈现给它的信息。

这对玩家有许多好处，因为它允许玩家使用现有的屏幕阅读器，并具有定制的阅读速度、旁白声音和详细程度。这也意味着国际化的内容更容易，因为玩家的屏幕阅读器引擎将处理他们当地语言的叙述。

然而，在撰写本文时，只有Windows和Xbox平台允许玩家使用，而其他一些平台还没有屏幕阅读器功能。这意味着多平台游戏应该仔细考虑这种方法，并在投入之前做一些研究，因为这可能被证明是更有价值的。

综合叙述

综合叙述是一个过程，运送一个语音合成器引擎与游戏客户端，并有你的游戏代码接口直接与它。

这对开发人员有很多好处，因为它可以在传递给它的字符串完全定制时，对读出的内容提供更多的控制。这也是一个更好的跨平台选择，因为游戏是负责叙述，而不是平台功能或第三方程序。它还可以用于任何需要的反馈系统，而不仅仅是UI。

然而，由于缺乏叙事速度、声音和细节水平的可定制性，玩家的收益并不好。需要考虑语言支持，这可能会改变客户端大小，因为任何语音合成器引擎的目标是多语言将需要与各种语音包。

也可以使用云服务，比如微软的Playfab套件，来卸载基于玩家区域设置的语音合成。这意味着一个字符串可以推送到服务中，它会为播放器返回合成音频。这就会产生一种即付即用的服务成本，并需要玩家始终在线才能访问他们的游戏，这可能会成为玩家的一个障碍。

如果整个用户界面都不能被叙述呢?

如果一个或多个特定的屏幕由于某种原因不能被正确地叙述，当玩家进入屏幕时，你最好让你设计的解说员喊出来。这有助于他们理解这个屏幕上的导航不会为他们做任何事情，这不是用户的错。

总结

在为我们的游戏设计旁白系统时，真正让我感到震撼的是它的复杂性和信息的缺乏。我们的大部分工作都是从零开始的，这也是我写这篇文章的最大动力。

原文链接：https://medium.com/