console.error(`Unable to load nonexistent manifest entry ‘islands/voting-prompt’. Check that your file path is correct.`)

您可能已经看到，我们一直在开展多项无障碍计划（、、），这些计划涉及 Stack Exchange 网络和的各个部分。作为该计划的一部分，我们还开发了一个。该仪表板为我们不同的业务重点提供了无障碍分数：（设计库）、PubPlat（Stack Overflow 和所有 Stack Exchange 站点）、Teams 和企业产品。我们通过运行自动夜间检查来计算此分数，这些检查会生成成功和失败的列表。分数是通过计算成功率占总测试数的百分比得出的。如果您想了解有关自动规则集的更多信息，可以资源。

我们最初计划将仪表板用于内部使用（我们稍后会讨论锁定图标），以便我们的工程师、设计师和产品经理了解我们在可访问性方面的表现。我们的目标是随着时间的推移不断提高这一分数，以履行对社区和客户的承诺。随着可访问性工作的继续，我们将继续跟踪更多页面并进行进一步测试，因此这个分数可能会下降，但我们将致力于努力将分数恢复到原来的水平。

在对仪表板进行几次迭代后，我们清楚地认识到，随着时间的推移，能够观察和监控指标将使社区受益。通过提供对我们内部使用的工具的透明、公开访问，社区能够就我们对、的遵守情况提供反馈，特别是对于颜色，我们会根据进行测试。借助此工具，我们希望社区知道我们的承诺不仅仅是说说而已，而是有指标支持的，可以衡量我们是进步了还是倒退了。

这是一款面向公众的工具，但有一些锁定的链接，社区无法访问。由于这些链接为我们的团队成员提供了内部文档的信息资源，因此您将看到一些带有锁定图标的链接，这些链接指向其中一些资源。

随着我们继续在整个网络上开展无障碍工作，我们希望分享这一点，以便您可以参考它来跟踪 Stack Overflow 对无障碍承诺的持续进展。我们的工作远未结束，我们仍在开展不同的无障碍计划，并将在有更新时继续更新。说到其他计划，我们计划在 6 到 8 周内（甚至可能 3 周内）发布对访问链接状态颜色和段落内链接的改进！随着发布日期的临近，我们将分享更多信息。对于其他计划，我们将在开展工作的同时继续更新它们。

如果您对仪表板有任何疑问或反馈，请告诉我们。我们将密切关注此帖子以获取反馈，直至 2024 年 8 月 21 日。

