The Train Cursor Paradox: Why Whimsy and Accessibility Are Natural Allies

By Joshua Gallagher, Custody & Agency | January 2026

There's a lie we tell ourselves in web development.

It goes something like this: websites can be fun and whimsical, or they can be accessible and performant, but choosing both is impossible. Pick your poison. Choose your sacrifice. Fun comes at the cost of inclusion. Delight demands performance penalties. Whimsy excludes users with disabilities.

I'm here to tell you that's complete nonsense.

Recently, I built a train cursor effect for an ecommerce site in the hobby supplies space. A little SVG locomotive that follows your mouse around, trailing puffs of smoke as you explore the page. Delightful, right? Also completely unnecessary. Pure decoration. The kind of feature that gets cut when budgets tighten or timelines compress.

But here's the thing: that "frivolous" train cursor taught me more about responsible web development than a dozen enterprise CRUD apps ever could.

The Common Implementation Pattern

Let me show you what most developers do when they want to add something whimsical to a site. They write code that looks like this:

function updateTrain() {
    trainX += (mouseX - trainX) * 0.15;
    trainY += (mouseY - trainY) * 0.15;
    train.style.left = trainX + 'px';
    train.style.top = trainY + 'px';
    requestAnimationFrame(updateTrain); // Always running
}

document.addEventListener('mousemove', (e) => {
    const smoke = document.createElement('div');
    smoke.className = 'smoke-particle';
    document.body.appendChild(smoke); // No limits, no cleanup
});

updateTrain(); // Starts immediately, never stops

Looks reasonable enough, right?

This code creates significant problems.

That requestAnimationFrame loop runs at 60 frames per second whether your cursor is moving or sitting still. It runs when you're reading text. It runs when you've switched to another tab. It runs when you've minimized the browser entirely. That's roughly 3,600 wasted function calls per minute doing absolutely nothing productive.

The smoke particle creation is even worse. No limits means memory grows infinitely. Every mouse movement creates a new DOM element. Move your cursor around for thirty seconds and you've created hundreds of orphaned divs that the browser has to manage. On an older computer (the kind of machine a hobbyist might have in their workshop) this code will bring the entire page to its knees.

And accessibility? Users with vestibular disorders will experience nausea from the constant motion. Screen reader users will hear phantom announcements about decorative elements. Keyboard-only users will wonder why everyone else is having fun while they're excluded.

This is the "whimsy tax" developers have accepted as inevitable. We shrug and say, "Well, it's just a fun extra feature. Users can deal with it."

They can. And they will. They'll close the tab and never come back.

What Accessibility Actually Means

Here's what changed my approach entirely: about 20% of the population has some form of motion sensitivity. That's one in five people. The majority of your audience, just scattered across multiple visits.

The Web Content Accessibility Guidelines exist for a reason. They're the bare minimum requirements for creating an inclusive web. WCAG 2.3.3 specifically addresses animation from interactions, and WCAG 2.2.2 requires users to be able to pause, stop, or hide moving content.

So how do you respect these standards while still creating something delightful?

You start by checking what the user actually wants. Modern browsers expose motion preferences through CSS and JavaScript. It takes exactly one line of code:

const prefersReducedMotion = 
    window.matchMedia('(prefers-reduced-motion: reduce)').matches;

That's it. That single boolean tells you whether the user has explicitly asked their operating system to minimize motion. If it's true, your decorative animation should cease to exist. Period. The reduced version is no version. The slower version is no version. Complete absence is the only acceptable state.

// Initial check on page load
const motionQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
let trainEnabled = !motionQuery.matches;

// Listen for preference changes mid-session
motionQuery.addEventListener('change', (e) => {
    if (e.matches) {
        // User just enabled reduced motion
        trainEnabled = false;
        stopTrainEffect();
        cleanupAllParticles();
    }
});

function stopTrainEffect() {
    if (animationFrameId) {
        cancelAnimationFrame(animationFrameId);
        animationFrameId = null;
    }
    train.classList.add('hidden');
    isMoving = false;
}

But respecting system preferences is just the start. You also need to provide user control. Some users are fine with animation most of the time but want to disable it on specific sites. Others want to try it out and turn it off if it bothers them.

The solution? A toggle button. Visible, clearly labeled, keyboard-accessible. One click to disable. Preference saved in localStorage so it persists across sessions. No dark patterns. No buried settings. Just a straightforward: "This effect is currently ON. Click here to turn it OFF."

// Persistent user preference with localStorage
let trainEnabled = localStorage.getItem('trainCursorEnabled');

if (trainEnabled === null) {
    // First visit - respect system preference
    trainEnabled = !prefersReducedMotion;
    localStorage.setItem('trainCursorEnabled', trainEnabled);
} else {
    // Return visitor - use their saved choice
    trainEnabled = trainEnabled === 'true';
}

