Focus & Keyboard Navigation

Web Components & Accessibility

Focus & Keyboard Navigation belong to usable component design.

Keyboard support makes interactive JavaScript usable without a mouse.

A component should hide repetition without hiding meaning. Start with semantic HTML, then add the browser feature that solves the real problem.

The professional version is not only that the component works. It must remain accessible, testable, maintainable and understandable in production.

Core API

focus() and keyboard events

Meaning first

Use the right HTML before adding custom behavior.

User input

Keyboard, focus and assistive technology need deliberate support.

Production habit

Clean up listeners and keep component boundaries clear.

Examples

Good component code keeps meaning visible.

Use the browser feature with semantic intent

button.addEventListener("keydown", event => {
  if (event.key === "Enter" || event.key === " ") {
    button.click();
  }
});

Hide meaning behind JavaScript

div.addEventListener("click", openPanel);
// A div is not keyboard-accessible by default.

Syntax reference

Named examples you can scan, copy, change and understand.

This is the practical reference part of the lesson. Each example has one job, a stable anchor and a small assignment, so the page works both as a course and as a developer reference when you need the syntax later.

Basic pattern

A compact example of the feature in context.

button.addEventListener("keydown", event => {
  if (event.key === "Enter" || event.key === " ") {
    button.click();
  }
});

What to notice

Read the variable names before the syntax.
Change one value and predict the result before running it.

Try it yourself

Rename one value and update every place where it is used.
Add one console.log line that proves what the example returns.

Weak pattern

A common shortcut that creates maintenance or accessibility problems.

div.addEventListener("click", openPanel);
// A div is not keyboard-accessible by default.

What to notice

Read the variable names before the syntax.
Change one value and predict the result before running it.

Try it yourself

Rename one value and update every place where it is used.
Add one console.log line that proves what the example returns.

Feature check

Check support before depending on advanced browser features.

if ("customElements" in window) {
  // Register or enhance the component.
}

What to notice

Read the variable names before the syntax.
Change one value and predict the result before running it.

Try it yourself

Rename one value and update every place where it is used.
Add one console.log line that proves what the example returns.

Accessible update

Dynamic UI should communicate state changes clearly.

const status = document.querySelector("[aria-live]");
status.textContent = "Interface updated.";

What to notice

Read the variable names before the syntax.
Change one value and predict the result before running it.

Try it yourself

Rename one value and update every place where it is used.
Add one console.log line that proves what the example returns.

Code patterns

Reusable examples for quick reference.

Use these examples as a quick reference when building reusable browser UI.

Basic pattern

A compact example of the feature in context.

button.addEventListener("keydown", event => {
  if (event.key === "Enter" || event.key === " ") {
    button.click();
  }
});

Weak pattern

A common shortcut that creates maintenance or accessibility problems.

div.addEventListener("click", openPanel);
// A div is not keyboard-accessible by default.

Feature check

Check support before depending on advanced browser features.

if ("customElements" in window) {
  // Register or enhance the component.
}

Accessible update

Dynamic UI should communicate state changes clearly.

const status = document.querySelector("[aria-live]");
status.textContent = "Interface updated.";

Rules that matter

Accessible components need rules, not luck.

Web Components can be powerful, but the browser does not automatically make custom UI accessible.

Start from working HTML

The page should have meaning before JavaScript upgrades it.

Use native controls when possible

Buttons, links and form controls already handle many accessibility details.

Manage focus deliberately

Dynamic interfaces should not trap or lose keyboard users.

Clean up side effects

Remove listeners and timers when components leave the page.

Keep styling boundaries clear

Shadow DOM can help, but it should not make the UI impossible to theme.

Test without a mouse

Keyboard testing catches real usability problems quickly.

Production thinking

Ship components that survive reuse.

Why does this matter?

Component code often gets reused everywhere. If the foundation is inaccessible, the problem spreads everywhere too.

Accessibility

This chapter is accessibility-heavy on purpose: reusable UI has to work for keyboard users, screen readers and dynamic content updates.

Production note

Production components need documented APIs, predictable lifecycle behavior, cleanup and browser-support decisions.

SEO note

Important content should not be locked inside client-only behavior that search engines or no-JavaScript users cannot reach.

Live code lab

Change the HTML, CSS or JavaScript and run the result.

The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.

Mini assignment

Try this now.

Change the visible text and run the example again.
Explain which part is plain HTML and which part is JavaScript enhancement.
Test the example using only the keyboard where possible.

Practice assignment

Do this before moving to the next topic.

Write the simplest semantic HTML version first.
Add the JavaScript behavior in a small, named block.
Add one accessibility check before calling the component finished.

HTML + JavaScript CSS

Live preview

Self-check

Before you continue, prove that you understand Focus & Keyboard Navigation.

Advanced

Answer these before moving to the next component lesson.

What problem does Focus & Keyboard Navigation solve?
Which part could fail if JavaScript does not run?
How would a keyboard user interact with this pattern?
What cleanup or lifecycle concern exists in production?
Why is semantic HTML still important here?

Senior audit upgrade

Extra production context for Focus & Keyboard Navigation.

Optional component path

Web Components are valuable, but they are not required for every website. Learn them after DOM, events, forms and accessibility basics are stable.