Accessibility and Search Basics

July 16, 2026 ยท View on GitHub

A website is not complete merely because it loads. It should be understandable, navigable, and usable across devices and assistive technologies.

Start with Semantic HTML

Use native elements before recreating them with generic containers:

<button type="button">Open settings</button>
<nav aria-label="Primary navigation">...</nav>
<main>...</main>

Native elements provide keyboard behavior and semantics that custom implementations often miss.

Keyboard Navigation

Test without a mouse:

  1. Press Tab through interactive elements.
  2. Confirm focus is visible.
  3. Confirm focus order follows the reading order.
  4. Activate links and buttons with the keyboard.
  5. Confirm no keyboard trap prevents leaving a component.

Do not remove focus outlines without providing a clear replacement.

Color and Contrast

Do not use color as the only signal. Pair color with text, icons, or structure.

Example error message:

<p class="error" role="alert">Enter a valid email address.</p>

Test foreground and background combinations with an accessibility contrast tool. Check hover, focus, disabled, and dark-theme states separately.

Forms

Associate every input with a visible label:

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

Placeholder text is not a substitute for a label. Explain errors near the field and preserve entered data after a validation failure when safe.

Images and Media

  • Write useful alternative text for informative images.
  • Use empty alternative text for decorative images.
  • Provide captions or transcripts for meaningful audio and video.
  • Avoid autoplaying audio.
  • Do not place critical text only inside an image.

Page Metadata

Each public page should have a unique title and useful description:

<title>Installation Guide | Example Project</title>
<meta name="description" content="Install and verify the Example Project on Linux and macOS.">

Metadata helps users distinguish tabs and can help search systems understand the page. It does not guarantee ranking.

Canonical URLs

If the same content is reachable at several URLs, select one public URL and use redirects consistently. A canonical link can communicate the preferred document URL:

<link rel="canonical" href="https://example.dpdns.org/guide/">

Do not use a canonical link to hide incorrect redirects or duplicate deployment paths.

robots.txt

A basic file may declare crawl preferences:

User-agent: *
Allow: /

robots.txt is public and voluntary. It is not access control. Do not list private paths in it expecting them to become secret.

Sitemap

A small site may publish a sitemap containing canonical public URLs. Update it when pages move or are removed. The sitemap supports discovery but does not guarantee indexing.

Structured Content

Clear headings, descriptive links, real text, and stable URLs benefit both accessibility and search understanding. Avoid pages created only to repeat keywords or manipulate rankings.

Accessibility Review Lab

For the static site built earlier:

  1. Navigate the entire site using only a keyboard.
  2. Check every image's alternative text.
  3. Check heading order.
  4. Zoom the page to 200 percent.
  5. Test a narrow viewport.
  6. Disable CSS and confirm the document remains understandable.
  7. Record and fix at least three issues.

Review Questions

  1. Why is a placeholder not a label?
  2. Why is robots.txt not a security boundary?
  3. What is the difference between a redirect and a canonical hint?
  4. How does semantic HTML help without adding visible design?

Continue to Performance and Caching.