toggleButton.addEventListener('click', () => {
    trainEnabled = !trainEnabled;
    localStorage.setItem('trainCursorEnabled', trainEnabled);
    updateToggleButton();
    
    if (!trainEnabled) {
        stopTrainEffect();
        smokeParticles.forEach(particle => particle.remove());
        smokeParticles.length = 0;
    }
});

Performance Is a Feature

Accessibility gets the headlines, but performance is equally critical. A slow website excludes people. People on older hardware, people in rural areas with slow internet, people using their phone's mobile data. They all deserve a fast experience.

The naive train cursor implementation I showed earlier had some horrifying performance characteristics. Let's look at the numbers:

How do you achieve those kinds of improvements? Smart lifecycle management.

Conditional Animation Loops

First, the animation loop should only run when it needs to. When the user's cursor is idle for more than a second, cancel the requestAnimationFrame entirely. Zero CPU cycles wasted on invisible effects.

let animationFrameId = null;
let isMoving = false;

function updateTrainPosition() {
    // Early exit if disabled or idle
    if (!trainEnabled || !isMoving) {
        animationFrameId = null;
        return; // STOP the loop completely
    }
    
    // Calculate movement delta
    const dx = mouseX - trainX;
    const dy = mouseY - trainY;
    
    // Only update if meaningful movement exists
    if (Math.abs(dx) > 0.1 || Math.abs(dy) > 0.1) {
        trainX += dx * 0.15;
        trainY += dy * 0.15;
        train.style.left = trainX + 'px';
        train.style.top = trainY + 'px';
    }
    
    // Queue next frame only if still moving
    animationFrameId = requestAnimationFrame(updateTrainPosition);
}

// Mouse movement handler with idle timeout
let hideTimeout;
document.addEventListener('mousemove', (e) => {
    if (!trainEnabled) return;
    
    mouseX = e.clientX;
    mouseY = e.clientY;
    
    if (!isMoving) {
        isMoving = true;
        train.classList.remove('hidden');
        // START the loop
        if (!animationFrameId) {
            animationFrameId = requestAnimationFrame(updateTrainPosition);
        }
    }
    
    clearTimeout(hideTimeout);
    hideTimeout = setTimeout(() => {
        isMoving = false; // Will stop loop on next frame
    }, 1000);
});

Particle Lifecycle Management

Second, implement particle limits. The smoke trail requires exactly twenty concurrent puffs for a visually pleasing effect. Use a queue structure. When you hit the limit, remove the oldest particle before creating a new one. First in, first out. Simple, predictable memory usage.

const smokeParticles = [];
const maxSmokeParticles = 20;

function createSmoke(x, y) {
    // Remove oldest if at capacity
    if (smokeParticles.length >= maxSmokeParticles) {
        const oldest = smokeParticles.shift();
        if (oldest && oldest.parentNode) {
            oldest.remove();
        }
    }
    
    const smoke = document.createElement('div');
    smoke.className = 'smoke-particle';
    smoke.setAttribute('aria-hidden', 'true');
    smoke.style.left = x + 'px';
    smoke.style.top = y + 'px';
    document.body.appendChild(smoke);
    smokeParticles.push(smoke);
    
    // Self-cleanup with tracking
    setTimeout(() => {
        if (smoke.parentNode) {
            smoke.remove();
        }
        const index = smokeParticles.indexOf(smoke);
        if (index > -1) {
            smokeParticles.splice(index, 1);
        }
    }, 1500);
}

Page Visibility API Integration

Third, and this is huge: use the Page Visibility API. When someone switches tabs, your decorative effect should pause completely. This single optimization can save hours of battery life on laptops.

document.addEventListener('visibilitychange', () => {
    if (document.hidden) {
        // Tab is now hidden
        isMoving = false;
        train.classList.add('hidden');
        
        if (animationFrameId) {
            cancelAnimationFrame(animationFrameId);
            animationFrameId = null;
        }
    }
    // When tab becomes visible again, effect will
    // restart naturally on next mousemove
});

The result? A 95% reduction in idle CPU usage. That's the actual measured improvement from implementing proper start/stop logic, particle limits, and visibility handling.

The Details That Compound

There are dozens of smaller optimizations that compound into significant improvements. Throttling particle creation to every 150 milliseconds instead of every mousemove event. Using CSS will-change hints to enable GPU acceleration. Setting pointer-events: none on decorative elements so the browser skips hit-testing entirely.

.train-cursor {
    will-change: transform; /* GPU acceleration hint */
    pointer-events: none;    /* Skip hit-testing */
    transform: translate(-50%, -50%);
}

.smoke-particle {
    will-change: transform, opacity; /* Optimize animations */
}

