HTML Accessibility Basics: Landmarks, Keyboard and Focus

What you will learn

Accessibility (often abbreviated a11y — “a,” 11 letters, “y”) means building pages that work for people using a screen reader, navigating entirely by keyboard, dealing with low vision, or living with a motor condition that makes a mouse difficult. This isn’t a separate skill bolted onto HTML — you’ve actually been learning it, piece by piece, since your very first lesson. This lesson pulls those pieces together and adds the parts you haven’t covered yet: landmarks, keyboard navigation, focus styles, and skip links.

Why this matters, concretely

It’s easy to treat accessibility as an abstract checkbox. It helps to think about real, specific situations instead:

• A screen reader user cannot see your page at all — they navigate by listening to it read aloud, jumping between headings, links, and form fields using keyboard commands.
• A keyboard-only user (due to a motor condition, an RSI injury, or simply a broken trackpad) navigates entirely with Tab, Shift+Tab, Enter and Space — no mouse.
• A low-vision user may zoom their browser to 200% or use a high-contrast mode, and needs your layout and text to hold up under that.
• A visitor in bright sunlight on their phone, or with a cracked screen, benefits from the exact same good contrast and clear structure that a low-vision user needs.

The encouraging part: accessible HTML is very often just correct HTML. Most of the work is using the right element for the job, which you’ve already been practising.

What you already know (a recap, with the “why”)

Alt text on images

<img src="chart.png" alt="Bar chart showing sales doubling from January to June 2026">

Without alt, a screen reader user gets nothing where an image was — sometimes just the file name read aloud, which is often meaningless. You covered writing good alt text in the images lesson; the accessibility reason is exactly what’s described there.

Correct heading order

<h1>Article Title</h1>
<h2>Section One</h2>
<h3>A Sub-point</h3>
<h2>Section Two</h2>

Screen reader users frequently navigate by heading — pressing a key to jump straight from one heading to the next, skipping everything in between, the way a sighted reader might skim a table of contents. Skipped levels (<h2> straight to <h4>) or headings chosen for their size rather than their outline position break that navigation.

Labelled form fields

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

Without a real, connected <label>, a screen reader user tabbing into a field hears only “edit text, blank” — no idea what to type. You covered this fully in the forms lesson.

Landmarks: labelled regions of a page

This is genuinely new territory. Landmarks are the semantic structural elements you met in an earlier lesson — <header>, <nav>, <main>, <aside>, <footer> — but viewed through an accessibility lens: each one creates a named region that a screen reader user can jump straight to, the same way you might jump straight to a specific chapter of a book instead of reading page by page.

<header>
  <nav>...</nav>
</header>

<main>
  <h1>Page content starts here</h1>
  ...
</main>

<aside>...</aside>

<footer>...</footer>
</html>

A screen reader can present these as a navigable list: “Banner, Navigation, Main, Complementary, Content info” — letting a user jump directly to “Main” and skip repeated header/navigation content entirely on every single page they visit on your site. Using <div> for all of these instead removes that entire capability; the content would still be readable, but a user would have to listen through everything, every single time, with no way to skip ahead.

<main> should appear exactly once

<main>
  <!-- the one, unique content of THIS page -->
</main>

There should be exactly one <main> per page, wrapping the content that’s unique to that specific page (not the shared header, nav, or footer repeated across your whole site). This single landmark is often the very first place a screen reader user jumps to.

Labelling landmarks when you have more than one

If a page has two <nav> elements (a main menu and a footer’s link list, say), tell them apart with aria-label (you’ll cover ARIA properly in the next lesson — this is a small, safe preview):

<nav aria-label="Main navigation">...</nav>
<nav aria-label="Footer links">...</nav>

Without this, a screen reader announces both simply as “navigation,” leaving the user unsure which is which.

Keyboard navigation

Close your eyes (or genuinely try this) and navigate a page using only the Tab key (move to the next focusable element), Shift+Tab (move to the previous one), and Enter/Space to activate whatever you land on. Two things make this work well or badly:

Only truly interactive elements should be focusable

Links, buttons, and form fields are focusable by default, with no extra work from you — another reason to use <button> and <a> for genuinely clickable things, rather than making a <div> or <span> clickable with only CSS and JavaScript. A real <button> also responds to Enter and Space automatically; a <div> styled to look like a button does neither, unless you manually rebuild all of that keyboard behaviour yourself.

<!-- Right: keyboard-accessible for free -->
<button onclick="submitForm()">Submit</button>

<!-- Wrong: looks like a button, but Tab and Enter do nothing here by default -->
<div class="button-looking-thing" onclick="submitForm()">Submit</div>

Visible focus styles: never remove them

Browsers draw a visible outline around whatever element currently has keyboard focus, by default. It’s extremely common — and a serious accessibility failure — to see this in a stylesheet:

/* Don't do this */
*:focus {
  outline: none;
}

Without a visible focus indicator, a keyboard user has no way to see where they currently are on the page. If you want a custom focus style instead of the browser’s default (a reasonable design choice), replace it — never remove it outright:

/* Better: replace the default with your own, still clearly visible */
a:focus-visible,
button:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

(:focus-visible specifically targets keyboard focus rather than every mouse click too — you’ll learn this selector properly in the CSS course, but it’s the modern, correct choice here.)

Skip links

