how to
How to make a skeleton placeholder accessible (WCAG 2.2 AA)
An accessible skeleton placeholder is a skeleton placeholder that meets WCAG 2.2 Level AA — operable by keyboard alone, properly announced by screen readers (NVDA, JAWS, VoiceOver, TalkBack), with visible focus indicators, sufficient colour contrast, and the correct ARIA semantics where native HTML is insufficient.
What WCAG criteria apply to a skeleton placeholder?
The minimum applicable success criteria are 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 1.4.3 Contrast (Minimum), 2.1.1 Keyboard, 2.4.3 Focus Order, 2.4.7 Focus Visible, 4.1.2 Name, Role, Value, and 4.1.3 Status Messages.
Keyboard interactions
A skeleton placeholder must be operable with only keyboard input. Tab to focus; Enter/Space to activate; Escape to dismiss where applicable; arrow keys within composite widgets per the ARIA Authoring Practices Guide.
Screen reader behaviour
The role of the skeleton placeholder must be announced (e.g. "button", "dialog", "menu"); its state ("expanded", "selected", "checked") must be communicated; and any updates must be announced via live regions if focus does not move to them.
Focus management
On mount, focus stays where the user was. On activation (e.g. opening a dialog), focus moves into the new context. On dismissal, focus returns to the trigger. Focus must not be trapped silently outside an explicitly modal context.
Common failures and how to avoid them
Building a skeleton placeholder from div + onClick instead of a native element — fails 4.1.2. Removing the focus outline without replacement — fails 2.4.7. Auto-opening behaviour without user trigger — frequently fails 3.2.5 Change on Request.
Reference implementations
react-aria (Adobe), Radix UI, Headless UI, and the W3C ARIA Authoring Practices Guide each publish accessibility-tested skeleton placeholder patterns. Use them rather than building your own.
FAQ
Frequently asked questions
Cited answers. Sourced. Updated as standards and case law change.
What is the correct ARIA role for a skeleton placeholder?
The ARIA Authoring Practices Guide (apg.w3.org) lists the recommended role and keyboard pattern for skeleton placeholder and other common widgets. In most cases the native HTML element (where one exists) is preferable to manually-applied ARIA.
Can a skeleton placeholder pass WCAG without ARIA?
Sometimes — when a native HTML equivalent exists. The first rule of ARIA is "do not use ARIA": native HTML communicates more semantics than custom ARIA in most cases.
How do I test a skeleton placeholder for accessibility?
Combine: keyboard-only traversal, NVDA + Chrome screen reader pass, axe-core automated scan, visible focus indicator check, contrast measurement, and 200% browser zoom test.
Stop guessing. Get the audit a Fortune 500 a11y team would have written.
Free audit on your live URL. No sign-up. IAAP-format report. Ready in hours.
founders@accessivepath.com · +977 9851094056