如果HTML和ARIA不允许，这可能是个坏主意

原文地址：If HTML and ARIA don’t allow it, it’s probably a bad idea

原文作者：Martin

译文出自：掘金翻译计划

于2021年10月25日发表在 Accessibility, Design and HTML

我在英国政府工作了好几年，我所做的每一项服务都包含条件性问题；换句话说，只有当前一个问题以某种方式得到回答时，才会提出这些问题。

在GOV.UK设计系统中有一个单选框表单组件的变体，当对第一个问题给出特定答案时，会立即显示出后续的问题。设计系统的建议是：

保持简单。如果相关的问题很复杂或者有多个部分，就在流程中的下一页显示。

这里的问题是，它的解释是开放的；一个人对 "简单 "的定义可能是另一个人的 "复杂"。越过这条线意味着不符合《网页内容可访问性指南》（WCAG）中的关于输入的成功标准，该标准指出：

改变任何用户界面组件的设置[例如选择一个单选按钮]并不自动导致上下文的改变，除非在使用该组件之前已经告知用户该行为。

WCAG将 "上下文的变化 "描述为：

Web页面内容的重大变化，如果在用户不知道的情况下进行，可能会使用户迷失方向。

在我看来，一个密切相关的问题，比如GOV.UK Design System的例子中给出的问题，不会构成‘上下文的改变’。而内容的设计是这样的，只问了一个问题：

但是存在这样的危险，即设计者可能会滥用这种模式，而这正是我所继承的一个政府服务中所发生的事情。在该服务中，不太密切相关的条件性问题会在同一页上显示出来，有时这些问题会有更多的条件性问题显示出来。

更根本的是，GOV.UK的有条件显示问题的单选组包含无效的ARIA。电子邮件单选按钮的HTML看起来像这样。

<input class="govuk-radios__input" id="contact" name="contact" type="radio" value="email" aria-controls="条件性联系" aria-expanded="false">

aria-expanded="false" 属性的目的是向屏幕阅读器用户表明，该控件将显示一些目前隐藏的内容；屏幕阅读器软件通常会读出类似 "折叠 "的内容。当选择该选项时，aria-expanded 的值变成了真，屏幕阅读器会显示 "展开"。

不幸的是，单选框 并没有出现在 aria-expanded 规范的 "Inherits into Roles "列表中，而且aria-expanded也不是输入作用的允许属性。

通过HTML验证器运行GOV.UK的代码，我们看到如下情况。

Error: Attribute aria-expanded not allowed on element input at this point.

因为这段代码是无效的，所以不能依靠它来正确传达给屏幕阅读器用户。但是，即使它能像预期的那样工作，我们不也应该以视觉方式告知用户，以尽量减少意外增加的内容的负担吗？

最近在GOV.UK的可访问性博客中也写到了这一内容，他们承认了验证问题和对一些用户造成混淆的可能性。他们还探讨了一些合理的替代方案，但都没有完全摆脱这样的事实：

对我来说，只要一发现到无效的HTML，我就会去寻找替代方案。无效的HTML之所以无效是有原因的，所以我喜欢把它看作是一种设计约束；一条我不能跨越的线。毕竟，约束是优秀设计的要素。

在本例中，我会坚持每页一件事的指导，在不同的页面上为用户提供两个步骤：

这既消除了验证问题，也消除了对用户的任何意外，不管是多么小的意外；消除了任何不能满足WCAG的问题。

当然，理想的情况 在现实世界中并不总是可能实现的，我使用有条件显示问题的政府服务就是一个很好的例子。有很多页面都有条件性显示的问题，我知道我们不可能把它们都分成独立的页面，因为：

我采取了策略，问自己哪些页面肯定不能通过On Input WCAG成功标准；哪些页面有

虽然结果是一个通过WCAG 2.1 拿到AA的服务，但人们总是担心我的 ”简单 “有时会成为审核师的 ”复杂“。