Building Accessible UI Components from Scratch

Accessibility is not a feature you add later. It is a baseline requirement. One in four adults has a disability, and even people without permanent disabilities benefit from accessible design — think about using your phone in bright sunlight or navigating with one hand while holding coffee.

Start with Semantic HTML

Before reaching for ARIA attributes, use the right HTML elements. A <button> is better than a <div onClick>. A <nav> is better than a <div class="navigation">. Semantic elements give you keyboard support and screen reader announcements for free.

This matters more than you think. A <div> with a click handler is invisible to keyboard users unless you add tabIndex, role, onKeyDown, and ARIA attributes manually. A <button> handles all of that natively.

ARIA Attributes That Actually Help

ARIA (Accessible Rich Internet Applications) fills gaps where HTML semantics fall short. Here are the attributes you will use most:

`aria-label` — Provides a text label when there is no visible text. Essential for icon buttons:

<button aria-label="Close dialog" class="p-2 rounded-lg hover:bg-zinc-100 dark:hover:bg-zinc-800">
  <svg><!-- X icon --></svg>
</button>

`aria-expanded` — Tells screen readers whether a dropdown, accordion, or menu is open or closed. Toggle it in your state management.

`aria-live` — Announces dynamic content changes. Use aria-live="polite" for status messages and aria-live="assertive" for errors.

`aria-describedby` — Links an element to its description. Great for form fields with help text or error messages.

Keyboard Navigation

Every interactive element should be reachable and operable with a keyboard. The core patterns:

Tab order. Users press Tab to move between interactive elements. Keep the order logical — usually left to right, top to bottom. Avoid tabIndex values greater than 0; they create unpredictable focus order.

Enter and Space. Buttons should activate on both. Links activate on Enter only.

Escape. Modals, dropdowns, and popovers should close on Escape and return focus to the trigger element.

Arrow keys. Tab lists, menu bars, and radio groups use arrow keys for internal navigation.

Focus Management

Focus management is where most component libraries fall short. Two critical scenarios:

Modal dialogs. When a modal opens, move focus to the first focusable element inside it. Trap focus within the modal so Tab does not escape to the page behind it. When the modal closes, return focus to the button that opened it.

Route changes. In single-page apps, announce route changes to screen readers. Move focus to the main content or a heading after navigation.

Color Contrast

WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. In Tailwind, this means being careful with light grays on white backgrounds.

<!-- Bad: 2.5:1 contrast ratio -->
<p class="text-zinc-400">This is hard to read</p>

<!-- Good: 4.6:1 contrast ratio -->
<p class="text-zinc-600 dark:text-zinc-400">This is readable</p>

Test with browser DevTools — Chrome's color picker shows contrast ratios inline.

Screen Reader Testing

You do not need a screen reader expert on your team. Basic testing catches most issues:

• macOS: VoiceOver is built in. Press Cmd+F5 to toggle it. Navigate with Tab and arrow keys, listen for announcements.
• Windows: NVDA is free and widely used.
• Quick check: Tab through your entire page. If you get stuck anywhere or cannot tell what is focused, that is a bug.

Practical Checklist

For every component you build, verify these:

1. Can you reach it with Tab?
2. Can you activate it with Enter or Space?
3. Does it have a visible focus indicator?
4. Does it have an accessible name (visible text or aria-label)?
5. Does color convey meaning alone? (It should not.)
6. Does it work at 200% zoom?

Every component on UI Drop includes proper ARIA attributes and keyboard support. Browse our navigation components and hero sections to see these patterns applied in real components.