Can Website Animation Make People Sick? Why Flashing Headers Are an Accessibility Issue

Before anything else: I have already spoken with the founder. I flagged the issue, explained the harm, and they responded immediately with a commitment to fix it. I will not identify them or share our conversation.

TL;DR: Flashing website content and uncontrolled animation can cause physical harm. Accessible motion design means addressing flash hazards, giving people control, and respecting reduced-motion preferences before exposure. This morning, a website header triggered symptoms that cost me the recording session I had planned.

And yes. I’m pissed.

This morning, I opened a LinkedIn message inviting me to look at a creative portfolio.

I clicked. The website loaded with a flashing motion header. Within moments, my day changed.

I have a vestibular disability. As I write this, I have a bad migraine, pain on the right side, blurry vision, and spots in my vision.

Today, I was supposed to record the introduction to my new podcast. I had plans. Creative energy. Something I was excited to make. Now, I cannot tolerate the studio lights.

Someone else’s website design made a decision about what my body could do today.

What does harmful website motion actually cost someone?

In a design review, that header might be described as bold. Dynamic. Attention-grabbing.

From this side of the screen, the words are different. Pain. Medication. Lost time. Canceled plans. The animation stayed on the website. The consequences followed me after I closed it.

That is the part I need creative teams, founders, marketers, and developers to understand. A visitor leaving your site does not necessarily end the experience you created for them. Sometimes, they are still dealing with it hours later.

I spend my career talking about accessibility. I also live with the consequences of people overlooking it. This morning, those two realities collided before my workday had properly started.

Can flashing content and animation cause physical harm?

Yes. W3C’s accessibility guidance identifies migraines, dizziness, nausea, and seizures as potential effects of flashing content. Certain flashing patterns can trigger seizures in people with photosensitive seizure disorders.

Motion sensitivity also deserves attention beyond flashing. W3C explains that animation can trigger vestibular symptoms, including dizziness, nausea, and headaches.

These experiences vary. My reaction does not establish what every visitor will experience, or whether a particular animation exceeds a technical threshold. It establishes that I was harmed.

People arrive at your website with bodies, nervous systems, and disabilities that your creative brief may never have considered.

They still belong in the audience you are designing for.

Why isn’t a pause button enough?

A pause button matters. But it cannot undo exposure that has already happened. When flashing content starts the moment a page loads, someone has to encounter it before they can find the control.

W3C explicitly explains that a seizure could occur before a person can turn hazardous flashing off. A pause control does not resolve that hazard. Think about the warning before a film or an attraction. There is an opportunity to decide whether to proceed. An autoplaying website header can remove that opportunity entirely.

By the time someone realizes they need to leave, their body may already be reacting.

My recommendation: begin with a static experience and let visitors choose to start nonessential motion. Address flashing hazards in the content itself.

What does WCAG require for flashing and moving content?

Two separate Level A requirements are especially relevant:

• WCAG 2.3.1, Three Flashes or Below Threshold: Content must not flash more than three times in any one-second period unless it remains below defined general-flash and red-flash thresholds. Assessing this requires more than deciding whether something “looks flashy.”

• WCAG 2.2.2, Pause, Stop, Hide: Moving, blinking, or scrolling information that starts automatically, lasts more than five seconds, and appears alongside other content needs a mechanism to pause, stop, or hide it, unless the movement is essential.

These address different problems. Meeting the motion-control requirement does not establish that flashing content is safe.

I did not conduct a formal flash-threshold assessment of this website. I am describing my experience and the design responsibilities it brings into focus.

What happens when AI makes motion design easier?

AI is making it easier to add animation to websites. A prompt, a motion skill, a generated component—and suddenly the page moves. But the ability to generate an effect does not tell you whether people can safely experience it.

When you give an AI tool a brief like “make it bold,” “add movement,” or “make it feel premium,” accessibility needs to be part of that instruction. And it needs to survive whatever the tool generates.

If you are building reusable AI skills for motion design, build accessibility into the skill itself.

Specify static defaults for nonessential motion. Respect reduced-motion preferences. Include accessible playback controls. Avoid flashing effects. Require review before shipping. Then check the result. A prompt asking for accessible animation is a starting point, not proof that the output is accessible.

I use AI. I experiment with it constantly. I want creative people to explore what these tools make possible. I also want us to understand what we are scaling.

A reusable skill can carry thoughtful decisions into hundreds of projects. It can just as easily repeat an omission hundreds of times.

The faster we can generate an experience, the earlier we need to ask what that experience might do to someone.

The visitor experiences the result. They do not get a different nervous system because AI wrote the code.

What should creative teams do differently?

I love creative work. I make video. I experiment with technology. I understand wanting a portfolio to show what you can do. I also know that every creative decision has an audience on the receiving end.

The founder responded with openness and a commitment to change. That matters. I appreciate it. But the next person who encounters a harmful experience might have neither the professional vocabulary nor the energy to explain what happened.

A person should not have to get hurt, identify the problem, and deliver an accessibility lesson before a team addresses it.

That work belongs in the brief, the design review, the build, and the launch decision.

A checklist before you publish website animation

• Remove hazardous flashing. Evaluate flash thresholds where needed; a pause button is not a substitute.

• Give visitors a choice before exposure. Consider a static first frame and intentional playback.

• Provide accessible controls. Make pause, stop, or hide controls easy to find and operate.

• Respect reduced-motion preferences. Test the experience with those settings enabled.

• Review the whole experience. Include videos, GIFs, transitions, backgrounds, and scroll effects.

• Include disabled people in your process. Address known hazards before asking anyone to test.

• Make someone accountable before launch. Accessibility needs an owner while decisions can still change.

I wanted to spend today recording something new. Instead, I am explaining why opening a website left me unable to do it.

If your design can take away someone’s ability to work, create, or get through their day, preventing that harm belongs in the brief.