15

  • 4
    我不确定这里是否适合提出这样的请求，但您能否稍微扩展一下“我们通过运行自动夜间检查来计算此分数，这些检查会生成成功和失败的列表”？成功和失败究竟是什么？换句话说：（人类）可访问性是如何自动计算的？（我现在看到它还检查，例如，每个表单元素是否都有一个“标签”；那么这些只是代码的自动检查吗？）


    – 


  • 5
    这偏离了目标。我的意思是，你监控得很好，但那些缺失的百分比通常是显而易见的严重可访问性问题。这个仪表板感觉就像是可访问性声明的漂绿版。做而不是吹嘘——网站的多个部分都存在显而易见的严重可访问性问题，而因这些问题而苦苦挣扎的人并没有因为 93% 的网站没有问题而得到帮助。可能只占网站整体功能的几个百分点，但我向你保证，它们占了不成比例的互动量


    – 


  • 1
    顺便说一句，设置一个面向公众的仪表板来吹嘘可访问性花了多少时间，而这些时间本来可以用来解决剩余的（通常是主要的）可访问性问题？


    – 

  • 6
    @Joachim 对于自动检查，我们使用了一个名为工具。这会扫描可通过编程检测到的可访问性问题。成功是指给定元素没有可检测到的可访问性问题，并检测到失败问题。


    – 
    职员模式

  • 2
    @Joachim 这篇在“衡量进度”部分更详细地介绍了这些检查，可能阐明了其中的一些工作原理。


    – 
    职员模式

  • 10
    @Zoe-Savethedatadump 这个仪表板绝不意味着我们已完成工作。我们知道仍有改进空间，我们计划继续改进。此工具旨在让社区和我们的 Teams 客户能够关注事情的进展。并让我们以可量化的方式衡量我们的表现。改善平台上的可访问性，改善我们目前所缺乏的和尚未开展的新工作。可访问性改进仍然是我们的目标之一，我很高兴地说，我们致力于在整个平台上不断改进。


    – 
    职员模式

  • 8
    让事情变得更好的一个好方法是衡量你目前所处的位置。我认为将这些指标公开并增加容易被忽视的工作的可见性是一个好主意。我知道对正在进行的工作这样做有点可怕。


    – 

  • 1
    @SpencerG 我也不是这个意思。当公司这样做时，几乎总是会变成“我们每个季度都会做一点，让它看起来像我们在努力”，但并没有付出长期的努力。例如，微软吹嘘自己是环保的——而无论你有多少碳补偿，它所做的 genAI 从根本上都是反环境的。监控是好的，吹嘘所说的监控通常是事情即将大幅走下坡路的标志，如果没有具体的改善策略——而这个声明并不是


    – 

  • 2
    换句话说：仪表板是这些计划在股东手中夭折的地方，而不是为最终用户带来繁荣


    – 

  • 3
    另外：“可访问性改进仍然是我们的目标之一，我很高兴地说，我们致力于在整个平台上持续改进”——为什么不公开分享这些计划？您的 [SE] 处理可访问性的策略是什么？可访问性如何融入您的 [SE] 路线图？或者更一般地说：您 [SE] 计划如何确保仪表板真正提供价值，而不仅仅是成为股东大会上毫无意义的谈话要点，这种谈话要点是为了公众的看法而保留的，而不是因为可访问性很重要？


    – 

  • 1
    需要说明的是，我之所以问这些问题，是因为我关心可访问性。失去可访问性计划对社区来说将是毁灭性的损失。但你们 [SE] 推动的大多数其他公开计划都失败了。请参阅编辑器、向导和日益重要的过时答案计划，该计划在一两个功能公告后就被抛弃了。还有更多，但我已经在 MSE 的某个地方列出了它们。找到答案就留给读者练习了。


    – 

  • 1
    我已将其添加到中。


    – 

  • 4
    除此之外，当营利性公司（一般来说）制作图表吹嘘某些计划时，却没有公开、具体的长期计划来执行，这通常表明该计划将在最多几个月内失去优先权并消亡。如果你 [SE] 没有具体的计划，那就是个问题，并使这一声明成为一系列坏消息中的另一个。我的目的不是说“仪表板不好”，而是质疑确保有实际计划来执行的动机，以及将仪表板用于不仅仅是吹嘘的事情


    – 

  • 3
    @Zoe-Savethedatadump 这基本上就是我的回答想要表达的意思。这个仪表盘只是一些很酷的自动数字，除了可以向用户展示以掩盖你只能在元信息上看到的更大问题之外，没有其他用处。我想知道这张图表是否会成为某位 CEO 在闭门会议上的下一个卖点。。。遗憾的是，我们总是在事情发生后才知道这些事情。


    – 

  • 将堆栈显示为具有最高分数的默认选项卡感觉有点不诚实，但每个人实际看到的“pubplat”的分数较低


    – 


7 个回答
7

这是一个很好的起点，我对此表示赞赏。

话虽如此，我不禁想知道，当您最近为使网站更具可读性而做出的一些努力遭到了负面反馈和要求撤销大多被忽略的更改的要求时，这个似乎只是基于某些设计规则的自动评分的指标有多么有用。

当您更改投票按钮的外观时，人们告诉您旧设计更清晰、更易读。他们忽略了这一点，现在我改用 Greasemonkey 脚本来撤消您的更改。具体来说

：目前为-564，是 Meta 上被否决次数最多的帖子之一。相比之下，获得了 96 个赞成票。我还要指出的是，虽然该请求已标记为已完成，但我在 Meta.SE 上看到的根本不是所要求的——但这可能是后续的进一步更改，所以我可能遗漏了一些背景信息。

当时，大多数用户似乎喜欢第四个提案。遗憾的是，一定有人非常喜欢他们的第三个设计，因为我们得到的是粗体标签，供享受。

所以，我的问题很简单：您是否只采用自动指标，而这些指标可能仅限于颜色对比度、字体大小等？用户反馈在多大程度上符合该数据？

简单来说：560 名用户强烈反对您的某项可访问性/设计更改会对该页面产生什么影响？我们能确定这不是一个空洞无用的指标吗？其唯一目的是让网站看起来更好，并宣传网站，而真正的设计问题仍然隐藏在 Meta.SE 上（并被忽略）？我的意思是……让每个人都看到 Stack 的独角兽可访问性得分为 98.26 /100，而只有少数 Meta 爱好者知道 -560 的分数变化，

这似乎很方便。

