Microsoft包含设计在Visual Studio Code中的影响
当我测试 Microsoft的新源代码编辑器Visual Studio Code时，我自然想到了他们如何在实践中实现该理论的问题。
包容性设计将可访问性设计提升到一个新的高度，因为它从更广泛的角度来看可访问性。
通用或包容性设计是一种新的设计理念，微软最近在软件开发中似乎非常重视 。
这篇文章并不仅要描述Visual Studio Code的可访问性功能，因为在正式文档中您可以找到它们的简要介绍，而只是想成为一个案例研究，以了解在需要时应注意什么将来设计一个包容性应用 。
因为我们可以肯定，包容性很快将成为软件和Web设计的要求，这不仅是出于无私的原因，而且还因为它将吸引许多新用户。
微软的包容性设计四原则
本文讨论了Microsoft的包容性设计的四个原则 （下面简要列出）。
Windows Dev Center将可访问性软件设计放在“可用性”类别中 ，并且他们还发表了许多关于该主题的出色文章 。
- 认为通用 。
- 使其个性化 。
- 保持简单 。
- 创造喜悦 。
因此，我宁愿脚踏实地，删除这些主观含义，并将这些原则转变为客观标准。
如果您通读了原始文章 ，则会发现使用“情感联系” ， “唤起奇迹”和“魔术”之类的表达式以不总是易于测试的方式来解释原理。
当我分析如何在Visual Studio Code中实现它们时，我会在以下意义上使用它们：
- 通用思考：辅助功能
- 个性化 ：可定制性，可扩展性
- 保持简单 ：无干扰的逻辑用户界面
- 创造乐趣 ：功能可发现性
当然，这只是一种可能的分类，并且有很多重叠之处 ，例如可定制性也可以是“创造喜悦”原则的一部分，但是由于我们需要切实的东西，让我们暂时坚持这种解释。
尽管Windows Dev Center建议将这些兼容设计原则应用于Windows 10应用程序，但Microsoft还将其Microsoft Design网站专门用于兼容设计。
尽管Visual Studio Code不仅是针对Windows 10的，而且旨在成为一个跨平台软件 ，但我们仍然可以根据上述原则安全地测试其功能，因为Microsoft显然将包容性设计视为他们将来希望遵循的软件设计路径。 。
通用思维
在“通用思维”原则下，我们将研究Visual Studio Code 对于各种用户组 （例如辅助技术的用户（无论是残障人士还是偏爱者使用），具有有限技术的人，非英语为母语的人）的可访问性等
请注意，从1.1.1版开始，在Windows键盘上， +和–符号在右侧的数字小键盘上不起作用，仅在打字（字母数字）小键盘上不起作用–可能不是最好的包容性。
Visual Studio Code中有一个默认的High Contrast主题 ，可以通过单击“ File > Preferences > Color Theme菜单进行设置，但是也可以从Visual Studio Code Marketplace中下载其他File > Preferences > Color Theme 。
Microsoft 在Windows 7中引入了High Contrast主题，很高兴看到他们遵循了此功能。
有效的键盘导航需要用户仅使用键盘 即可控制软件的 所有功能 。
对于由于视觉或行动不便而无法使用鼠标的人，提供键盘导航至关重要。
Visual Studio Code很好地实现了此功能，尽管它具有许多预设的键绑定 （请参见完整列表 ），但用户还可以借助JSON格式的配置文件来自定义键盘快捷键 。
好消息是Microsoft承认文档的“ 当前已知问题”中缺少此功能。
当前，从1.1.1版开始，VS Code不支持所有区域的选项卡导航，例如，顶部菜单栏不能以这种方式使用。
命令面板F1可以在某种程度上代替它，因为也可以从顶部菜单中找到所有在顶部菜单中找到的命令。
尽管Tab用户无法使用键盘访问顶部菜单栏的功能。
在测试过程中，我发现使用Tab键可以访问Editor ， 侧边栏 ， 视图栏 （请参见VS Code区域的命名 ）及其所有动作和项目。
用户可以通过按Ctrl + M键绑定在两种功能之间切换。
捕获的Tab键可以在VS Code的不同部分之间移动 ，而通常情况下，Tab键可将 Tab键添加到在“编辑器”区域中打开的文本文件中。
选项卡导航的一项重要的可访问性功能是选项卡陷阱 ，它使用户可以在选项卡键的两种功能之间进行切换。
文档提到 VS Code开发团队使用NVDA屏幕阅读器测试了屏幕阅读器的可用性。
当然， 屏幕阅读器用户也需要完全可访问的软件。
为了进行测试，我使用了另外两个屏幕阅读器， JAWS是使用最广泛的屏幕阅读应用程序之一，而Microsoft Narrator是Windows 10的内置屏幕阅读器。
但是，这是Narrator的缺点，而不是Visual Studio Code的缺点，因此我们可以放心地假设视障用户可以使用更高级的屏幕阅读器应用程序来访问所有VS Code功能。
例如，当我用鼠标在顶部菜单项上移动时，它只能正确读取顶部菜单项，而当我在键盘上使用向下箭头时，则不能正确读取。
JAWS会认真地阅读所有区域，命令和菜单，但是讲述人在任务上遇到了一些较小的问题。
开发团队也注意使其具有包容性，因此它还支持Tab和键盘导航，并且可以使用屏幕阅读器。
对于Visual Studio Code， 调试器就是一个很好的例子。
为了使应用程序完全可访问并具有包容性，我们还需要注意那些可能不会首先出现在我们脑海中的部分。
其中之一是本地化 ，或者换句话说，它支持外语作为显示语言 ，因为世界上许多人不是英语母语人士。
现在，我们已经准备好讨论文档中的 VS Code列表的可访问性功能，但是当谈到“ Think Universal”包容性设计原则时，还需要提及其他重要事项。
目前，Visual Studio Code已本地化为10种不同的显示语言 （英语，简体中文，繁体中文，法语，德语，意大利语，日语，韩语，俄语，西班牙语） 。
如果他们想将另一种语言设置为显示语言，则可以轻松配置其locale.json文件 。
来自这些语言的用户甚至无需配置其显示语言，因为VS Code 默认会选择操作系统的显示语言 。
目前，语言不受支持的用户将以英语安装VS Code。
可能有10种显示语言不是很多，但是如果我们考虑到VS Code是一种新软件，这也不错，而且Microsoft将来很有可能会支持更多显示语言。
现代的源代码编辑器并不是很大 ，Microsoft也加入了这种趋势，因为Visual Studio Code的下载量不到100 MB ，磁盘占用空间也不到200 MB。
VS Code满足此要求，因为它也支持Windows，OS X和Linux 。
如果我们要使用包容性软件，那么当然也需要跨平台 ，这意味着它需要在不同的操作系统上运行。
个性化
Visual Studio Code很好地满足了这两个要求，以至于我甚至在这两个方面分别撰写了有关自定义性和扩展性的文章 。
“让它个性化”是Microsoft包容性设计的第二个原则，正如我之前所承诺的那样，我们将在此标准下研究可 定制性和可扩展性 。
简而言之， 可自定义性是通过自定义主题和模块化的JSON格式配置设置实现的，而可扩展性则是通过自定义扩展实现的，用户可以从Visual Studio Code Marketplace下载或在TypeScript或JavaScript中创建自己的 扩展 。
您可以在此处阅读有关Visual Studio Code的可扩展性方法的技术背景的更多信息 。
可定制性的解决方案非常适合精通技术的人，他们是源代码编辑器的典型用户，因为可定制性的重要部分是通过模块化JSON格式的配置文件实现的 。
用户，即使他们不是编码专家，也可以轻松地编辑其自定义.json文件 ，因为Visual Studio Code在彼此相邻的两个编辑器窗格中打开默认设置和自定义设置，从而使用户可以轻松地进行实验。
这是一个很好的解决方案，因为配置选项没有隐藏在难以理解的庞大菜单层次结构后面。
配置文件是模块化的，它们是.json文件的逻辑结构层次结构，下面列出了最重要的文件：
-
settings.json用于自定义用户设置 ，可通过File > Preferences > User Settings菜单访问 -
.vscode/settings.json用于自定义工作区设置 ，可通过“File > Preferences > Workpraces Settings菜单访问 - 用于自定义按键绑定的
keybindings.json，可通过“File > Preferences > Keyboard Shortcuts菜单访问 -
javascript.json，php.json，css.json，c.json，和一堆其他.json设置的自定义用户对于片段不同的编程语言文件，通过访问File > Preferences > User Snippets菜单 - 用于自定义调试器设置的
launch.json，可通过单击Debug View顶部栏上的齿轮图标（在编辑器左侧）进行访问 -
.vscode/locale.json用于自定义显示语言设置 ，可通过在命令面板（ F1 ）中键入“Configure Language命令来访问 -
.vscode/tasks.json用于自定义任务运行程序设置 ，可通过在命令面板（ F1 ）中键入“Configure Task Runner命令来访问
我认为VS Code用户几乎不会抱怨可定制性，因为即使列出选项也是一项详尽的任务。
因此，他们将拥有更加直观的工作流程。
由于配置选项是模块化的，因此用户只需要照顾他们真正需要的内容 ，这有助于他们专注于要执行的任务。
把事情简单化
对于此运行上下文，我们将继续关注用户界面的简单性 。
在编程和设计的许多其他地方，我们都可以满足Microsoft的Keep It Simple包容性设计原则，只需考虑KISS （保持简单，愚蠢）设计原则和DRY （不要重复自己）软件开发原则即可。
由于Visual Studio Code是源代码编辑器，因此它可能不是具有此类缺陷的人经常使用的软件，但是可能还会出现一些灰色区域。
在可访问性方面，由于存在认知和智力障碍的用户，通常建议使用易于使用的简单用户界面。
但是，简单性不仅因为它们而重要，因为设计良好的逻辑界面还可以降低学习曲线 ，并提高工作速度 ，从而使软件也对一般人群更具吸引力。
Visual Studio Code还利用了众所周知的心理现象，即单纯曝光效应 （或熟悉现象 ），因为它采用的基本布局与其他知名源代码编辑器（如Atom）使用的布局相似。
从文档中我们可以了解到，这是微软的一项巨大努力：
VS Code还为用户提供了“并排编辑”功能，该功能也可以在其他源代码编辑器中找到，这不是巧合，因为它使编码过程变得更加简单 ，并且当然有助于“保持简单”设计原则。
除了基本的UI之外，Visual Studio Code还具有一些很酷的功能 ，值得一提的是关于包容性设计的文章，例如：
- Intellisense根据上下文为用户提供建议（使用人工智能的后端部分也是一个不错的解决方案）
- 窥视 （ Shift + F12 ）在嵌入式窗口中显示完整的功能定义
- 命令面板 （ F1 ），使所有命令都可以在同一位置访问。
创造喜悦
找到可用于检查“创建欢愉”的包容性设计原则的具体标准并不是一件容易的事，因此我最终选择了功能可发现性的标准，因为微软通过以下方式定义了该原则：
这种表述可能会让您想起许多微小的时刻 ，这是Google最新的重大事件之一，因此可以说明领先的科技公司在考虑如何推动行业发展时可能会得出类似的结论。
就在正确的时刻 ，而不是之前，之后。
在包容性设计中， 吸引用户并引起他们的好奇心非常重要，如果我们能够帮助他们在达到用户旅程的某个特定点时向前迈进 ，那么我们可以取得最大的收获。
当我们谈论功能可发现性时 ，它是创造愉悦感的一种更世俗的表现，可以通过精心设计的实用程序导航 ，智能文档和仅在适当时机出现的支持信息来增强功能。
您需要自己判断使用Visual Studio Code是否会让您感到愉悦。
我们可以在Visual Studio Code中找到所有这些功能的示例，只需考虑前面提到的IntelliSense和Command Palette ，但是语法突出显示和自定义代码段也可以帮助用户充分利用该软件。
就我自己而言，我或多或少喜欢这种体验： 结构合理的在线文档 ， 易于导航的Visual Studio Code Marketplace和可在滚动下拉列表时实时预览的自定义颜色主题 （访问通过“ File > Preferences > Color Theme菜单）。
最后的话
我认为，Microsoft通过定义包容性设计的四个原则取得了重要的里程碑。
由于包容性设计是一个新领域，因此技术行业仍处于试验阶段。
正如我们已经看到的那样，尽管仍然需要改进一些领域，例如提供完整的Tab支持以及全局的Search and Replace功能 ，他们还是设法在新的源代码编辑器Visual Studio Code中成功地实践了这一理论。
以下资源可能会有所帮助：
由于可访问性和包容性都是用户体验的一部分 ，因此，如果您想了解最新的行业趋势，则最好对它们进行更多了解。
- Windows Dev Center的辅助功能文章
- Microsoft Design的Inclusive Design Toolkit手册（PDF） （可下载）
- Hongkiat.com 辅助功能标签
翻译自: https://www.hongkiat.com/blog/microsoft-inclusive-design-vscode/