构建更易访问的GitHub CLI:终端无障碍化实践

本文详细介绍了GitHub团队如何将Web无障碍标准应用于命令行界面,通过改进屏幕阅读器支持、色彩对比度和自定义选项,让GitHub CLI成为所有开发者都能使用的工具。文章包含具体技术实现方案和实际案例演示。

在GitHub,我们致力于让所有开发者都能真正使用我们的工具,无论能力或工具集如何。命令行界面(CLI)是开发者体验的重要组成部分,GitHub CLI是我们的产品,它将GitHub的强大功能带到了您的终端。

在无障碍性方面,终端与Web浏览器或图形用户界面有着根本区别,其历史可追溯到Web本身之前。虽然像Web内容无障碍指南(WCAG)这样的标准为Web和图形应用程序的无障碍化提供了清晰路径,但对于终端和CLI来说,并没有等效的全面标准。W3C为非Web软件提供了一些高级指导,但并未规定具体技术,留下了许多需要解释和创新的空间。

这一差距挑战我们以创造性和有目的性的方式思考终端中的无障碍性应该是什么样子。我们最近的公开预览版专注于满足三个关键群体的需求:依赖屏幕阅读器的用户、需要高背景文本对比度的用户,以及需要可自定义颜色选项的用户。我们的工作旨在让GitHub CLI对所有用户更加包容,无论您如何与终端交互。运行最新版GitHub CLI中的gh a11y命令可启用这些功能,或继续阅读了解我们设计和实现这些功能的路径。

理解终端环境

基于文本和命令行的应用程序与图形或Web应用程序有着根本区别。在网页上,屏幕阅读器等辅助技术利用文档对象模型(DOM)来推断页面的结构和上下文。网页可以设计成DOM结构对这些技术友好,而不影响页面的视觉设计。相比之下,CLI的主要输出是纯文本,没有隐藏标记。终端模拟器作为文本应用程序的"用户代理",按照服务器应用程序的指示渲染字符。辅助技术访问这个字符矩阵,分析其布局,并尝试推断结构。正如WCAG2ICT指南所指出的,此领域的无障碍性意味着确保所有文本输出对辅助技术可用,并且结构信息以程序可确定的方式传达——即使没有显式标记存在。

在改进GitHub CLI对盲人、低视力用户和色盲用户的可用性过程中,我们发现自己 navigating 一个有很多指导但具体实施无障碍体验技术很少的领域。我们研究了辅助技术如何与终端交互:屏幕阅读器如何审查输出,颜色和对比度如何自定义,以及结构线索如何从纯文本中推断。我们最近的公开预览版包含了对这些领域中各种用例的探索。

重新思考屏幕阅读器的提示和进度

GitHub CLI作为命令行应用程序的优势之一是其丰富的提示体验,为我们的用户提供了一个交互式界面来输入命令选项。然而,这种丰富的交互体验对语音合成屏幕阅读器构成了障碍:非字母数字视觉提示和为视觉效果不断重绘屏幕的使用,可能难以正确解释为语音。

为了减少混淆,让盲人和低视力用户更自信地回答问题和导航选择,我们正在引入一种提示体验,使语音合成屏幕阅读器能够准确向用户传达提示。我们的新提示器使用Charm的开源charmbracelet/huh提示库构建。

另一个为视觉效果重绘终端的用例是显示进度条。我们现有的实现使用通过重绘屏幕显示不同盲文字符的"spinner"(是的,我们欣赏这种讽刺)来向用户指示命令正在执行。语音合成屏幕阅读器无法很好地处理这一点:

这已被替换为静态文本进度指示器(在可能的情况下带有与所执行操作相关的消息,否则回退到通用的"Working…“消息)。我们正在努力确定可以进一步改进上下文文本的其他领域。

颜色、对比度和自定义

颜色在终端中不仅仅是装饰:它是突出显示信息、发出错误信号和引导工作流程的重要工具。但颜色也可能成为障碍——如果终端背景颜色与显示文本颜色之间的对比度过低,某些用户将难以辨别显示的信息。与Web浏览器不同,终端的背景颜色不是由应用程序设置的。该任务由用户的终端模拟器处理。为了保持对比度,命令行应用程序考虑这一变量非常重要。

我们用于渲染Markdown的旧颜色调色板未考虑终端的背景颜色,导致在某些情况下对比度较低。

颜色本身也很重要。不同的终端环境具有不同的颜色能力(有些支持4位,有些支持8位,有些支持24位等)。无论能力如何,终端都使用户能够自定义其颜色偏好,选择如何显示不同的色调。然而,大多数终端仅支持更改有限子集的颜色:即ANSI 4位颜色表中的十六种颜色。GitHub CLI已做出广泛努力,将我们的颜色调色板与4位颜色对齐,以便用户可以使用其终端偏好完全自定义其体验。我们在决定使用哪些4位颜色时,建立在Primer开创的无障碍性基础之上。

为CLI社区构建

我们的改进旨在支持广泛的开发者需求,从需要屏幕阅读器的盲人用户,到需要高对比度的低视力用户,再到需要可自定义颜色选项的色盲用户。但此公开预览版并不标志着我们团队对使所有开发者都能使用GitHub CLI的承诺的结束。我们打算让我们的扩展作者更容易实现我们对核心CLI所做的相同无障碍改进。这将允许用户在所有GitHub CLI命令(无论是官方维护还是社区维护)中获得一致的体验,以便更多工作流程可以默认无障碍。我们还在研究如何自定义命令输出的表格格式,以便屏幕阅读器更轻松地读取/解释。我们很高兴继续我们的无障碍之旅。如果没有与Charm的朋友以及GitHub无障碍团队同事的合作,我们不可能取得如此进展。

征集反馈

我们邀请您帮助我们实现使GitHub CLI成为所有开发者体验的目标:

  • 试用:将GitHub CLI更新到v2.72.0,并在终端中运行gh a11y以了解如何启用这些新的无障碍功能。
  • 分享您的经验:加入我们的GitHub CLI无障碍性讨论以提供反馈或建议。
  • 与我们联系:如果您有与我们无障碍人物角色相关的生活经验,请联系无障碍团队或参与我们的讨论小组。

展望未来

为命令行调整无障碍性标准既是一个挑战,也是一个机遇。我们致力于分享我们的方法,向社区学习,并帮助为无障碍CLI工具设定新标准。

感谢您与我们一起构建更易访问的GitHub。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计