Short answer: A loading animation tells people your site is working on their request. Show nothing for waits under a second, a spinner or a skeleton screen for waits up to about 10 seconds, and a progress bar for longer waits or uploads. Tell screen readers the same in a status message, and say when the wait ends.
What a loading animation is for
NN/g, the usability research group, says progress indicators reassure people that the system is working and reduce their uncertainty. They also give people something to look at, which makes the wait easier to bear.
Its response time limits help decide when to show one. About 0.1 second feels instant, about 1 second keeps the flow of thought, and about 10 seconds is the limit for keeping attention on the task.
The moment someone clicks, the page should show it got the request, for example with a button that looks pressed.
Spinner, skeleton screen or progress bar
| Indicator | Best for | Wait |
|---|---|---|
| No indicator | Quick answers: show the result | Under 1 second |
| Spinner (a looped animation) | One part of the page, such as a card or a video | 2 to 10 seconds |
| Skeleton screen | A full page loading, shown as gray blocks in its layout | 1 to 10 seconds |
| Progress bar (percent done) | Uploads, downloads and other long processes | 10 seconds or more |
| Frame-only skeleton (header and footer only) | Not recommended: a mostly blank screen looks broken | Any wait |
From NN/g’s articles on skeleton screens, progress indicators and response times, read November 4, 2026.
When to show it, and what to say
Under a second, skip the loader. NN/g says spinners and skeleton screens aren’t necessary there, and a quick flash can make people feel they can’t keep up.
Between 2 and 10 seconds, a spinner or a skeleton screen works. A short text helps too, such as “Loading comments…”, so people know why they are waiting.
From 10 seconds on, show how much is done and roughly how long is left. For long tasks, give people a way to stop.
NN/g advises against a static “Loading…” that never moves, and against warnings not to click twice. Show that the first click was accepted instead. A skeleton screen doesn’t replace speed work, such as the image changes in our lazy loading images guide.
Make the wait clear to screen readers
WCAG counts the waiting state of a page and the progress of a process as status messages. Screen readers should get them without the focus moving. In the W3C’s example, a busy icon appears after someone starts a process, and the screen reader announces “application busy”.
MDN describes the status role as a live region for advisory information, polite by default, which is where your “Loading…” text belongs. While an area loads, set aria-busy="true" on it, then set it back to false, so screen readers wait for the finished content. Our aria-live guide shows how to announce a change without moving the focus.
When the wait ends, say so. If a busy message disappears with nothing in its place, people who can’t see the screen won’t know, and the W3C suggests a status message such as “system available”.
A progress bar needs a name too. MDN notes that a <progress> element with no value is indeterminate, and that in most cases it needs an accessible label. Our aria-label guide covers how to name it.
Motion and long waits
WCAG asks for a way to pause, stop or hide moving content that starts on its own, lasts more than five seconds and runs next to other content. A preload animation can count as essential when nothing can be done during it and hiding the progress could make people think the page froze.
NN/g also notes that animated skeletons, with a pulse or a shimmer, can distract some people or create accessibility problems. Our website animation guide covers reduced motion and pause controls.
How to add a loading state
- Measure the real wait, on a phone too.
- Under about a second, show the result and skip the loader.
- For 2 to 10 seconds, use a spinner on the part that loads, or a skeleton screen for a full page.
- For 10 seconds or more, show progress, an estimate and a way to stop.
- Add a short text that says what is loading.
- Put that text in a status message, and mark the loading area busy.
- Say when it finishes, and let reduced motion stop the animation.
How our contact form handles the wait
Our contact form is the main way to write to us. On November 4, 2026, we tested how it handles the wait, in English and Spanish, on a computer and on a phone. A test browser held our message and never let it leave.
The send button turns busy the moment it’s pressed, so a second click can’t send the message twice. If no answer comes within 0.3 seconds, our loader fades in where the button’s label was, at the same width, and screen readers hear “Sending…”.
When the answer came back in 0.1 seconds, nothing appeared: no loader and no message. When it came back in 0.4 seconds, the loader stayed 0.36 seconds instead of blinking, because once it shows it waits at least 0.35 seconds.
When the message arrives, the form gives way to a confirmation that screen readers announce as a status message. With reduced motion turned on, the loader holds still: across 15 samples it showed a single drawing, against 9 or 10 different ones with motion on.
Before you publish
- Quick answers show the result with no loader.
- Waits of 2 to 10 seconds show a spinner or a skeleton screen.
- Waits of 10 seconds or more show progress and a way to stop.
- A short text says what is loading.
- Screen readers hear when the wait starts and when it ends.
- The animation holds still when reduced motion is on.
RememberA loader is a promise that something is happening. Show it only when the wait is real, say what is loading, and tell everyone when it’s done.
Forms and pages that respond clearly are part of our web design service.
Quick answers about loading animations
What is a loading animation?
A visual sign that your site is working on a request, such as a spinner, a skeleton screen or a progress bar. NN/g notes that progress indicators reassure people that the system is working and give them something to look at while they wait.
Should I use a spinner or a skeleton screen?
For a wait under 10 seconds, either can work. NN/g says spinners suit a single module, such as a card or a video, while skeleton screens suit a full page because they show its layout. Past 10 seconds, use a progress bar.
Do I need a loader for fast loads?
No. If a page loads in under a second, NN/g says spinners and skeleton screens aren’t necessary, and a quick flash can make people feel they can’t keep up. Delay the loader so it only appears when the wait is real.
How do screen readers know a page is loading?
Put a short text such as “Loading…” in a status message, which screen readers announce without moving the focus. Mark the area that is updating with aria-busy until it’s done, then say that it finished, as the W3C suggests.
Do loading animations need a pause button?
WCAG asks for a way to pause moving content that starts on its own, lasts more than five seconds and runs next to other content. The W3C treats a preload animation as essential when nothing else can be done meanwhile and hiding the progress could make people think the page froze.
Sources
Read on November 4, 2026. W3C Web Accessibility Initiative: Understanding SC 4.1.3 Status Messages (Level AA) and Understanding SC 2.2.2 Pause, Stop, Hide (Level A). MDN Web Docs: ARIA: aria-busy attribute, ARIA: status role and <progress> HTML progress indicator element. Nielsen Norman Group: Skeleton Screens 101, Progress Indicators Make a Slow System Less Insufferable and Response Times: The 3 Important Limits. Our case: our contact form, tested in a browser on November 4, 2026.