Accessible Scrolljacking
I build scrolljacked websites. I also spent a chunk of my career doing ADA compliance work. Depending on who you ask, that makes me either a hypocrite or exactly the right person to write this post.
Because the critics of scrolljacking — the usability researchers who’ve spent a decade calling it scroll hijacking — are not wrong. Their list of charges is fair. It takes control away from the person holding the mouse. It keeps animating at people whose operating system is explicitly asking it not to — and for someone with a vestibular disorder, unwanted motion isn’t an annoyance, it’s nausea. It strands keyboard users when the tab order stops matching what’s on screen. It breaks the back button. Every one of those failures is real, and I’ve seen every one of them shipped.
Here’s the part I’d push back on: none of it is the technique. It’s the implementation. Each charge has a direct, buildable answer, and this site — the one you’re reading right now — is where I prove it. (If you want the definition-level version first, start with What Is Scrolljacking?)
Answer one: surrender completely to reduced motion
Every modern operating system has a “reduce motion” setting, and every browser passes it
to your CSS as prefers-reduced-motion. Most animated sites that bother to check it just
tone things down — shorter durations, smaller slides. That misses the point. The person who
flipped that switch doesn’t want less of the ride. They want off.
So this site surrenders completely. Reduced motion on means no scroll interception, no slide animations, no deck — you get a normal, scrolling website, because that’s what was asked for. There’s nothing to opt out of when nothing forces itself on you.
Answer two: keep the web’s furniture
The classic scrolljacked site is one enormous page pretending to be five, which is why the back button dies. This one is the opposite: five real pages pretending to be one. Every section of the deck that matters is a real URL — you can bookmark it, share it, land on it from a search result, and hit back and end up exactly where back should take you. Google indexes pages, not animations, so the search engine sees a perfectly ordinary website. The trick is that moving between those real pages is animated to feel identical to moving within one.
Answer three: the keyboard is a first-class citizen
Arrow keys move the deck the same way a scroll wheel does. Tab order follows the visual order, there’s a skip link before the navigation, and nothing traps focus inside a section. If you navigate by keyboard, or your screen reader does, the page underneath the motion is honest — real headings, real landmarks, real links — because it’s a real page.
Answer four: let the browser drive
The old jank came from JavaScript arm-wrestling the browser’s scroll thread. The View Transitions API ends the fight: the browser’s own compositor runs the animation, which is why the motion here feels native instead of faked. I break down the full mechanics on the web development page if you want to see how the engine works.
Here’s the test I’d give any scroll-driven site, including mine: turn on reduce motion. Unplug your mouse. Hit the back button. If it survives all three, the motion was a choice. If it doesn’t, the motion was the site. Accessibility isn’t the tax you pay for the fancy scroll — it’s the thing that makes the fancy scroll defensible.