An adaptive learning platform that teaches digital accessibility in a way that fits your role, learning style, and access needs.
Buttons are everywhere — and one of the most commonly broken accessibility elements in digital products. This lesson teaches what makes a button truly accessible, and how to apply that in your role.
Every accessible button shares five core properties regardless of how it looks: a visible label, all interactive states defined, adequate touch target size, sufficient contrast, and a visible focus indicator.
Try tabbing through the buttons above — the focus ring uses the wA11y orange
outline: none to "look cleaner." This breaks keyboard navigation. Use :focus-visible instead — it shows focus rings for keyboard users only.
These patterns appear across nearly every product — all are preventable at the design or code stage.
<div> or <span> styled to look like a button. Not keyboard-focusable, not announced as a button, doesn't respond to Enter or Space. Fix: always use <button>.outline: none removes the focus indicator. WCAG 2.4.7 failure. Use :focus-visible to preserve focus rings for keyboard users only.aria-label="Close dialog" or a visually hidden <span>.Three questions to test what you've learned.
outline: none. Which WCAG criterion does this violate?:focus-visible — it shows focus rings for keyboard users without affecting mouse interactions.aria-label="Delete item" to the buttonrole="img" to the SVGaria-label on the button provides a descriptive name screen readers announce. Tooltips alone are not reliable for screen reader users.Great work. You've finished this foundational accessibility lesson.