On a page with a long header and navigation menu, a keyboard user has to press Tab through every single link in that menu, on every page, just to reach the actual content. A skip link solves this: a link, positioned as the very first focusable thing on the page, that jumps straight past the repeated header content.

<a class="skip-link" href="#main-content">Skip to main content</a>

<header>
  <nav>...</nav>
</header>

<main id="main-content">
  ...
</main>

.skip-link {
  position: absolute;
  left: -9999px;
  top: 0;
}

.skip-link:focus {
  left: 8px;
  top: 8px;
}

The pattern: the link is visually hidden off-screen by default, but becomes visible the moment it receives keyboard focus (typically the very first Tab press on the page) — invisible to everyone else, instantly available to the person who actually needs it. Try it in the practice editor: press Tab once as soon as the preview loads, and watch the skip link appear.

Colour contrast

Text needs enough contrast against its background to be readable, especially for low-vision users. The Web Content Accessibility Guidelines (WCAG) set specific numeric contrast ratios — this is technically a CSS concern (colours), but it’s worth flagging here since it directly affects the HTML content you write:

• As a rule of thumb, avoid light grey text on a white background, or similarly low-contrast combinations, for anything meant to actually be read.
• Free contrast-checker tools (search “WebAIM contrast checker”) let you test a specific foreground/background colour pair against the WCAG standard before shipping a design.

A brief word on WCAG

WCAG (Web Content Accessibility Guidelines) is the official, internationally recognised standard for web accessibility, published by the W3C — the same organisation behind the HTML specification itself. It’s organised around four principles, easy to remember as POUR:

• Perceivable — content must be presentable in ways people can perceive (alt text, captions, sufficient contrast)
• Operable — interface elements must be operable (full keyboard access, enough time to read/act)
• Understandable — content and operation must be understandable (clear labels, consistent navigation)
• Robust — content must work reliably across different browsers and assistive technologies (valid, semantic HTML — which is exactly what this whole course has been teaching)

You don’t need to memorise WCAG’s detailed technical criteria as a beginner. Knowing it exists, and that everything in this lesson (and course) directly supports it, is enough for now.

A quick way to test your own page

You don’t need special hardware to start testing accessibility:

1. Unplug your mouse (or simply don’t touch it) and try using your own page with only Tab, Shift+Tab, Enter and Space.
2. Browser DevTools → Lighthouse tab (in Chrome) runs an automated accessibility audit and flags real, specific issues on your actual page.
3. Turn on your operating system’s built-in screen reader (VoiceOver on Mac, Narrator on Windows) for five minutes on your own page, just to hear what it sounds like.

Common mistakes

• Removing focus outlines with outline: none and nothing to replace them. A keyboard user loses all sense of where they are on the page.
• Making a <div> or <span> clickable instead of using a real <button> or <a>, losing keyboard focusability and Enter/Space activation for free.
• Using more than one <main> per page, or none at all.
• Two unlabelled <nav> elements, leaving a screen reader user unable to tell them apart.
• No skip link on a page with a long header/navigation, forcing every keyboard user to tab through the same repeated menu on every single page.
• Low-contrast text that fails WCAG’s minimum contrast ratio, especially light grey on white.
• Treating accessibility as a final “add-on” pass instead of a habit built into every lesson you’ve already learned — alt text, heading order, labels, and semantic elements.

Interview-style questions

What is a “landmark” in HTML accessibility, and why does it matter? A landmark is a semantic structural element (<header>, <nav>, <main>, <aside>, <footer>) that creates a named region a screen reader can list and jump directly to, letting users skip repeated content like a site’s header and navigation on every page.

Why is it a serious accessibility failure to write outline: none globally? It removes the browser’s visible focus indicator without providing any replacement, leaving keyboard-only users with no way to see which element currently has focus.

What problem does a skip link solve? It lets keyboard users jump directly to a page’s main content in one action, instead of having to tab through every link in a repeated header and navigation menu on every page.

Why is a real <button> more accessible than a styled, clickable <div>? A <button> is focusable by keyboard and responds to Enter/Space automatically; a <div> has none of this built in and would need all of that behaviour manually rebuilt with extra code.

Practice

1. Use the Practice in Editor button. Load the preview, then press Tab once immediately, and watch the skip link appear. Press it, and observe where focus lands.

2. Try navigating the practice example using only Tab and Enter — no clicking.

3. Add aria-label="Footer navigation" to a second <nav> you add inside the <footer>, so it’s distinguishable from the header’s navigation.

4. Fix this code (it has two mistakes: a clickable <div> instead of a real button, and a heading level jump):

   <h1>Dashboard</h1>
   <h3>Recent Activity</h3>
   <div onclick="logout()">Log Out</div>

Recap

• Accessibility means building pages that genuinely work for screen reader users, keyboard-only users, and people with low vision — largely by using the correct HTML element for the job.
• Alt text, correct heading order, and connected form labels are the accessibility foundations you’ve already been practising.
• Landmark elements (<header>, <nav>, <main>, <aside>, <footer>) let screen readers jump directly between named page regions; label multiples of the same landmark with aria-label.
• Real <button> and <a> elements are keyboard-accessible for free; styled <div>s are not.
• Never remove focus outlines without replacing them, and add a skip link on pages with a long header/navigation.
• WCAG (POUR: Perceivable, Operable, Understandable, Robust) is the official standard behind all of this.