Section 25: Accessibility and Keyboard Navigation

Learning Objectives

• Understand the purpose of web accessibility.
• Use semantic HTML and accessible form labels.
• Provide meaningful alternative text.
• Understand keyboard focus, landmarks and link purpose.

1. What Is Web Accessibility?

Accessibility means designing websites so people with different abilities can use them. This includes people who use screen readers, keyboard navigation, voice control, magnification or other assistive technologies.

2. Prefer Semantic HTML

<header>
  <h1>Codementrix Tutorials</h1>
</header>

<nav aria-label="Main navigation">
  <a href="/">Home</a>
  <a href="/courses">Courses</a>
  <a href="/contact">Contact</a>
</nav>

<main>
  <h2>Latest Lessons</h2>
  <p>Explore practical web development tutorials.</p>
</main>

<footer>
  <p>Copyright Codementrix</p>
</footer>

Semantic elements communicate purpose and create useful landmarks. They help browsers and assistive technologies interpret the page.

3. Meaningful Image Alternatives

<!-- Informative image -->
<img src="html-structure.png" alt="Diagram showing the head and body sections of an HTML document">

<!-- Decorative image -->
<img src="decorative-divider.svg" alt="">

Describe the information conveyed by a meaningful image. An empty alt attribute is appropriate when an image is decorative and adds no information.

4. Accessible Forms

<form action="/contact" method="post">
  <label for="contact-email">Email address</label>
  <input id="contact-email" name="email" type="email" required>

  <label for="contact-message">Message</label>
  <textarea id="contact-message" name="message" required></textarea>

  <button type="submit">Send message</button>
</form>

Do not rely on placeholder text as the only label. Make instructions and validation errors clear and programmatically associated with their fields where appropriate.

5. Keyboard Navigation

Users should be able to reach and operate interactive elements using the keyboard. Native links, buttons, inputs and selects usually provide expected keyboard behavior without extra code.

• Tab usually moves focus forward through focusable elements.
• Shift+Tab usually moves focus backward.
• Enter activates links and commonly activates buttons.
• Space activates buttons and toggles many native controls.

Exact behavior depends on the control, browser and operating system. Test the actual interface rather than assuming every control behaves identically.

6. Do Not Remove Focus Visibility

Keyboard users need to see which element currently has focus. Avoid removing focus outlines unless you replace them with a clearly visible alternative.

<style>
  a:focus-visible,
  button:focus-visible,
  input:focus-visible,
  textarea:focus-visible,
  select:focus-visible {
    outline: 3px solid #2563eb;
    outline-offset: 3px;
  }
</style>

7. Accessible Tables

<table>
  <caption>Course Schedule</caption>
  <thead>
    <tr>
      <th scope="col">Course</th>
      <th scope="col">Duration</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">HTML Mastery</th>
      <td>Self-paced</td>
    </tr>
  </tbody>
</table>

A caption identifies the table, and appropriate header cells help communicate relationships between data.

8. Color and Instructions

Do not communicate errors or status using color alone. Pair color with text, an icon with an accessible name, or another clear indicator. Ensure text and controls have sufficient contrast.

9. Accessibility Testing

• Navigate the entire page with a keyboard.
• Check that form controls have accessible names.
• Inspect heading order and landmark structure.
• Test zoom and responsive layouts.
• Use an automated accessibility checker as a supplement, not a replacement, for manual testing.

Common Mistakes

• Using clickable div elements instead of native buttons or links.
• Leaving meaningful images without appropriate alt text.
• Using placeholders as the only form labels.
• Removing keyboard focus indicators.
• Using color alone to indicate an error.

Practice Exercises

1. Convert a generic page layout into semantic landmarks.
2. Add accessible labels to a registration form.
3. Write suitable alt text for an instructional diagram.
4. Navigate a website using only Tab, Shift+Tab, Enter and Space.

Revision Quiz

1. Why should semantic HTML be preferred when appropriate?
2. When is alt="" appropriate?
3. Why is placeholder text not a full replacement for a label?
4. Why should keyboard focus be visible?
5. Should errors be communicated by color alone?
6. Can an automated checker find every accessibility problem?

Answer Key and Explanations

1. It communicates structure and purpose — Browsers and assistive technologies understand semantic elements.
2. For decorative images — It prevents unnecessary announcements for images that add no information.
3. It may disappear and does not reliably replace a persistent label — A label keeps the field's purpose clear.
4. To show the current keyboard position — Users need to know which control will receive an action.
5. No. Use additional text or other clear indicators.
6. No. Automated testing must be supplemented with manual testing.