When Semantic HTML Goes Wrong: The Definition List Disaster

I've been staring at this WCAG audit report for the past hour, and honestly, it's both fascinating and deeply frustrating. Here's a perfect example of how good intentions in HTML can go spectacularly wrong when developers don't understand the semantic meaning behind their markup choices.

The page in question fails WCAG 1.3.1 (Info and Relationships) (opens in new window) because someone decided that definition lists (<dl>) were the perfect solution for... well, everything that looks like a list of paired information. Chat conversations, product specifications, feature lists — you name it, they threw it in a <dl> and called it accessible.

This is exactly the kind of implementation crisis I keep seeing: developers who know enough about accessibility to be dangerous, but not enough to understand why semantic HTML matters beyond just "making it work."

The Chat Conversation Catastrophe

The most egregious example shows someone marking up a customer service chat like this:

<dl>
  <dt>User:</dt>
  <dd>Hi, how can I help you?</dd>
  <dt>Customer:</dt>
  <dd>I have a question about my order.</dd>
</dl>

When a screen reader encounters this, it announces each exchange as a term and its definition. Imagine listening to: "User, definition: Hi, how can I help you? Customer, definition: I have a question about my order." That's not just confusing — it's actively misleading about the content structure.

A conversation isn't a glossary. It's a temporal sequence of exchanges between people. The proper markup here would be a simple list with clear speaker identification, or better yet, a structured approach using <article> elements with proper headings and attribution.

The Product Specs Problem

The second failure hits closer to home for e-commerce developers:

<dl>
  <dt>SKU:</dt>
  <dd>12345-67</dd>
  <dt>Color:</dt>
  <dd>Blue</dd>
  <dt>Price:</dt>
  <dd>$49.99</dd>
</dl>

I get why this feels right. It looks like term-definition pairs, and definition lists are for term-definition pairs, right? Not quite. The semantic meaning of a definition list is specifically about explaining what terms mean, not just any key-value relationship.

Product specifications are data, not definitions. A SKU isn't being defined as "12345-67" — that's its value. Semantic HTML should reflect the actual meaning and relationships in your content, not just its visual appearance.

For product specs, you want either a proper data table (if you have multiple products) or a description list using <div> elements with appropriate ARIA labels. Even a simple unordered list with strong emphasis on the labels works better than misusing definition list semantics.

When Definition Lists Actually Work

The audit does show one correct usage:

<dl>
  <dt>Accessibility</dt>
  <dd>The quality of being accessible; able to be easily reached, entered, used, understood, or appreciated.</dd>
  <dd>In web design, the practice of making websites usable by everyone.</dd>
</dl>

This is perfect! "Accessibility" is a term that has multiple related definitions, and each <dd> provides a different aspect of what the term means. Screen readers handle this beautifully, announcing the term once and then presenting each definition in sequence.

The Bigger Picture: Why Semantics Matter

Here's what really gets me about this case: it represents a fundamental misunderstanding of how assistive technology works. When we use semantic HTML correctly, we're not just following arbitrary rules — we're providing a roadmap for screen readers, voice navigation software, and other assistive technologies to understand and present our content effectively.

The organizational maturity research shows that teams often get stuck at this level: they know they should use semantic HTML, but they haven't developed the deeper understanding of why specific elements exist and when to use them.

The Navigation Problems

Beyond the definition list issues, this page has basic structural problems that compound the accessibility failures. No <nav> landmark means screen reader users can't quickly jump to navigation. No <header> or banner landmark removes another crucial navigation aid.

These aren't just technical violations — they're barriers to efficient navigation. A screen reader user landing on this page has no quick way to orient themselves or find the main navigation. They're forced to tab through everything or use heading navigation (which only works if headings are properly structured).

The Developer's Dilemma

I've been thinking a lot about why these mistakes happen so consistently. Part of it is that HTML looks deceptively simple. A <dl> element seems straightforward until you realize that its semantic meaning is quite specific. Part of it is that visual design often drives markup decisions instead of content meaning.

But there's also an operational capacity issue here. Many development teams don't have accessibility expertise embedded in their workflow. They're trying to retrofit accessibility onto existing patterns without understanding the underlying principles.

Fixing the Fundamentals

For the chat conversation, use a simple list structure:

<ul class="chat-conversation">
  <li><strong>User:</strong> Hi, how can I help you?</li>
  <li><strong>Customer:</strong> I have a question about my order.</li>
</ul>

For product specifications, consider a table if you have multiple products, or a structured div approach:

<div class="product-specs">
  <div class="spec-item">
    <span class="spec-label">SKU:</span>
    <span class="spec-value">12345-67</span>
  </div>
</div>

And always include proper landmarks:

<header>
  <nav aria-label="Main navigation">
    <!-- navigation items -->
  </nav>
</header>
<main>
  <!-- main content -->
</main>

Moving Beyond Surface-Level Compliance

This case illustrates why automated accessibility testing has limitations. An automated tool might miss the semantic misuse of definition lists because the HTML is technically valid. It takes human understanding of content meaning and user experience to catch these problems.

The real solution isn't just fixing these specific markup issues — it's building teams that understand semantic HTML as a communication tool, not just a structural necessity. When developers truly grasp that their markup choices directly impact how disabled users experience their content, these kinds of mistakes become much less common.

Semantic HTML isn't about following rules for the sake of compliance. It's about creating a foundation that assistive technology can build on to provide equivalent experiences for disabled users. When we get that right, accessibility stops being something we retrofit and becomes something we build in from the start.