ARIA attributes matter too. The train and smoke particles are purely decorative. They convey no information that exists nowhere else. So they need aria-hidden="true" and role="presentation" to tell screen readers to skip them completely. The toggle button, on the other hand, needs a proper aria-label that explains its purpose: "Toggle train cursor effect."

<div class="train-cursor" aria-hidden="true" role="presentation">
    <svg aria-hidden="true">...</svg>
</div>

<div class="smoke-particle" aria-hidden="true"></div>

<button aria-label="Toggle train cursor effect">
    🚂 Train Effect: ON
</button>

"Making something accessible is making it better. Full stop."

Want to know the best part? All these optimizations and accessibility improvements took about ten hours of additional work. Ten hours to go from "problematic and exclusionary" to "delightful and responsible." Ten hours to create something worth being proud of.

The return on that investment? Legal protection from accessibility lawsuits that average $30,000 in settlements. Better SEO from improved performance scores. Higher user satisfaction from respecting preferences. Competitive advantage from demonstrating attention to detail. A portfolio piece that shows actual craftsmanship.

But honestly? The ROI that matters most is being able to look users in the eye and say: "Yes, this is whimsical and fun. And yes, it's also built for everyone."

Testing and Validation

You cannot ship responsible code without testing it. Here's the validation checklist I use:

Reusable Patterns

The techniques used in the train cursor apply to any decorative effect. Here's a template you can adapt:

class ResponsiveAnimation {
    constructor(element, options = {}) {
        this.element = element;
        this.enabled = false;
        this.animationId = null;
        
        // Check motion preferences
        this.motionQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
        this.checkMotionPreference();
        
        // Listen for preference changes
        this.motionQuery.addEventListener('change', () => {
            this.checkMotionPreference();
        });
        
        // Listen for visibility changes
        document.addEventListener('visibilitychange', () => {
            if (document.hidden) {
                this.pause();
            }
        });
    }
    
    checkMotionPreference() {
        if (this.motionQuery.matches) {
            this.disable();
        } else {
            // Check user's saved preference
            const saved = localStorage.getItem('animation-enabled');
            this.enabled = saved === null ? true : saved === 'true';
        }
    }
    
    start() {
        if (!this.enabled || this.animationId) return;
        this.animate();
    }
    
    pause() {
        if (this.animationId) {
            cancelAnimationFrame(this.animationId);
            this.animationId = null;
        }
    }
    
    animate() {
        // Your animation logic here
        
        this.animationId = requestAnimationFrame(() => this.animate());
    }
    
    toggle() {
        this.enabled = !this.enabled;
        localStorage.setItem('animation-enabled', this.enabled);
        if (!this.enabled) this.pause();
    }
}

What This Means For You

If you're a developer, accept that fun and responsible are compatible goals. You can have both. It just requires giving a damn and investing the time to do it right.

Check prefers-reduced-motion before every animation. Every single time. Provide user controls with persistent preferences. Use the Page Visibility API to pause effects in background tabs. Implement particle limits for generative systems. Add proper ARIA attributes. Test with screen readers. Measure your performance improvements.

If you're a designer, design the toggle controls into your whimsical features from the start. Consider motion sensitivity in your initial concepts. Plan for reduced-motion alternatives. Specify performance budgets. Include accessibility annotations in your design files. Test with real users who have disabilities.

If you're a project manager, budget time for accessibility from the beginning. Make WCAG compliance a requirement in your acceptance criteria. Prioritize user control over forced experiences. Test with diverse users across different ages, abilities, and technologies.

The Real Lesson

This is a case study about values, dressed up as a case study about a train cursor.

Every technical decision is an ethical decision. When you ship code that ignores motion preferences, you're deciding that your fun matters more than someone else's health. When you create memory leaks that slow down older computers, you're deciding that performance is optional for people who can't afford new hardware. When you skip accessibility testing, you're deciding that disabled users are worth less of your time.

These are choices about who gets to participate in the web we're building.

The train cursor effect works because it respects people. It respects their motion preferences. It respects their hardware limitations. It respects their autonomy to choose whether they want it. It respects the WCAG standards that exist to protect them.

And in return, it creates something genuinely delightful. The constraints force creativity. The limitations inspire better solutions. Caring about users produces better work.

That little train cursor, trailing its smoke across a hobby supplies website? It's proof that we can do better. We can create experiences that make people smile without making other people sick. We can add personality without sacrificing performance. We can be creative while remaining ethical.

We just have to give a damn.

Joshua Gallagher runs Custody & Agency, a performance marketing agency specializing in SEO, AEO, and ADA compliance for regulated industries. He's been building websites since the Google AdWords beta program and believes the web deserves to be both fun and inclusive. Find him at custodyandagency.com.

Technical implementation and code examples are available upon request. The animated accessibility icon in this article respects prefers-reduced-motion and includes proper ARIA labels, because practicing what you preach matters.