11

  • 2
    如果这些自动化指标确实只能发现与代码相关的可访问性问题，但显然不会访问具有人类敏感性的网站，那么这也将是我对评论中提出的问题的后续问题。


    – 


  • 1
    @Joachim“但显然不要访问具有人类情感的网站。 ”啊，那么与 SE 员工相当。


    – 

  • 1
    我绝对同意大家的观点；指标在 [不再有用](en.wikipedia.org/wiki/Goodhart’s_law) 之前一直都很有用。不过，我仍然不完全理解投票按钮引发的喧嚣，我不确定这是否是最好的例子；我不想忽视人们的诚实反应，但在我看来，这更多的是关于“改变是坏事”而不是实质性的批评——也就是说，一旦最初的问题得到很大程度的解决。社区对变化的反应有时可能 会被误导，而我们往往是一群固执的人。话虽如此，标签加粗确实很糟糕。


    – 

  • @zcoop98 请参阅链接的第二篇帖子。公告中实施的原始设计大大降低了投票的可读性 – 至少在某些网站上是这样。我认为他们在那之后确实对设计做了一些改进，但改进仍然基于他们的观点，而不仅仅是听取人们的意见。唉，我更喜欢原始按钮的另一个原因是它们更小。


    – 

  • @SPArcheon-onstrike 有趣的是，现在按钮不那么清晰了。我不记得具体是什么变化导致了这种情况，但我认为是颜色更新之一。当房间里（和我的显示器上）光线较强时，很难看到圆圈。有时这完全不可能，实际上只能看到微小的三角形。


    – 

  • @VLAZ 正如我所说，我在他们做出更改后不久就撤消了他们的更改，因此我有点忘记了沿途的其他改进。


    – 

  • 3
    我们并不完全依赖自动指标。仪表板本身是自动和手动加权指标的平均值。手动加权指标来自内部标记的需要改进的问题，这些问题不在自动测试中包含的页面上。


    – 
    职员模式

  • 2
    话虽如此，社区情绪不会影响可访问性评分。这是完全不同的事情；理想情况下，我们会推出类似投票按钮的东西，即既满足用户期望又符合可接受的可访问性要求的设计。但是，我们知道情况显然并非总是如此。您指出的问题实际上是一个更大的问题，不能仅通过自动或手动测试的可访问性评分来解决，而是我们如何进行更改并让社区提供反馈。


    – 
    职员模式

  • 2
    坦率地说，在我看来，与这个仪表板不太相关的是，我们需要更好地在沟通和针对具体举措的反馈请求中定位无障碍需求。这样，这些需求对于社区来说就更加明显，成为我们需要牢记的参数。当然，这最终取决于我们。我想我们正在改进及时获得反馈并缓解这些问题，但显然，这项工作仍在进行中。


    – 
    职员模式

  • 1
    @SpencerG 消息的长度可能削弱了预期的含义。这并不是在质疑自动检查的使用（但我建议您查看 wizzwizz4 的建议）。我想指出的是，我认为重点应该放在用户反馈上，而不是百分比分数上。您有一个工具可以帮助您在学习设计可访问性的过程中发现重复的错误，这很酷，但是……这并不是我认为该网站的卖点。所以，您知道您有这个工具，这很好，但作为用户，这个数字本身对我来说有点简单。


    – 

  • @SpencerG 这也是我讽刺地问这个分数是不是公司下次公开演讲时吹嘘的东西的原因。对于网站用户来说，网络已达到 98.48928582498673% 而昨天仍为 98.48928582498672% 并不那么具有启发性 – 这更能打动一些“游戏外”观众。所以… 感谢您让我们知道这个工具的存在，感谢您的透明度，但我不会经常检查分数。


    – 

页面在移动设备/窄屏幕上不太容易访问：

整个页面不应该有滚动条，因为表格已经有滚动条了。

非自动化测试的计划是什么？

这个仪表板朝着正确的方向迈出了一步，但您的非自动化测试仍然达不到标准，甚至连基本要求（即 A 级 WCAG）都没有达到。例如，最近的更新要求用户知道 a) 蓝色和灰色；b) 橙色和灰色之间的区别，因此不符合。就上下文而言，这是添加灰色 mod/staff 指示器的更新。另一个新的可访问性问题的例子是，在可访问性仪表板本身上，锁定图标对于屏幕阅读器来说是完全不可见的（HT ）。这两个问题都无法通过自动化测试检测到，因为它无法知道颜色或图标不仅仅是装饰性的。

