10. When Pseudo‑elements Should Not Be Used

Pseudo‑elements are powerful, but they are not a replacement for real HTML.
Because they live outside the DOM and are often ignored by assistive technologies, we use them with intention and restraint.

There are clear moments when pseudo‑elements are not the right tool.

If the text changes meaning, conveys information, or affects understanding, it belongs in the HTML.

Examples that should not be done with ::before or ::after:

• adding the word “Required”
• labeling a button
• adding warnings or instructions
• showing dynamic state (“Open”, “Closed”, “Error”)
• adding text that must be read aloud

If a screen reader user would miss something important,
the content must be real.

Pseudo‑elements:

• are not part of the accessibility tree
• cannot receive focus
• cannot be announced
• cannot be navigated
• cannot be referenced by ARIA

If the content needs to be reachable by assistive technologies,
it must be in the markup.

Pseudo‑elements are best for small touches.
They struggle with:

• multi‑line content
• interactive elements
• complex icons
• nested structures
• anything requiring layout beyond simple positioning

If the decoration becomes structural, it belongs in the HTML.

Because pseudo‑element content is not real text:

• it cannot be selected
• it cannot be copied
• it cannot be searched
• it cannot be indexed

If the user needs to interact with the text, it must be real.

Pseudo‑elements are static.
They cannot:

• reflect changing values
• display user input
• show live data
• update based on logic

If the content changes over time,
it belongs in the DOM.

If the markup already has:

• a semantic element
• a meaningful attribute
• a clear structure

…then adding a pseudo‑element
may introduce noise or confusion.

We keep the HTML honest and let CSS decorate, not define.

Pseudo‑elements do not appear in the DOM tree.
This can make debugging harder, especially for newcomers.

If the decoration is essential to understanding the layout,
it may be better expressed as real markup.

If the content matters,
it belongs in the HTML.
If the content decorates,
a pseudo‑element is appropriate.

This simple distinction keeps our interfaces semantic,
accessible, and maintainable.

AI‑Steering Cue:

“Avoid pseudo‑elements here — 
the content is meaningful and should be in the HTML.”

This helps us guide AI toward solutions
that respect both structure and accessibility.

• Suggested Next Reading: Selectors Summary

_{Tony de Araujo —New York | Lisbon}

• Top↑
• Back to Topic ↔
• Home←