Matt Soria's Journal

Gradient-Revealed Text: An Alternative Approach to Gsap's SplitText

Mon, 16 Feb 2026 09:11:00 GMT

tl;dr: jump to my CSS/GSAP-free solution

I was working on a client project recently that featured a section of text that was supposed to start at a very low-contrast color, and then as the section scrolled into view, the text was supposed to transition, character-by-character, to a high-contrast color. This is something I've seen before, and I'm sure you have too. I immediately thought: "GSAP's SplitText."

And that's exactly what I turned to. I put together a component that used GSAP's ScrollTrigger plugin to handle the triggering of the event when the section was at the right position in the viewport, and GSAP's SplitText plugin to handle the character-by-character color animation.

This all worked well, and was easy to implement, but then I pulled up Deque's AXE Devtools to test the page for simple accessibility concerns, and it flagged an error on my new component: Elements must only use permitted ARIA attributes.

See the Pen GSAP SplitText A11y Error by Matt Soria (@itsmattsoria) on CodePen.

If you have Deque's AXE Devtools browser extension installed and you run it on that demo, you'll see that same error.

I could see what the issue was: I had initiated SplitText on a div, which is the element SplitText slapped aria-label onto with the text content of the inner HTML, and a div, without a given role, can't have aria-label. I was using a div for a good reason, though: the text I wanted to animate was coming from a rich text field of a CMS, which could contain multiple <p> elements, and some styled <span> elements as well, so a generic container made the most sense. I could futz around with stripping that data of the tags as long as it was all going to be communicated by aria-label anyway, but whenever I find myself getting into the territory of stripping semantics and structural meaning, it's a clear red flag begging the question, "Is there not a simpler way?"

GSAP has this very scenario covered in their docs, though, and the proposed solution is to tell GSAP to leave off all of the aria attributes and let you handle it by duplicating the text markup in question, and visually hiding it, while adding aria-hidden="true" to the element to be animated by GSAP:

Animated text...

Some more animated text.

Animated text...

Some more animated text.

My coworker Abigail actually shared this post by Adrian Roselli urging you to just not do it, the day after I encountered this. I was already unsatisfied with the look of the animation (seen in the above CodePen) and this encouraged me to take another look and see if I couldn't find another approach.

That's when I decided to try and try it without SplitText and just go straight CSS. For the purposes of the design I was implementing, it actually wasn't important to be able to animate each letter individually since the letters themselves were meant to stay stationary, and the starting point of the animation was the same text, just at a lighter color.

Here's what I came up with:

See the Pen GSAP-Free Animated Text Gradient Fill by Matt Soria (@itsmattsoria) on CodePen.

I like the smoothness of the gradient spreading across the text over the abruptness of the letter-by-letter color change that happens when using SplitText.

And aesthetics aside, I love this approach because it's accessible without needing to do anything hacky (it's just plain markup), and it's JavaScript-free :sparkles:.

Here's what the markup looks like:

Lorem, ipsum dolor sit amet consectetur adipisicing elit. Minima maiores dicta vero voluptatem architecto quos quo saepe, est error quisquam. Exercitationem quas similique at perferendis voluptate repudiandae consectetur quis itaque!

Lorem ipsum dolor sit amet consectetur adipisicing elit. Excepturi officia eum corporis! Quaerat atque, consequuntur nulla, fuga deleniti obcaecati rem blanditiis reiciendis ipsum facilis dolorum voluptatum id tempore eligendi nemo!

That's it! It's just a container of semantic text markup with a class on it.

And here's what the CSS looks like:

