Good point. Any ideas how to implement it properly?

chrismorgan · 2025-03-16T11:27:08 1742124428

I have often wanted to do exactly this, and was disappointed when I learned aria-label couldn’t be used to replace the value exposed for non-interactive content. I have hunted for other techniques a couple of times, and never been completely satisfied, though things have improved in the last year and a bit.

The basic technique is roughly this:

  <span>
      <span aria-hidden="true">displayed text</span>
      <span inert class="visually-hidden">accessibility text</span>
  </span>

  <style>
      .visually-hidden {
          position: absolute;
          width: 1px;
          height: 1px;
          margin: -1px;
          overflow: hidden;
          clip-path: rect(0 0 0 0);
          -webkit-user-select: none;
          user-select: none;
          pointer-events: none;
      }
  </style>

The `inert` attribute is a recent addition which may exclude the accessibility text from find-in-page (maybe desirable, maybe undesirable, depending on the situation). Firefox and Chromium shipped that refinement of its behaviour in the last year and a half, Safari hasn’t yet (and seems to have reservations about the whole idea <https://bugs.webkit.org/show_bug.cgi?id=269909>).

You can also play with putting the accessibility text in a pseudoelement’s content (e.g. <span data-a11y-text=…><span aria-hidden=true>…</span></span> and [data-a11y-text]::after { content: attr(data-a11y-text); … }), which should these days be exposed in the accessibility tree, but Firefox find-in-page now includes generated content (though you can’t bridge real and generated content), and it wouldn’t surprise me if Chromium eventually followed suit, so I’m not convinced it’s worth the bother, especially if you lose `inert` or have to add an element anyway. But keeping it as an attribute instead of a separate element has some appeal.