More Accessible Skeletons

I had this post queued up for Halloween because, come on, skeletons, and then life did its thing and now it is a … Thanksgiving post?

Many skeleton patterns do a poor job presenting themselves to screen reader users in any meaningful way. They often stuff aria-busy into their widget, set its value to true when the thing is loading, and leave it at that. Except few screen readers honor aria-busy="true".

This means you need to find some other method to hide the busy content. You could pair aria-busy="true" with aria-hidden="true" to achieve the hiding effect. Or you could use CSS to find any node with aria-busy="true" and set it to display: none, achieving the same effect for screen reader and non-SR users.

HTML & ARIA

If I pull from my block links post (Block Links, Cards, Clickable Regions, Rows, Etc.), I end up with this passable code tweaked to include the skeleton:

<article>

  <div class="skeleton">
    <div aria-hidden="true"></div>
    <div aria-hidden="true"></div>
    <div aria-hidden="true"></div>
    <span>Loading</span>
  </div>

  <div aria-busy="true">
    <h3><a href="[…]">Glossier Roof Party</a></h3>
    <img src="[…]" […] alt="[…]">
    <p>
      Gastropub sartorial venmo hashtag […]
    </p>
  </div>

</article>

The method for making your skeleton will of course vary (for example, <article> is rarely what you would have in practice). In my case I am using some <div>s in the structure of the final card because it was easier for me at the time of prototyping.

Pay attention to the <span> in the <div> with the skeleton class.

CSS

This CSS hides the node with the content (assuming the node exists but the content has not been loaded yet), while also hiding the skeleton when it gets set to aria-hidden="true":

*[aria-busy=true], .skeleton[aria-hidden=true] {
  display: none;
}

The following CSS visually hides the <span>, but still leaves it available for a screen reader:

.visually-hidden, .skeleton > span {
  position: absolute;
  top: auto;
  overflow: hidden;
  clip: rect(1px, 1px, 1px, 1px);
  width: 1px;
  height: 1px;
  white-space: nowrap;
}

It is my standard style block for my visually-hidden class (which is why I left it in the selector). How you reference the styles is up to you; I could have just as easily added the visually-hidden class to the <span> but I wanted to enforce its relation to the skeleton class.

Script

Now the function that hides the skeleton and shows the content needs to do two things:

• flip the aria-busy from true to false on the content node (which will make it visible), and
• add aria-hidden="true" to the node with class="skeleton" (which will hide it).

If you already have some async content action going on, then you probably already have a function to manage some of this. I am not offering anything else here because it will be dependent on your own implementation (which thankfully I do not know).

Example

The following example (at Codepen, or in debug mode) shows a bunch of cards in a loading state. You can press one button to populate each of them with content (after an initial three second delay and then in half-second increments), testing with a screen reader to see the impact of the changing ARIA attributes in action. The other button resets them all to the loading state so you can test again in your next screen reader of choice.

See the Pen UI Skeletons and aria-busy by Adrian Roselli (@aardrian) on CodePen.

Screen Reader Support

My demo works across browsers with current releases of JAWS, NVDA, VoiceOver, and TalkBack.

There is a paragraph at the end of the page that has aria-busy="true" that you can use to test with your configuration. To save you some time, I can tell you that only JAWS 2020 honors it (unless paired with IE11). Narrator (Windows 10 Pro with Edge 87), NVDA (2020.2 with Chrome 87 and Firefox 83), TalkBack (Android 11 with Chrome 86 and Firefox 83), and VoiceOver (iOS 14, macOS 11) treat this content as any other.

Additional Concerns

Skeletons are a bit of an anti-pattern. They are Lilliputian lies you give the user with a grin. A bait-and-switch for the impatient. I urge you to reconsider them if you can. They may have their uses in some places, but they are not a good blanket approach.

I use CSS to make the animation in my example. It is a gradient on a 20 second cycle. However, I also choose to honor users who have set the preference to reduce motion on pages. I only show the animation if the user has not set a preference:

