Skeleton

Use skeleton to achieve loading visual state for asynchronously rendered UI elements.
  • Examples
  • Properties
  • Accessibility

Examples

Web Component

Accessibility

Keyboard Navigation

KeyFunction
TabMoves focus to the next element in the tab sequence. The skeleton itself should not receive focus.
Shift + TabMoves focus to the previous focusable element. The skeleton should not disrupt navigation.

For detailed keyboard interactions, refer to our Keyboard Control Guide.

Visit WebAIM for general keyboard techniques.

Guidance for developers
  • Ensure skeleton components do not receive focus and do not interfere with navigation.
  • Use aria-hidden="true" to hide skeleton placeholders from assistive technologies.
  • Announce dynamic content changes using aria-live regions when skeletons are replaced with real content.
  • Avoid relying solely on skeletons for loading states—provide textual loading indicators when appropriate.
  • Ensure the skeleton component scales appropriately across different screen sizes and devices.
Guidance for designers
  • Design skeleton placeholders to closely match the structure of the actual content.
  • Maintain sufficient contrast between the skeleton and the background to ensure visibility.
  • Use smooth, subtle animations to indicate loading progress without being distracting.
  • Provide alternative loading indicators for users who may not recognize skeleton placeholders.
  • Avoid using skeletons for static content—only apply them for dynamic content that is actively loading.

Explore live examples in the ARIA Practices Guide.

Resources

  • WebAIM ARIA Guide: Techniques for using ARIA effectively.
  • WCAG 2.2 Animation Guidelines: Recommendations for reducing animation effects for users with vestibular disorders.
  • MDN Guide on ARIA Live Regions: Explains how to communicate dynamic changes to assistive technologies.
  • More Accessible Skeletons: Best practices for making skeleton components more accessible.

Other recommendations

Find additional accessibility tips in our Accessibility Guide.

WCAG 2.2 Guidelines

  • Non-text Content: Ensure all badges conveying information have a text alternative. (Level A)
  • Info and Relationships: Maintain semantic structure for screen readers. (Level A)
  • Headings and Labels: Ensure badges have meaningful labels. (Level AA)
  • Labels or Instructions: Provide clear instructions for dismissible badges. (Level A)
  • Name, Role, Value: Define ARIA attributes correctly for badges. (Level A)