Meaning before appearance

Web browsers construct two parallel representations of a web page:

1. The Document Object Model (DOM): The programmatic hierarchy of nodes used for CSS styling and JavaScript interaction.
2. The Accessibility Tree: A specialized API tree generated from semantic HTML elements that exposes Name, Role, State, and Value to assistive technologies like screen readers, speech input engines, and braille displays.

When you style a <div> or <span> to visually look like a button with rounded corners and gradients, zero semantic metadata is conveyed to the accessibility tree. To a blind screen reader user, it is invisible as an actionable control—it is announced merely as generic 'text'.

The most widespread accessibility defect on the modern web is confusing a Button with a Link:

• Use a <button> when: The user action performs an operation, triggers a state change, submits a form, opens a modal, or toggles a menu on the current page.
• Use an <a> (Anchor) with href when: The user action navigates to a new URL, a different web page, or an anchor target on the same page.

Why this distinction matters:

• Sighted users perceive both as clickable items, but screen readers announce 'link' vs 'button', setting critical cognitive expectations.
• Native <button> elements trigger on both Space and Enter keys.
• Native <a> links trigger on the Enter key only.
• Using <div onclick="..."> breaks keyboard navigation entirely unless you manually write 50 lines of polyfill code for tabindex, keyboard listeners, and ARIA roles.

Sighted users scan a webpage by visually skimming large, bold typography.

Screen reader users scan a webpage by navigating heading outlines (e.g., pressing the H key in NVDA or JAWS, or using the rotor in VoiceOver to pull up a table of contents).

The Strict Heading Rules:

1. Exactly one <h1> per page: Represents the overall topic of the document (e.g., 'Order History' or 'Account Settings').
2. Strict logical nesting without skipping:
   • <h1> -> <h2> -> <h3> -> <h4>.
   • Fatal Defect: Jumping from <h2> directly to <h4> because you wanted smaller font styling. (Use CSS classes to adjust font size, never heading levels!).
3. Never use headings for styling alone: A pull-quote or promotional banner should not be marked as an <h3> just because its font size matches your aesthetic preference.

HTML5 introduced native Landmark Elements that establish structural signposts across the document:

• <header>: The banner containing site logo, global identity, and utility shortcuts.
• <nav>: Major navigation blocks (primary header menu, pagination, breadcrumbs).
• <main>: The primary, unique content of the document (there must be only one visible <main> per page).
• <aside>: Complementary content tangentially related to the main content (related articles, author bio, sidebars).
• <footer>: Colophon, copyright notices, terms of service, and secondary links.
• <search>: Structural container for search forms.

A rampant web design antipattern is omitting <label> elements and using the placeholder attribute instead to create a 'clean, minimal' form input.

Why Placeholders Fail Accessibility and Usability:

1. They Disappear on Focus: The moment a user types one letter, the placeholder vanishes. Users with cognitive disabilities, memory impairments, or distractions forget what field they are editing.
2. Poor [Color Contrast](/glossary/contrast-ratio): Most default browser placeholder text fails the WCAG 4.5:1 color contrast ratio requirement.
3. Inconsistent Screen Reader Support: Many screen readers do not announce placeholders as accessible names.

The Bulletproof Standard: Always use an explicit <label for="email-input">Email Address</label> bound programmatically to <input id="email-input">. Clicking the label also expands the click target by focusing the input!

Writing alt text for images is not about mechanically describing every pixel. Follow W3C's Alt Text Decision Tree:

1. Informative Images: Does the image convey information, data, or context not present in the surrounding text? Write concise, descriptive text: <img src="chart.png" alt="Line graph showing mobile signups increasing 42% in Q3">.
2. Decorative Images: Is the image pure visual eye-candy, background decoration, or redundant with adjacent text? Provide an empty alt attribute: <img src="decorative-flower.svg" alt="">.
   • Notice: Omitting the alt attribute entirely is an error (the screen reader will read the raw file URL like 'image-slash-assets-slash-flower-dot-png'). An empty alt="" instructs the screen reader to silently ignore it.
3. Functional Images (Icons): Is the image inside a button or link? The alt text must describe the action, not the picture: <button><img src="trash.svg" alt="Delete project"></button>.

Why do accessibility guidelines mandate that navigation menus, search result feeds, and bulleted features use semantic list tags (<ul>, <ol>, <li>) rather than stacks of <div> tags?

The Assistive Technology Experience: When a screen reader encounters a <ul> containing 6 <li> elements, it announces:

'List with 6 items. Item 1 of 6: Overview... Item 2 of 6: Analytics...'

This critical metadata tells the user:

• Exactly how many choices exist in this collection.
• Where they currently are within the group.
• How to skip past the entire list with a single keystroke if they aren't interested in this menu.

The W3C Web Accessibility Initiative published the famous First Rule of ARIA:

'If you can use a native HTML element or attribute with the semantics and behavior you already require, then do so instead of re-purposing an element and adding an ARIA role, state or property.'

Consider building an expandable accordion:

• The ARIA Hack: A <div> with role="button", tabindex="0", aria-expanded="false", custom JavaScript keydown listeners for Space and Enter, and custom focus management.
• The Native HTML Solution: <details> and <summary>. Zero JavaScript required, 100% accessible out-of-the-box on every browser, keyboard, and screen reader.

ARIA is an emergency bridge for custom widgets that HTML cannot express; it is not a replacement for good HTML.

Tables are intended for relational tabular data, never for page layout.

When a screen reader traverses a well-structured data table, it continuously announces the column and row headers corresponding to the current cell:

<table>
  <caption>Employee Quarterly Sales Performance (2026)</caption>
  <thead>
    <tr>
      <th scope="col">Employee</th>
      <th scope="col">Region</th>
      <th scope="col">Revenue</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Elena Rostova</th>
      <td>Northern Europe</td>
      <td>$142,000</td>
    </tr>
  </tbody>
</table>

Key Elements:

• <caption>: The title of the table announced upon entry.
• <th scope="col"> and <th scope="row">: Explicitly ties data cells to their parent headers.

Put all semantic HTML principles into practice:

You are auditing a checkout page written by an intern. You find the following markup:

<div class="checkout-box">
  <div class="heading-text">Complete Your Order</div>
  <div class="cart-list">
    <div class="item">Wireless Mouse - $29</div>
    <div class="item">USB-C Hub - $49</div>
  </div>
  <div class="input-box">
    <input type="text" placeholder="Enter Promo Code">
  </div>
  <div class="submit-btn" onclick="submitOrder()">Pay Now</div>
</div>

A screen reader user navigating this component hears: 'Complete Your Order, Wireless Mouse - $29, USB-C Hub - $49, edit text, Pay Now text'. They cannot tell there is a heading, cannot tell there are 2 items in a list, have no persistent label on the promo code, and the 'Pay Now' button cannot be reached or clicked via keyboard!