Decorative text can add visual impact. Not every design needs decorative text, but some designs occasionally want them. This site used to have a lot, but not any more. It had huge numbers in multiple places, creating various elements that look good. These numbers didn’t need to be seen, read or understood because they do not convey any meaningful information.
Unfortunately, accessibility audits such as Google Lighthouse may misinterpret the decorative text as meaningful text when they are not. Well, chances are, it’ll just be a warning about contrast or readability that you could ignore. Your website will still usable because your core human audience will understand.
However, if you want to remove the Lighthouse warning and improve the accessibility of your website, this article will roughly cover how to make that text truly ‘decorative’.
Why does accessibility matter?
Accessibility is not just about passing audits, but about ensuring that everyone can use and enjoy your website. Screen readers, high‑contrast modes, and other assistive technologies are lifelines for people with visual, auditory, or cognitive differences. When decorative elements are misinterpreted as meaningful text, they can clutter the experience, distract from real content, and make navigation harder.
By handling decorative text correctly, you’re not only satisfying Lighthouse but also respecting the diverse ways people interact with the web. In short: accessibility is about inclusion, and good design is inclusive by default.
The problem: Decorative text
When decorative text are rendered directly in the DOM, Lighthouse sees them as text nodes. For example my website frequently could’ve used:
|
|
Even if you add attributes like aria-hidden="true" or role="presentation", Lighthouse may still flag them. That’s because the text is still present in the DOM, and automated tools can’t reliably distinguish decorative intent.
Why aria-hidden still matters
Although aria-hidden="true" won’t stop Lighthouse from reporting issues, it’s still essential for accessibility. Screen readers respect this attribute, ensuring decorative elements don’t confuse users who rely on assistive technology.
|
|
Think of aria-hidden as a courtesy to real users, even if Lighthouse doesn’t care.
If you want to double‑check, open your browser’s Accessibility tab in DevTools (Chrome, Edge, or Firefox) and inspect the element. If aria-hidden is applied correctly, the decorative text won’t appear in the accessibility tree.
The solution: data-* attributes + CSS
There’s a few ways of dealing with this problem, such as using pseudo :before and :after elements, custom images/SVG possibly dynamically generated through code or rendered through your server, but using a data-attribute with CSS is an easy way to solve the Lighthouse problem.
To keep decorative text visible but invisible to audits, store them in a data-* attribute and render them with CSS. This way, Lighthouse doesn’t see text nodes, but your design remains intact.
|
|
|
|
This approach ensures:
- Lighthouse ignores the decorative text (no text nodes to analyze).
- Screen readers skip them (
aria-hidden="true). - Designers keep their decorative flair.
Conclusion
Decorative text can confuse accessibility audits if left as raw DOM content. By moving it into data-* attributes and rendering with CSS, you preserve your design while keeping Lighthouse happy. And remember: aria-hidden is still worth including for the real people, not just for passing audits.
Leave a comment