Accessibility Basics

<code class="language-html"><button 
<p>  aria-role="button" </p>
<p>  aria-label="Submit the form"</p>
<p>  class="custom-button"</p>
<p>></p>
<p>  🔒 Submit</p>
<p></button></code>

with just a class="button".

Common role pitfalls to avoid:

• ❌ Using role="button" on a tag (use role="link" instead for hyperlinks)
• ❌ Forgetting aria-label when the button has no visible text (critical for screen readers)
• ❌ Over-specifying roles (e.g., role="button" on a —native HTML already handles this)

Role	When to Use It	Example Element
button	Custom interactive controls
link	Custom hyperlinks (not native )
tablist	Groups of tab buttons (for tab navigation)
tabpanel	Content sections that switch with tabs

💡 Pro Tip: Always test your ARIA roles with axe DevTools or Lighthouse to catch missing or conflicting roles.

---

Keyboard Navigation: Making Your Interface Tab-Friendly

Keyboard navigation is the lifeline for users who can’t use a mouse—whether due to motor impairments, physical limitations, or simply preferring keyboard shortcuts. A fully accessible interface must be navigable via keyboard alone (using Tab, Shift+Tab, arrow keys, and Enter).

Core requirements for keyboard accessibility:

1. All interactive elements must be focusable (e.g., buttons, links, form inputs)
2. Focus states must be clearly visible (e.g., with :focus CSS)
3. Tab order must follow logical flow (e.g., from top to bottom, left to right)
4. No skipped elements—every interactive item must be reachable via keyboard

Here’s a runnable example of a keyboard-friendly form:

<code class="language-html"><form>
<p>  <label for="email">Email</label></p>
<p>  <input type="email" id="email" aria-label="Email address"></p>
<p>  </p>
<p>  <label for="password">Password</label></p>
<p>  <input type="password" id="password" aria-label="Password"></p>
<p>  </p>
<p>  <button type="submit" aria-label="Submit form">Sign In</button></p>
<p></form></code>

Why this works:

• Every input has a clear aria-label for screen readers
• The form follows natural tab order (email → password → submit)
• The button has a meaningful aria-label (critical for screen readers)
• No JavaScript is needed—this is 100% keyboard-accessible by default

Critical keyboard navigation patterns:

1. Tab order: Start at the top of the page, move left-to-right, top-to-bottom
2. Focus indicators: Always use :focus CSS to show a visible focus state (e.g., a border or outline)
3. Skip links: For long pages, add a Skip to content link at the top (e.g., Skip to content)
4. No focus traps: Ensure users can always escape a modal or dialog via Esc key

Real-world example:

Imagine a user with limited dexterity trying to fill out a form. Without keyboard navigation, they’d be stuck. With it:

• Press Tab → Focuses on email input
• Press Enter → Submits the form
• Press Tab → Moves to password input
• Press Esc → Closes any open dialogs

✅ Key takeaway: Your interface must work without a mouse. Test this by pressing Tab repeatedly—every interactive element should be reachable.

---

Alt Text: The Voice for Images

Alt text is the “voice” for images—describing visual content to users who can’t see it (via screen readers, low vision, or slow internet). It’s not just for screen readers; it’s also critical for SEO, image accessibility, and users with cognitive differences.

Why alt text matters:

• Screen readers read alt text instead of images
• Search engines use alt text to index images
• Users with low vision or color blindness need descriptive text

Best practices for alt text:

1. Be descriptive but concise (max 120 characters)
2. Avoid empty alt text (alt="") → Screen readers will skip the image
3. Use context for complex images (e.g., “Chart showing quarterly sales growth from 2020–2023”)
4. For icons: Use alt="Icon description" (e.g., alt="Search icon")

Here’s a real-world example with multiple scenarios:

<code class="language-html"><!-- Good: Describes the image and its purpose -->
<p><img </p>
<p>  src="chart-sales.png" </p>
<p>  alt="Quarterly sales growth chart showing 2020 to 2023 revenue trends"</p>
<p>  class="sales-chart"</p>
<p>></p>

<p><!-- Good: Icon with context --></p>
<p><img </p>
<p>  src="search-icon.svg" </p>
<p>  alt="Search icon for finding products"</p>
<p>  aria-hidden="true" <!-- Hidden from screen readers (only for icons) --></p>
<p>></p>

<p><!-- Bad: Empty alt text --></p>
<p><img src="logo.png" alt=""> <!-- Screen readers will ignore this --></p>

<p><!-- Bad: Overly long alt text --></p>
<p><img src="complex-diagram.png" alt="This image shows a detailed flowchart of the user journey with 12 steps, including login, payment, and order confirmation processes"></code>

When to omit alt text:

• For decorative images (use alt="" or aria-hidden="true" for icons)
• For images that are purely functional (e.g., a button with a background image)

🌟 Pro tip: Test your alt text with screen readers—if it reads clearly and helps users understand the image’s purpose, you’ve got it right.

---

Summary

In this section, we’ve covered the three pillars of accessible web fundamentals:

1. ARIA Roles provide semantic meaning to custom UI elements (e.g., role="button" for interactive controls).
2. Keyboard Navigation ensures interfaces work without a mouse (tab order, focus states, and no focus traps).
3. Alt Text gives images meaningful context for screen readers and users with visual impairments.

These practices aren’t just compliance requirements—they’re the foundation of truly inclusive digital experiences. By implementing them thoughtfully, you create interfaces that work for everyone, from users with disabilities to those in low-bandwidth environments. Remember: accessibility is a journey, not a destination. Start small, test relentlessly, and keep learning. 🌟