Your award-winning site might be locking people out

The showcase reels are stacked with 3D terrain, WebGL flowers, and cursor effects that pull like a magnet. The craft is real and it's worth studying. But the same week those sites won awards, the numbers on accessibility and basic usability came in ugly. Both things are true at once. Let me catch you up on what that means for your team.

The craft is getting scary good

The bar for motion work keeps climbing. Garden Eight, a seven-person Tokyo studio, described their aircord site as one continuous state change between 2D and 3D, where video, typography, scrolling, camera movement, and shaders were designed as a single change of state. No page swap. The screen just transforms. That only works because the same person handled design and development.

The technical honesty is refreshing too. The Cerebrium team shipped in WebGL, not WebGPU, because the newer path took close to twenty seconds to compile shaders on their reference machine. They wanted it, they built it, they cut it. And a solo hiking site, Ridgeline, put real elevation data into a live Three.js scene inside Webflow in about a week, driven by an AI agent through the Webflow MCP.

Where the same sites lose points

Here's the part the highlight reels skip. The awards break the score down, and accessibility is the soft spot. The Lacoste Polo Factory site scored a 9.20 on animations and a 6.00 on accessibility, with one dev reviewer handing it a 5. The Spotify Wrapped Party experience landed a 7.00 on accessibility, the second-lowest mark on its dev card.

These are top-tier teams with big budgets. The motion gets a 9. The thing that decides whether a screen reader user can use the page gets a 6. That gap is a choice, made under deadline, over and over.

The number that should stop you

Zoom out and it gets worse. WebAIM runs the top million home pages through automated WCAG testing every year, and the result Zeeshan Khalid points to is that 95.9% of them still fail. Buttons labeled "click here." Images that announce themselves as "image.jpg." He watched a friend with a visual impairment give up on a train ticket after fifteen minutes and say, "It's just easier this way."

That's not exotic. Those are the cheapest fixes in the book. Alt text and real button labels are not a WebGL research problem. They're a whose-job-is-it problem.

Pretty is not the same as usable

And usable is where money actually moves. MeasuringU benchmarked eight big health insurance sites and found the group dropped from the 67th percentile in 2018 to the 30th today, after eight years of digital investment. Seven of the eight had negative Net Promoter Scores. Highmark hit minus 47%.

The top complaint across all eight was people not being able to find what they came for. As the report puts it, that's a navigation problem, not a content problem: the info is there, buried under menus built around the insurer's org chart instead of the few things a member shows up to do. Spending went up. The experience went down.

The deep cut

Garden Eight said the thing the awards data proves the hard way. In their work, motion is not treated as decoration, and the first priority is not to interfere with user actions or the flow of content. The distortion effect from Dash carries the same lesson: their own takeaway was that the hero effect changes significantly on touch devices, something they'd consider earlier next time.

So the move on Monday is small and boring. Add accessibility to your definition of done, at the same table where you sign off on the animation. Put alt text, button labels, keyboard tabbing, and contrast on the same checklist as the scroll timing. It costs you almost nothing and it's the exact thing the 95.9% skipped. The craft and the inclusion ship in the same pull request, or the craft is only serving the people who were fine anyway.

Three questions for your team

1. On our last shipped project, what accessibility score would it get, and who on the team can actually answer that without guessing?
2. Are our fanciest interactions gated on cursor movement, and what happens to them on a phone or with a keyboard?
3. If we ran our own top task, like "find an in-network doctor" or "find the price," how many clicks and dead ends does a real user hit before they get there?