正在采取哪些措施来防止新功能中的可访问性问题？如何解决这些可访问性计划之前出现的问题？其中一些老问题非常严重，以至于它们会阻止用户执行重要但基本的任务，例如正确格式化帖子（例如，无法使用键盘访问非 Stacks 编辑器工具栏）。

手动问题的链接有一组箭头，而不是锁，并且链接到私人 jira

指标链接指向一个私有的 github repo – 它看起来与指向 stacks 的其他链接相同。这也需要锁定

2

  • 1
    由于这是工作人员经常使用的工具，我们选择将手动问题链接与 Jira 图标一起显示，而不是锁，这有点令人困惑。但我们希望工作人员清楚他们可以在哪里找到这些链接。考虑到它位于登录后，我们认为这很明显。至于指标链接，我们错过了，并将更新它。


    – 
    职员模式

  • 5
    如果可以的话，也许可以在手动问题链接上同时包含这两个内容？这样，员工也只会知道其员工。


    – 

我认为这是一个很酷的功能，我很高兴看到它。有可访问性问题的用户将受益最多。

有人可以简单地解释一下这些工具如何处理代码覆盖率，以及我们是否可以期望测试网站的所有可见 HTML/CSS 部分吗？

3

  • 4
    目前，我们还没有 100% 覆盖这些内容。目前，这些内容涵盖了我们已开始优化的页面列表，这些页面主要基于访问量最大的页面。我们希望随着时间的推移扩大页面列表，但在这方面还有很多工作要做。过去，我们曾经有一个团队专注于提高可访问性。


    – 
    职员模式

  • 4
    最近，作为此仪表板计划的一部分，我们开始转向一个框架，该框架成为每个团队的一部分，以保持可访问性。我们谈到了这一点。此外，正在进行手动测试，这些测试在我们的一些内部 Jira 板上手动捕获、评估和标记。


    – 
    职员模式

  • 1
    @SpencerG 谢谢你的解释！我记得，我很期待后续的进展。


    – 


我很高兴您公开了这个可访问性仪表板。为此，我向您表示感谢。然而，这个仪表板的存在，以及，强烈暗示您正在玩可访问性打地鼠游戏：您的流程系统地重复产生相同的可访问性问题，然后必须修复这些问题。

在我看来，你做错了。可访问性不应该是一个事后过程：你的其他流程应该在设计时考虑到网络可访问性。（分散打地鼠的负担不算。）无论你的可访问性问题修复流程多么出色，如果你仍然经常引入这些问题，那么你仍然做错了。推荐阅读：

    • 使用粗体文本而不是标题是一个常见问题：例如参见审核队列/暂存区的所有如何使用框。

这个答案的其余部分只是上述内容的结果。

由于这些链接为我们的团队成员提供了内部文档的信息资源，因此您会看到一些带有锁定图标的链接，指向其中一些资源。

您已<svg>为此使用了标签，但标签aria-hidden="true"缺失<title>。如果这一区别足够重要，值得评论（），那么为什么标记了其唯一的标志（阻止其暴露给无障碍 API）？

也许你应该把你的可访问性仪表板放在你的可访问性仪表板上。

（附言：这个内联 SVG 也是重复的，这完全没有必要。要么使用外部的<img>，要么使用 SVG 的<use>标签。页面膨胀也是一个访问问题：不是每个人都有高带宽、无限流量的互联网连接。）

仪表板为我们不同的业务重点提供了可访问性分数：Stacks（设计库）

Stacks 是围绕使用非语义类描述页面的视觉方面而构建的，因此根据设计，Stacks 从根本上是无法访问的。

例子：

<div class="fc-black-400 fs-caption fs-italic">recorded Aug 7, 2024</div>

这应该使用。您有办法一眼就发现这些问题吗？我只能通过“我知道 Stack Exchange 不会做…… *检查*是的，他们也没有在那里做”来发现它们，这是打地鼠式的，不可持续。

在您的设计过程变得更加语义化之前，您只会继续遇到这样的问题。（我怀疑 Stacks 的当前设计阻碍了您的发展，但这可能不是真的。）

2

  • 2
    如果有人知道这个答案有什么问题，请告诉我。


    – 

  • 1
    没什么，真的。如果你注意到所有显示批评的答案都被否决了，那么你应该感谢一些勤奋的骑士。


    – 

可以添加暗黑模式吗？

是否可以将类似的东西添加到仪表板，以便用户可以使用暗模式？（截图自）。

添加class="theme-dark"标签<body>似乎足以使暗模式发挥作用（技巧来自）。