Why does NNG recommend skeleton screens for full page but not for individual components

Question

I need to decide between using a skeleton screen or a loading animation for the contents of a modal.

The modal itself contains an image, title, paragraph, couple of CTAs and a carousel at the bottom that updates the content (like a gallery view).

We were thinking of going ahead with skeleton screens but I recently came across the below NNG article

How do you decide between the two? Spinners are typically best used on a single module, like a video or a card which is on a dashboard. Skeleton screens (with the exception of frame-display ones) are better when the full screen is loading because the wireframe gives users a sense of what the page will look like and, thus, minimizes cognitive load.

Below are the things that confuse me.

1. While it states the above, I could find no reasoning or rationale behind why spinners are typically used for single modules.
2. The words used in this article is "Skeleton screens (with the exception of frame-display ones) are better when the full screen is loading". By full screen, would a modal be in scope here.

At the start of the article it also mentions

This specific type of progress indicator is used exclusively for full-page loads.

So not sure if "full screen" and "Full page" are being used interchangeably here.

So far I've read the below questions

Skeleton Screen or Loading Animation

Does a skeleton loader need to be accessible?

Regarding accessibility, one of the answers include the below, which is a quote from Success Criterion 2.2.2

Moving, blinking, scrolling

For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential;

I can only speculate that the NNG recommendation might have something to do with this. The skeleton loading animation would be "parallel" to other content in case of a card.

Having said this, it still does not address the case of modals where all the other content is now behind the overlay.

I'm leaning towards skeleton screens as the modal is perceived and consumed independent of the rest of the page and it also is quite content heavy. However, wish to know more around the NNG recommendations and any studies / articles around it that I might be missing.

Answer 1

Does the modal load as the page is loading too? For example sometimes sites will load the main page and also load a marketing modal at the same time ("sign up for our newsletter"). So you could end up with the main page skeleton and the modal skeleton at the same time.

I'm going to ignore that situation for now and assume the user performed some action and now the modal is going to load. I'm also going to assume that your modal is a true modal and does not allow any kind of keyboard interaction with the main page "behind" the modal (and that includes trapping the screen reader focus inside the modal, typically done with aria-hidden on the non-modal content).

If those assumptions are true, then a modal dialog is "separate" from the main page so it's perfectly fine to use a skeleton. It would not fall within the "(3) is presented in parallel with other content" so WCAG 2.2.2 would not apply.

A skeleton screen is just a fancy spinner or busy indicator and the same accessibility considerations for a busy indicator should be applied to a skeleton. This might include the use of aria-busy and depending on how long it takes for the modal to load, you might want to update assistive technology periodically via aria-live.

Having said all that, I've never seen a modal use a skeleton screen and I rarely see them use a spinner or busy indicator. Most modals display fairly quickly.

Answer 2

"Spinners are typically best used on a single module,...", The phrase "...best used..." means you can do something else (aka use skeleton loader) if it fits your situation.

Both the skeleton loader and the spinner help with reducing the cognitive issues that come with not knowing if the app is responsive or not. Though, personally, I'd rather the skeleton loader, mainly because anything that gets the user to familiar ground is good. And a loader that mimicks the layout of the real data's structure is as good as it gets for now at least.