Accessible HTML: semantics, keyboard navigation, and visible focus

Updated: November 6, 2026.

HTML tells browsers and assistive technologies what is on a page and how to interact with it. First, choose an element with the right behavior. Then provide clear names, visible focus, and a layout that adapts reliably.

Actions determine whether to use a button or a link

A link with an href leads to a resource or a location within a document. A button performs an action: opening a dialog, changing a state, or submitting a form. Styling does not change that purpose. A link can look like a large button and still be a link.

<!-- Link to a section of this article -->
<a href="#focus">Go to the focus check</a>

<!-- Action that does not submit the form -->
<button type="button">Open filters</button>

<!-- Form submission -->
<button type="submit">Send request</button>

A div with a click handler does not automatically have a button role, a place in the Tab sequence, or the expected keyboard activation. Adding role="button" is not enough: you still have to implement the behavior. A native button removes a substantial amount of that work.

Semantics help people find their way

Use main for the primary content, nav for a navigation region, and headings for the document structure. Do not turn every group of links into its own navigation landmark. When there are several regions, give them distinct names such as “Main navigation” and “Article sections.”

A nav element has an implicit navigation role, so <nav role="navigation"> is usually redundant. Giving a div the same role does not make all HTML elements interchangeable: native semantics are easier to maintain and depend less on manual additions.

ARIA supplements an interface; it does not fix it automatically

A button's visible text usually already supplies its accessible name. An icon-only button needs a name; a field is better served by an associated label. Do not replace a clear visible label with an entirely different aria-label: people using voice control may struggle to address the element by the words on the screen.

aria-expanded communicates whether something is expanded and must match its actual state. aria-hidden="true" removes content from the accessibility tree, but does not automatically make it visually hidden or remove it from the keyboard sequence. Do not put it on a focusable control or one of its ancestors.

Focus must be visible and predictable

Removing outline “because it does not fit the design” is a poor starting point. First, design a clearly distinguishable focus indicator, then test it against every background. Box-shadow is not a universal substitute: it may disappear in forced colors mode. Keep a functioning outline.

/* Example for a verified light surface */
.action:focus-visible {
  outline: 3px solid #1239a6;
  outline-offset: 3px;
}
@media (forced-colors: active) {
  .action:focus-visible {
    outline-color: Highlight;
  }
}

:focus-visible does not mean “only Tab”. Browsers use heuristics to decide when visible focus is needed; for example, a text field may retain it after a click. Hover does not replace focus: the states serve different purposes.

Check sticky headers, cookie banners, and floating panels. WCAG 2.4.11 AA requires that author-created content does not entirely hide the focused component. A more usable design target is to keep the whole element and its indicator visible.

Tab is only part of navigation

Complete the main tasks using a keyboard: Tab and Shift+Tab move focus, Enter activates links and buttons, and Space activates buttons; composite components need the keys appropriate to their pattern. Do not make Tab visit every list item if the pattern expects arrow-key navigation.

A screen reader is not the same thing as a keyboard. It can navigate headings, landmarks, and ordinary text; on a phone, people use gestures. Keyboard testing and screen reader testing are separate parts of the work. Pressing Tab ten times successfully does not establish accessibility for a blind person.

Magnification: 150% is not enough

For 1.4.4, text must be resizable up to 200% without loss of content or functionality, subject to the criterion's exceptions. Separately, 1.4.10 checks reflow at a width equivalent to 320 CSS px for vertically scrolling content. A common method is 400% zoom from an initial viewport width of 1280 CSS px. These are two different checks.

Lines of text should not require constant movement in two directions. Exceptions exist for content that needs a two-dimensional structure, such as certain tables and maps. They do not justify horizontal scrolling across the entire page because a button is too wide.

Also increase line height to 1.5 times the font size, spacing after paragraphs to 2 times, letter spacing to 0.12 times, and word spacing to 0.16 times. The check is for no loss of content when users make these adjustments, not a requirement to make these values everyone's defaults.

Alt text depends on an image's purpose

Informative images need their meaning conveyed; decorative images need an empty alt="". An icon inside an already labeled button usually should not repeat the name. A short alt is insufficient for a complex chart: provide an explanation of the findings and accessible data alongside it.

The practical outcome of good semantics is that people understand where they are, what they can do, and what will change after an action. Verify that through a task, not by counting newly added attributes.

Sources and the status of standards checked on November 5, 2026.

Apply these practices with an AI agent

Based on this research, we created open skills for Codex and Claude Code to help analyze and improve websites and applications. Accessible UI guides checks of semantics, keyboard interaction, focus, forms, and contrast; Adaptive Interfaces helps adapt layouts to window sizes, text scaling, the keyboard, and foldable devices. The agent examines the actual project, proposes evidence-based improvements, and verifies the agreed changes. These skills do not replace testing with users and assistive technologies.

The practical guidance from this series is collected in the Accessible UI skill on GitHub: semantics, keyboard interaction, focus, forms, contrast, and verification. The instructions are in English. See the installation instructions and invocation examples in the first article.