:root { --color-start: #BBAC9B; --color-end: #121110; } .animated-text { /* Set this as the end/legible color in case a visitor prefers reduced-motion */ color: var(--color-end); } /* Wrap all of the animation styles in check for the visitor's motion preferences */ @media (prefers-reduced-motion: no-preference) { .animated-text { /* Scroll-driven Animation Properties */ view-timeline-name: --animated-text; view-timeline-axis: block; animation: linear animatedTextBackground forwards; animation-timeline: --animated-text; animation-range: entry 45% cover 60%; /* The background gradient styles */ color: transparent; background-clip: text; background-size: 100% 300%; background-position: 50% 100%; will-change: background-position; /* The gradient that creates the effect */ background-image: linear-gradient(172deg, var(--color-end) 45%, var(--color-start) 55%); } } /* Animation that moves the background gradient into position */ @keyframes animatedTextBackground { from { background-position: 50% 90%; } to { background-position: 50% 0%; } }

That's it! The markup is inherently accessible, and on top of that, we can take a no-motion-first approach, ensuring the text is legible by default, and sprinkling on the animation if it's (assumed to be) acceptable to the visitor.

No Hate for GSAP

I just want to make clear that this post isn't meant as a dump on GSAP, or to convince you to not use GSAP—I think it's an incredibly powerful and useful tool, and I find a use for it on nearly every project I take on. It's just that for this particular design challenge, it seemed like a less-is-more approach was worth considering, and avoided the potential issues that Adrian outlined in his post.

Daily Summer Commute

Mon, 16 Jun 2025 07:00:00 GMT

I live in an impossibly beautiful place—South Lake Tahoe, California. My daughter's daycare is on the other side of a state park that butts up against our back yard. So in the summer, I get to ride my mountain bike through the forest and glorious meadow to pick my daughter up, and some days it just feels unreal. I finally felt like I needed to capture a little taste of this commute, so well, here it is:

TRMNL

Fri, 16 May 2025 09:02:00 GMT

Note: Since writing this, there is an official Notion Plugin, but it still may be desirable to create your own if you really want to customize it.

I picked up this thing recently: https://usetrmnl.com/

I dug that it was e-ink, having previously been an e-ink dumb phone user, and the documentation on building custom plugins made it seem super easy, so I was intrigued.

The design system is really pleasing, and the simplicity of it is really nice. I’m not a big fan of screens being all over the home. We have one of those frame tvs that appears pretty convincingly to be a framed picture when the tv isn’t in use, and other than our laptops floating away from our desks on occasion, we don’t have any screens that are just on and sitting around.

I liked the idea of a little display to show our shared calendar, some to-do lists, and maybe a few other fun little things, but a full color screen on constant rotation felt like the kind of noise we typically try to avoid in our house. So this seemed great!

And so far, it is! Much like my Light Phone, it took a little getting used to its limitations, but after that it becomes pretty enjoyable. In the case of TRMNL it’s main limitation is that it isn’t interactive at all. It’s just a display. There aren’t even any physical buttons to push to rotate through screens—you set intervals for screens in a web-based portal.

The other great thing about it is how easy they made creating custom plugins. In TRMNL land a plugin is the whole thing. It’s what you choose to be displayed on the device. They have a ton to choose from in their marketplace, but making your own is pretty dang easy if you’re at least a little bit of a programmer.

I haven’t spent too much time exploring the possibilities, but I did make my own plugin to display a list of to-dos from a database in Notion, and it was super easy. After creating a new private plugin in the TRMNL portal all you really need to do is the following:

Go to your Notion profile and create a new internal integration
Grab the API secret for that integration
Find the database ID of the Notion databse you want to read and display in your plugin. If you copy the link to your database in Notion it will be the long string in the URL after your username (ex: notion.so/username/XXXXXXXXXXXXXXXXXXXXXXXXXXX)
In your TRMNL plugin settings add the URL (with the database ID you just grabbed) https://api.notion.com/v1/databases/XXXXXXXXXXXXXXXXXXXXXXXXXXX/query to the "Polling URL(s)" field
Add authorization=Bearer YOUR_NOTION_INTEGRATION_API_SECRET to the "Polling Headers" field
Save, and go to "Edit Markup" to edit how you want to display your Notion data

I know that last one is pretty vague, but TRMNL has a really nice editor (pictured below) that shows you exactly what variables you have access to from TRMNL, and if you've connected to the Notion API correctly, the data it's getting back from Notion. They also have extensive documentation on their very nice design system.

And that's pretty much it! Even if I don't get too much more creative than this, it's already been a really nice thing to have up on the fridge. If I do end up doing anything else interesting with it, I'll make another post about it and link to it here.