为什么我们不能用一行脚本标签来解决可访问性问题?

2025-06-08

为什么我们不能用一行脚本标签来解决可访问性问题?

这个问题问得好。有些公司可能持不同意见(比如AccessiBe,它就是个垃圾)。这篇文章不是写给他们看的,是写给你看的。他们知道自己在做什么(以及不做什么)。

首先:默认情况下,网络是(通常)可访问的。

我们破坏了它。我、你、公司、资本主义,凡是你能想到的——都是我们破坏了网络的可访问性。

<div>onClick当元素出现时带有事件的标签<button>、不会捕获焦点的模态框以及其他示例在整个互联网上随处可见。

让我们从浏览器和辅助功能软件如何解释代码的角度来思考这个问题:

  1. 写一些 HTML。
  2. 将该 HTML 加载到浏览器中。
  3. 浏览器解释该 HTML,并从中创建一个可访问性树(包括渲染它等)
  4. 浏览器公开了可访问性技术所访问的 API,并且浏览器将 HTML 解释为就好像它是按照标准编写的一样。
    • 如果此 HTML 不符合规范,例如使用不当(例如,查看<div>带有onClick事件的内容),浏览器就无法推断其具体用途。
    • 这会影响可访问性技术,因为它只能处理浏览器提供的功能。

如果我们不当使用 Web 技术,我们还能指望浏览器以某种方式执行启发式算法来理解我们的意思吗?毕竟,编程实际上是用计算机能理解的语言告诉它该做什么。如果我们不以计算机能理解的方式告诉它该做什么,它通常会选择最安全的路径。

一个例子是纠正缺少结束 HTML 标签的情况。在旧版浏览器时代,标准允许某些标签省略结束标签,并且这是有效的HTML。现在情况已经不同了(除了某些例外情况,例如<input>!)。

参考以下代码:

<div>
  <span>Hello!
</div>
Enter fullscreen mode Exit fullscreen mode

在任何现代浏览器中,<span>如果您检查它,上述内容将在 DOM 中自动关闭。

Firefox 检查器的屏幕截图,显示带有 span 的 DOM,该 span 具有结束 span 标签,但源代码没有该结束标签

上面的代码甚至没有 HTML 标签、HEAD 标签或 BODY 标签,但 Firefox 却默认有。浏览器虽然能帮我们很多忙,但却无法从我们糟糕的代码中解读出我们的意图。

有时,标准并不是我们所需要的全部

在其他情况下,我们可以正确使用所有 HTML 标签,但仍然无法创建可访问的界面。这就是细微差别发挥作用的地方。例如,模态窗口。根据定义,模态窗口只是其他元素之上的一个对话框。用户体验决定了它应被视为一个单独的“文档”,而没有标准的方式来做到这一点。模态窗口通常打破了 Web 的创建方式。页面是一个“文档”,而模态窗口是“文档中的文档”。

如果一个文档真的要表现得像一个文档,那么它必须是唯一“聚焦”的文档。对于模态窗口,我们通常会添加一个“聚焦陷阱”,以确保用户无法不情愿地脱离它。附加脚本不会知道这是你的意图。

在某些情况下,我们需要JavaScript 来实现网页的无障碍访问。Stephanie Eckles在 Smashing Magazine 上发表了一篇非常精彩的文章,详细阐述了这一点。

某人的 JavaScript 怎么知道这种细微差别?

不行。它不能。它不会。需要可访问界面的用户和该领域的专家一次又一次表示 行不通

不要采取附加修复措施

AccessiBe 并非第一家这样做的公司,但它承诺过高,实际操作却很卑鄙。Overlay事实说明书中还提到了其他一些公司的名字——它们都应该被避开。

可访问性并不是附加的。

鏂囩珷鏉yu簮锛�https://dev.to/clairebaire/why-can-t-we-solve-accessibility-with-a-one-line-script-tag-508f
PREV
使用 Sass Maps AWS Security LIVE 干燥 CSS 选择器!
NEXT
我的疯狂发布。33,000 名访客💥,在多个平台上排名第一。