来自 Ire Aderinokun 的一篇关于 <abbr title=""> 元素用于缩写的不可抗拒的 HTML 元素深入研究。你可以直接使用它 (JUI)，它工作得很好，但如果你希望为它们创建一个工具提示（在触摸屏上也适用），那么它会变得更加复杂。
最终结果是将语义 HTML 保持原样，并通过大约 50 行 JavaScript 进行渐进增强，这些 JavaScript 添加了交互式包装器元素和事件处理程序。
我觉得这非常适合做成一个 Web 组件，它可以/应该广泛分发供使用。也许一个 <a11y-abbr> 组件或其他什么。不过，Web 组件可以扩展其他原生 HTML 元素吗？如果不是，我想它基本上会退回到 <span>，所以也许这不是理想的选择。
我敢说，这也是 React 可以胜任的一件事。例如，我使用 Reach Router，默认情况下，在创建链接 (<Link> 变成 <a>) 时，它们会获得正确的 aria-current 属性，因为它就是当前页面。这是您免费获得的良好可访问性，因为该库足够好，可以正确地获取该细节。尽管像 React 这样的库在可访问性方面存在问题，但它们在抽象方面存在很大潜力来改进可访问性。就像 Brad Frost 一直在 React 组件中强制执行可访问性最佳实践 一样。
我主要用它来包含页面的目录。我把目录放在多级无序列表中。在细节之前，我有一个链接，上面写着“跳过目录”，该链接指向它后面的第一个部分 ID，这是因为一些屏幕阅读器会读取 details 节点的内容，无论它是否打开，所以如果 details 内容很多，提供一种方法让屏幕阅读器跳过它会很方便。
我以前用过一个 polyfil，但它有时会在浏览器更新时出现问题——所以现在我不再理会了，如果浏览器不支持 details，它就会一直处于打开状态。
我发现给 summary 元素一个黄色的背景很有用，当 details 默认情况下是关闭的时候，我会在括号里写 (点击展开)——令人惊讶的是，有多少人不知道怎么做，除非在 summary 中写了这句话。
至于工具提示，老实说，我认为 details 不是合适的工具，我认为需要用纯 JS 和 CSS 在 div 中处理。
如果有一个真正的工具提示元素就好了。
我想知道这是否是一个情况，即 title 属性基于光标的处理非常普遍，以至于应该就触摸设备上类似工具提示的行为达成共识，并由移动浏览器实现。但另一方面，移动浏览器已经存在了很长时间，如此重大的变化可能会导致问题并破坏现有的网站。
很难抉择。这感觉很可惜，一个大约 50 行的 polyfill 对于处理移动设备上的工具提示是必要的。
这也让我想起 我曾经写过的一篇关于这个想法的博客文章，其中我们允许浏览器在默认样式/内容处理方面发挥更重要的作用，以促进更快的加载速度和更好的体验。如果这种大约 50 行的 polyfill 或类似的体验在 web 上被广泛使用，也许它需要在更底层的级别得到支持。