nolan
2021 年2 月 2 日 13:17
1
大家好，
不确定这个问题是否已知或已被跟踪。如果是，欢迎提供相关链接。不过，虽然情况正在改善，但使用屏幕阅读器访问 Discourse 仍存在一些挑战，我想在此记录下来。
我是一名屏幕阅读器用户，原本计划搭建一个主要面向视障用户的自托管实例。通常情况下，由于无障碍问题，我并不推荐使用 Discourse。但你们让自托管变得非常简单，并提供了我所需的功能，因此无障碍功能尚未完善让我感到遗憾。以下是我遇到的一些挑战：
被屏幕阅读器识别为 HTML <select/> 的下拉菜单几乎完全无法正常工作。它们可以通过常规键盘操作展开，但无障碍支持仅此而已。问题在我设置过程中选择语言时就开始了。我不确定默认是否已选中“英语：美国”，但当我去检查时，已不小心将语言设置为西班牙语，且很难改回来。最终，我通过屏幕阅读器找到了列表并成功修正。不过，几乎每个下拉菜单都有问题。我不想说“所有”，因为也许界面某个偏远角落还有能正常工作的，但我尝试过的每一个都完全无法使用。
我无法找到进入管理界面的方式，除非直接导航。设置界面告诉我它在齿轮图标下，但我找不到该齿轮图标的文本表示，而且我发现的任何可通过键盘访问的控件似乎都无法最终链接到管理界面。目前我直接访问 /admin，但这让我怀疑还有哪些工具因为我找不到这个齿轮而未被发现。
与设置下拉菜单相关，我无法使用分类列表顶部的下拉/选择控件来导航到分类列表。我知道有“分类”链接，这通常是我使用的方式。但如果那些选择器能正常工作就好了。
每当有人未注册 Discourse 时，系统会提示其注册，部分原因是论坛会记住阅读进度。但这从未在我的屏幕阅读器上成功过。它本应如何工作？点击链接是否应将焦点移到我最后阅读的那篇帖子？
这与我的站点无关，但此处的模态注册体验也存在一些挑战。我尝试通过电子邮件注册，但你们的实例拒绝了我使用近 17 年的 .info 邮箱地址，而该地址在我自己的服务器上一直正常工作。随后我通过 Google 注册，但返回时出现的模态窗口带来了一些挑战：
它未获取键盘焦点，因此我必须手动寻找并与之交互。
在我尝试操作时，无限滚动的主题列表不断添加新主题，使得焦点更难到达对话框。我不记得具体是如何比主题出现得更快找到它的——我还没喝咖啡呢——但我确实成功了。
因此，我有几个问题：
如果可能，我真的很想继续使用 Discourse。我能在自己的站点上修改多少内容？特别是：
能否移除分类列表选择器，让用户必须通过“分类列表”链接进行交互？
能否移除新建主题页面上的分类选择器，让用户必须先选择要发布的分类，从而避免意外发布未分类帖子或产生混淆？
能否以方便升级的方式同时实现以上两点？如果没必要，我不想编辑默认模板或分叉项目，也不希望完全采用新主题。
这项工作是否在任何地方被跟踪？是否有人专门负责推进？Discourse 论坛正在吞噬互联网。无论我转向何处，我参与的项目或社区都在采用它。甚至作为一名视障用户，我 也想运行 Discourse，因为你们让这一切变得如此简单。我只是不希望这样一个关键工具的无障碍功能要么被忽视，要么永远处于追赶新开发的被动状态。
感谢阅读。
29 个赞
pmusaraj
2021 年2 月 2 日 15:52
2
这是一篇深思熟虑的帖子，@nolan 。我相信其他团队成员也会回应你的问题，但能否分享一下你的环境设置，以便开发人员尝试复现你遇到的问题？例如，你使用的是哪个操作系统、哪款屏幕阅读器等等。
11 个赞
nolan
2021 年2 月 2 日 16:22
3
Windows 10，NVDA 屏幕阅读器。不过，委婉地说，该问题已严重到很可能在任何环境下都无法正常工作，因此几乎任何操作系统与屏幕阅读器的组合都可能遇到此问题。
11 个赞
感谢您的反馈！我们深知在无障碍访问方面还有改进空间，近期已加大相关工作力度。2020 年底，我们委托第三方对 Discourse 最重要的非管理员页面进行了无障碍性审计，并在过去几周开始着手解决高优先级问题。
您提到的这一点确实有道理，找到管理员菜单可能比较困难。该菜单链接位于主标题菜单之一内，其 aria-label 为“前往其他主题列表或分类”，这显然未能清晰表明其中包含几个管理员链接。
关于“Discourse 会记住您上次离开的位置”这条提示，预期行为是：当您进入主题时，应直接跳转到您上次阅读的位置。我刚刚尝试用键盘导航，确认当前焦点并未放置在正确的位置。
我们的许多下拉菜单采用自定义实现，这也是被指出需要改进无障碍性的领域之一。我们也意识到，我们的模态框未实现焦点捕获，导致部分内容难以访问，尤其是在您遇到的具有无限滚动功能的页面上。
关于您提出的继续使用 Discourse 的问题：您列出的所有功能均可实现；只需几行 CSS 代码即可隐藏这些元素。该 CSS 需置于主题中，但可以放在主题组件内，该组件可添加到任何现有主题上（因此您无需更改主主题）。主题更便于升级，因为它们位于 Discourse 之上；而像您提到的直接编辑模板或分叉代码，会使后续更新变得非常困难。
我们在 Meta 上将无障碍问题报告标记为 accessibility
非常感谢您提供的反馈，尤其考虑到发布这些反馈需要额外付出努力。希望在接下来的几个月里，Discourse 能变得更容易使用。
17 个赞
aschrijver
2021 年2 月 5 日 18:36
9
我在 Fediverse 讨论 中收到了 Robert Kingett 的提问，他是一位有视觉障碍的用户，个人简介中标注为“无障碍加速主义者”。他的问题是：
你们如何让 Social Hub 对屏幕阅读器和其他残障人士（包括癫痫等）可访问？
由于 SocialHub 基于 Discourse 运行，而该问题涉及本平台的无障碍问题，我提议将此讨论线程复制为 Markdown 文档并托管在 GitHub Gist 中。以下是该文档链接，可供其他视障人士使用：Accessibility: Discourse with a screen reader · GitHub
4 个赞
nolan
2021 年2 月 5 日 18:40
10
此外，如果尚未提出此问题，我想将其作为一个快速提升无障碍性的建议：
屏幕阅读器能很好地利用 HTML5 的许多语义标签。我不仅可以高效地在它们之间导航，它们还能告诉我当前所在的内容类型。
如果帖子能放在 <article> 元素中，其标题和页脚分别使用 <header> 和 <footer> 元素，那就太好了。如果直接替换元素不可行，适当使用 role 属性也能传达相同的含义。
目前，阅读长线程颇具挑战性。在第一篇帖子之后，我必须滚动跳过包含推荐主题等内容的区域。随后我只能线性地阅读后续帖子，无法跳过那些我已听过无数遍、除日期外毫无变化的相同标题，或是包含相同消息控制按钮的页脚。当然，还有一些高级的 ARIA 调整能让体验更好，但在我看来，替换标签或使用角色属性是一种低投入、高回报的解决方案。
谢谢！
8 个赞
我们审查队列中有一项更新，将为主题页面添加一些 ARIA 标记。根据规范，似乎应为帖子下方的控件以及页面底部的工具栏区域添加 toolbar 角色标记。
此外，我们还有一个主题时间线工具栏区域，它充当滚动条（我已为其添加了 scrollbar 角色），并包含“跳转到首帖”和“跳转到末帖”按钮（我已为这些按钮添加了描述）。
这些更改预计将在下周的 Discourse 更新中提供。
7 个赞
nolan
2021 年2 月 13 日 12:06
12
太棒了，很期待！
这可能是不言而喻的，但我还是要提一下。请注意，仅仅在这些控件上添加 ARIA 属性是不够的。换句话说，如果将这些区域标记为工具栏，却不遵循 工具栏模式 ，其效果可能比完全不加角色还要糟糕。如果我进入一个工具栏，我会期望它能表现出某种行为，而仅仅添加角色并不会自动实现这些行为。我只想强调这一点，因为我在添加无障碍功能时经常看到的一个错误是：添加了这些角色，却没有添加相应的键盘行为。结果，我遇到了一堆不符合预期的控件，不断在这种期望落空中挣扎，这比从一开始就没有这些期望更糟糕。
希望这能说得通。如有其他问题，我很乐意解答。
9 个赞
MarcoZehe
2021 年2 月 13 日 17:01
13
嗨 Chris，scrollbar 角色 可能并不完全符合你的需求。我们需要在实际使用中观察一下，但到目前为止，我尚未见过这种用法。它更像是 HTML5 中的 range 元素，用于表示容器的相对滚动位置。“跳转到首帖”和“跳转到末帖”项目只是可以滚动视图的普通按钮，但我认为这些按钮不适合作为滚动条容器的内容，因为滚动条容器需要包含 aria-value* 属性。
附言：在 VS Code 社区中，我被称为 ARIA 角色专家。我不确定是什么让我获得了这个声誉，但我以对角色选择挑剔而闻名。角色使用不当可能弊大于利，因此这一特定更改可能不得不回退。我几乎可以肯定它会这样。
7 个赞
nolan
2021 年2 月 13 日 17:41
14
出于好奇，想问问贵团队是否有专注于无障碍功能的人员？我对最近的无障碍功能审计以及计划中的改进感到兴奋，但 Discourse 驱动着互联网上的大量服务，因此最好有一位具备一线实战经验的人员参与并指导这些改进工作。在无障碍领域，很容易出错，甚至无意中让情况变得更糟。
举个例子，Slack 声称关注无障碍功能，也确实尝试使用 ARIA，但他们的实现似乎导致聊天区域对我的屏幕阅读器完全不可访问。或者，如果确实可访问，以我几十年的使用经验，我也无法弄明白。
无论如何，我以此为生，也从事类似工作，随时可以提供帮助。同时，我也使用多个 Discourse 论坛，因此确保无障碍功能对我而言是一项切实的生活质量提升。
8 个赞
@MarcoZehe 关于我们的时间线控件，我曾在“滚动条（scrollbar）”角色和“滑块（slider）”角色之间犹豫不决。最终我选择了滚动条角色，因为该控件确实会滚动页面，且符合 W3C 给出的描述：
一种图形对象，用于控制查看区域内内容的滚动，无论内容是否已完全显示在该查看区域内。
话虽如此，这是我们构建的一个较为独特的控件……它既能滚动页面，又能显示你在当前帖子范围内的位置（例如，它会显示你当前位于第 6 条，共 12 条帖子）。有可能根本不存在一种完美的标记方式供屏幕阅读器使用，甚至可能将其隐藏会更好……因为正常的页面滚动无需它也能按预期工作。我想先尝试一下，看看你实际使用后的反馈；如果效果不理想，我们可以回退。
回答你的问题 @nolan ，我负责整理无障碍性建议并推动完成我们的审计工作，但我之前关于无障碍性的经验大多来自实施他人定义的规范。我们目前没有专职负责无障碍性的专家，因为我们的规模仍比 Slack 小好几个数量级……但这可能意味着我们需要在此期间聘请专人来确保我们做得正确，避免让情况变得更糟……
感谢你们两人的回复，我非常感激！
6 个赞
关于工具栏角色，进一步澄清一下……您的意思是，除非完全遵循 W3C 所描述的这一模式，否则该角色就毫无价值吗？
实现焦点管理，使键盘 Tab 键序列中工具栏仅作为一个焦点停留点，并使用方向键在工具栏内的控件之间移动焦点。
如果是这样的话，在我们能够正确实现焦点管理和方向键控制之前，我将不会实现该角色。
5 个赞
MarcoZehe
2021 年2 月 13 日 19:18
17
正确，如果你使用了该角色，就意味着你承诺将同时实现该设计模式。如果你尚未准备好提供设计模式，也请暂时不要使用该角色。
5 个赞
这里是否适合报告我对托管的 Discourse 实例进行无障碍性审计的发现，还是应该另开一个新线程？
另外：
我之前提到的第三方无障碍性报告及后续工作并未公开追踪。
是否有机会重新考虑这一决定？如果能提供一些可与我客户分享的透明度，将会非常有帮助。
4 个赞
jomaxro
2021 年2 月 19 日 16:40
19
嘿，Aaron，
为了确保信息不丢失，我建议针对你审计中的每一项发现，都新建一个 ux accessibility
6 个赞
nolan
2021 年5 月 21 日 17:18
22
为了进一步说明：
仅使用角色而不实现该模式，就好比将某个元素样式化为按钮，却只在鼠标悬停并滚动滚轮时才做出响应。如果我通过 Tab 键聚焦到工具栏，或者以其他方式聚焦它，而它要么将各个按钮单独暴露出来，要么对方向键无响应，那么它的体验就会像那个奇怪的鼠标滚轮按钮一样。你将不得不在每次交互前都要思考，而它却声称具备它实际上并不具备的行为。
希望这能稍微澄清一下。知道某个元素是工具栏只有在其行为 符合工具栏特征时才有价值。否则，它只会造成干扰。
5 个赞
nolan
2021 年5 月 21 日 17:24
23
哎呀，真让人失望。我来这里是想问问，我发帖时那些看似正在进行的更新现在进展如何。我们还没上线自己的社区，但旧的 PHP 论坛即将停用，所以现在是最后的机会。我本以为到现在应该已经有一些令人惊叹的改进了。
但我无法找到进入网站管理区域的方法。虽然我可以访问 /admin，但无论我用什么方法，都无法通过键盘访问指向该网站的链接。这给请求视障用户协助我进行 Moderation 带来了一些挑战。
接着，我尝试在五分钟前回复这条消息，但不知怎么的，我误点了“编辑”或“引用”按钮。结果被带到了一个看似可编辑的、我之前发送的消息版本中。我尝试按回车键点击标有“取消”的链接，但无效。刷新页面也不行。最终我发送了回复，然后找到并操作了一个无法通过键盘访问的模态框（类似于我最初在这里报告的那个），才丢弃了那条消息。
在这方面有什么变化吗？或者是否有公开的路线图？作为一名必须与 Discourse 社区互动的视障用户，我可以让它为我所用，但我不太放心让一群视障朋友使用这个平台——至少，我不太放心让他们基于 Discourse 建立一个他们会喜欢的社区。
谢谢。
5 个赞
riking
2021 年5 月 21 日 17:55
24
不幸的是，这弹出了一个模态框，询问您想如何处理草稿（丢弃/保存/取消），而且似乎模态框的焦点捕获功能出现了问题……
5 个赞
ethindp
2021 年5 月 22 日 16:54
25
Discourse 对我来说很好用，但我确实希望看到一些无障碍功能的改进。自从上次使用 Discourse 的管理界面或管理 Discourse 论坛已经过去一段时间了，但我相信三个月内应该能取得不少进展。
我理解 ARIA 的实现可能具有挑战性，但这绝不意味着无法取得进展。@nolan ，我以前也遇到过同样的问题——花了一段时间才弄明白为什么点击“取消”后编辑框没有消失。我真的很希望未来某天能将 Discourse 用作我自己社区的论坛，但如果无障碍功能得不到改善，我可能不得不重新考虑这个决定。而且，我可不想再回到 PHP 时代。
你们几乎已经有人主动提出要在无障碍功能方面提供帮助了。如果我的语气听起来有些急躁，请见谅——我知道这对你们来说很不容易。但无论如何，@nolan 和我都绝对愿意提供帮助。我很乐意搭建一个 Discourse 测试实例。
7 个赞
