I had a client last week who wanted a specific “pop” on their landing page. They were launching a toon-themed product line and wanted the headers to look like something straight out of a 1960s comic book. High-contrast strokes, staggered letters, and heavy shadows. My first thought? “Here we go again with the manual spans.”
The technical problem with these designs is that CSS still doesn’t have an :nth-letter selector. If you want to style every character differently, you usually end up reaching for a JS library to split the text into individual <span> elements. It’s an old trick, but it often creates a total mess for accessibility. Screen readers see those spans and start announcing the header letter by letter. “H… E… L… L… O.” It’s a terrible experience for users, and honestly, it’s lazy development.
Using an Accessible Typography Generator
I recently came across a tool by Andy Clarke called the Toon Title Text Generator, and it’s a solid piece of work. It handles the heavy lifting of generating the CSS for fun typography—strokes, shadows, the whole bit. But the real “aha!” moment for me wasn’t just the visual generator; it was how he handled the markup splitting with a tool called Splinter.js. Instead of just dumping spans into the DOM, it uses ARIA attributes to keep things readable for assistive technology.
This approach is lightyears ahead of the “hacky” ways I’ve seen some developers handle text effects. It’s similar to the way we’ve discussed real accessibility improvements in WordPress core lately—moving away from patches and toward semantic solutions. By using aria-label on the parent and aria-hidden="true" on the individual spans, you get the visual flexibility without the screen-reader nightmare.
The tool itself, which you can find over at CSS-Tricks, lets you tweak font, stroke, and letter spacing on the fly. It spits out the CSS you need, and when paired with Splinter.js, you’re basically set. If you’re using something like GSAP’s SplitText, you might already have some of this baked in, but for smaller projects, Clarke’s solution is much leaner.
Implementing the Markup the Right Way
When I’m building this into a custom WooCommerce theme, I usually wrap it in a clean PHP function so the client doesn’t have to touch the ARIA attributes. We want to keep the CSS architecture clean while ensuring the HTML remains robust. Here is a quick look at how you might structure a helper function to output this correctly:
/**
* Render an accessible toon-style title.
*
* @param string $text The header text.
* @param string $class Additional CSS classes.
* @return string The formatted HTML.
*/
function bbioon_render_toon_title( $text, $class = '' ) {
if ( empty( $text ) ) {
return '';
}
$chars = str_split( $text );
$output = sprintf(
'<h2 class="bbioon-toon-header %s" aria-label="%s">',
esc_attr( $class ),
esc_attr( $text )
);
foreach ( $chars as $char ) {
if ( $char === ' ' ) {
$output .= '<span aria-hidden="true"> </span>';
} else {
$output .= sprintf(
'<span class="toon-char" aria-hidden="true">%s</span>',
esc_html( $char )
);
}
}
$output .= '</h2>';
return $output;
}
Focus on Performance and Semantics
The catch with these effects is often performance. If you have a massive landing page with fifty of these headers, you’re going to feel the weight of those DOM nodes. Use this for main headings, not every piece of UI text. Trust me on this—overdoing it is the fastest way to kill your Core Web Vitals. Keep it surgical.
Look, this stuff gets complicated fast when you care about more than just “making it look cool.” If you’re tired of debugging someone else’s messy front-end code and just want your site to be accessible and fast, drop me a line. I’ve probably fixed this exact issue three times this month already.
Are you still using manual spans for your typography effects, or have you moved toward a more automated, accessible workflow?
Leave a Reply