@media (prefers-reduced-motion: no-preference) {
  .skeleton div {
    animation: gradientBG 2s ease infinite;
  }
}

My animation name is gradientBG as defined via @keyframes.

Most skeletons have terrible contrast. Awful. Mine has a 1:1 contrast ratio and if the sun hits my screen just right while my eyes are glazed over from waiting, I may miss these completely. I also consider these a WCAG SC 1.4.11 Non-text Contrast failure since they are being used to convey state.

Finally, for those users who explore a screen by flinging their mouse about (my favorite users when doing interface testing, since you can almost watch what they are thinking), I change the mouse cursor to the waiting pointer:

.skeleton {
  cursor: progress;
}

Now go forth and delete skeletons from your pattern libraries!

Additional Warning

While writing this I came across the Vuetify skeleton, v-skeleton-loader. Vuetify is a Vue UI library based on Material Design. The rendered HTML output of the pattern looks like this:

<div aria-busy="true" aria-live="polite" role="alert" […]>
  […]
</div>

You should already be worried about something that has an alert role yet also wants to be polite. Regardless, there appears to be no test with real content and the lack of notes about screen reader support or workarounds is troubling. If you have an example that I can test in the wild, please share.

In the meantime, probably avoid Vuetify’s skeleton pattern.

Update: 3 December 2020

I updated the example to allow you to set the contrast of the skeleton to the 3:1 ratio that WCAG Success Criterion 1.4.11 Non-text Contrast mandates. I also gave you an option to go full neon.

I also adjusted the animation to stop after 5 seconds, in order to comply with WCAG Success Criterion 2.2.2 Pause, Stop, Hide. You can override it with the button, which makes it easier to see the awesome neon.

29 August 2023: 2.2.2 Note 4 exempts loading indicators if interaction cannot occur for all users while the loader is, er, loading. Skeletons are often used in parallel with other content (think of checking your bank balance while a chunking third-party stock ticker spinning away in the sidebar). As such, this pattern does not get a blanket exemption. Technique C39 :Using the CSS reduce-motion query to prevent motion is sufficient to pass 2.3.3, so it makes sense the Working Group would consider it an option for 2.2.2.

Finally, I found an existing bug against Vuetify’s skeleton and added a note to make the initial report a bit clearer — #10999: [Bug Report] Skeleton loaders should not have aria-busy and alert role. Go like it or hate it or whatever the kids do nowadays on the Github social network.

Update: 14 December 2020

I missed this post, Effective Skeleton Screens, which talks about the visual artifacts and (failed) expectation management of skeleton screens.

While it does not talk about accessibility at all (though it has good alternative text for the images), it is worth considering the larger usability issues with skeletons when applied carelessly.

Even if you can justify their use, now you are on the hook for making them accessible (unless you roll your own).

Update: 26 September 2021

An issue against WCAG has been opened as a result of my post: #2048 Do skeleton loaders fall under “inactive” exemption of 1.4.11 Non-Text Contrast?

I think the main sticking point is how they fit into current WCAG definitions of user interface elements and disabled controls. I make my opinion clear in the thread, but for those interested in the discussion I encourage you to read all the feedback. People far smarter than I are weighing in.

Update: 2 April 2022

I updated the example to support Windows High Contrast Mode, renamed Contrast Themes in Windows 11. I took the 1986 theme and swapped the colors out for system colors and wrapped it in the Frankenquery’s Monster feature query that I outline in my post WHCM and System Colors.

/* Forced colors mode */
@media screen and (-ms-high-contrast: active),
  screen and (forced-colors: active) {
    .skeleton div {
      -ms-high-contrast-adjust: none;
      forced-color-adjust: none;
      background: linear-gradient(-60deg, Canvas 0, Canvas 130px, CanvasText 146px, ButtonText 149px, ButtonText 151px, CanvasText 154px, Canvas 170px, Canvas 100%);
    }
}

This will not work in Firefox at least through version 100 since it does not support forced-color-adjust.

The colors will change based on which theme you have running.

Update: 29 August 2023

Added note above on how and when WCAG SC 2.2.2 applies.