Like others have already said, it’s an accessibility nightmare. On the other hand, it’s not like this is going away anytime soon – maybe screenreaders could learn to understand and read some such “fonts” (e.g. bold/italic at least)?
replies(3):
> • Don't use aria-label or aria-labelledby on any other non-interactive content such as p, legend, li, or ul, because it is ignored.
> • Don't use aria-label or aria-labelledby on a span or div unless its given a role. When aria-label or aria-labelledby are on interactive roles (such as a link or button) or an img role, they override the contents of the div or span. Other roles besides Landmarks (discussed above) are ignored.
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>
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.