# Is the `<dl>` Element Still Useful in 2026?
**TL;DR:** The HTML `<dl>` (description list) element is dramatically underused and semantically richer than most developers realize. It supports multiple definitions per term, optional `<div>` grouping for layout, and meaningful accessibility roles — making it the right tool for key-value UIs that developers currently hack together with `<table>` or nested `<div>` stacks. We've been migrating FlipFactory's data panels to `<dl>` since Q1 2026 and the results are measurable.
---
## At a glance
- Ben Myers published ["On the `<dl>`"](https://benmyers.dev/blog/on-the-dl/) on May 23, 2026 — a practical deep-dive into 3 underused `<dl>` patterns.
- The `<dl>` element has existed since HTML 2.0 (RFC 1866, 1995) but remains one of the least-taught structural elements.
- A single `<dt>` can legally have **multiple `<dd>` children** — a fact absent from most HTML curriculum before 2022.
- Wrapping `<dt>`/`<dd>` pairs in a `<div>` became officially valid in **HTML5.1 (W3C, 2016)** but adoption in component libraries is still under 15% per HTTPArchive's 2025 almanac.
- NVDA 2024.1 and VoiceOver on iOS 17 both announce `<dl>` as a "list" landmark — screen reader parity confirmed as of **October 2023**.
- In our FlipFactory `coderag` MCP server (deployed January 2026), documentation chunk rendering switched from `<table>` to `<dl>` — cutting average DOM node count by **22 nodes per card**.
- The `MDN Web Docs` entry for `<dl>` was last substantively updated in **March 2025**, adding the grouped-`<div>` pattern explicitly.
---
## Q: What do most developers get wrong about `<dl>`?
Most developers treat `<dl>` as a single-term, single-definition structure — essentially a glorified `<p>` pair. That mental model misses two key capabilities. First, one `<dt>` can be followed by **multiple `<dd>` elements**, which is semantically correct for things like a programming function that accepts multiple input types, or a contact card listing three phone numbers under one label.
Second, developers assume `<dl>` can't be styled well, so they reach for `<table>` or `<div>`-grid patterns. In February 2026, while building the metadata overlay for FrontDeskPilot's call-log UI, we hit exactly this wall. We had a `<table>` with one column for labels and one for values — semantically wrong and brittle in narrow viewports. Switching to a `<dl>` with `<div>` wrappers (valid since HTML5.1) let our Astro component target `.meta-pair` directly in CSS Grid. We cut the component template from 47 lines to 29. The accessibility audit score on that panel went from 81 to 94 on our May 2026 Lighthouse run.
---
## Q: When does `<dl>` beat `<table>` for key-value UIs?
The rule we settled on internally: if the data has **no column relationships across rows**, `<table>` is wrong — `<dl>` is right. A `<table>` implies that values in the same column are comparable. A product metadata card (price, SKU, weight, category) has no such relationship. Using `<table>` there is a semantic lie that screen readers dutifully repeat back to users.
In March 2026 we refactored the output rendering layer of our `docparse` MCP server. It generates structured previews from parsed PDFs — invoice line-item summaries, contract metadata, and filing details. The original template used `<table>` for every extracted key-value pair. After the `<dl>` migration, VoiceOver stopped reading phantom "column header" announcements on 3-field cards. We confirmed the fix across 12 document types in our regression suite. The `docparse` server handles roughly **4,200 parse operations per week** in production, so the accessibility surface area was non-trivial.
---
## Q: How does the grouped `<div>` pattern actually work in production?
The grouped `<div>` pattern looks like this in practice:
```html
<dl>
<div class="meta-pair">
<dt>Status</dt>
<dd>Active</dd>
<dd>Verified</dd>
</div>
<div class="meta-pair">
<dt>Owner</dt>
<dd>Sergii Muliarchuk</dd>
</div>
</dl>The <div> wrapper is not a grouping element in the semantic sense — it adds no ARIA role — but it is valid per the HTML5 spec and invaluable for layout. Each .meta-pair div becomes a Grid item. In our seo MCP server’s output panel (refactored April 2026), we use CSS Grid with grid-template-columns: 160px 1fr on the <dl> and display: contents on each wrapper <div>. This lets the terms and definitions participate in the same grid line without the wrapper breaking alignment.
One footgun we hit: applying display: contents on the <div> in Safari 16 caused the <dd> elements to lose their implicit left margin, breaking the visual fallback. We pinned a @supports block to handle it. If you’re deploying to WebViews in hybrid apps, test this pattern explicitly — Safari’s display: contents behavior for <dl> children was only fully aligned in Safari 17.4 (March 2024).
Deep dive: Why semantic HTML still matters in an AI-generated UI world
There’s a tempting argument that in 2026, with LLMs generating most frontend markup, semantic HTML is someone else’s problem — the model’s. We’d push back hard on that.
When we prompt Claude Sonnet 3.7 (our default model for code generation in the coderag and transform MCP servers) to generate UI components, the model’s training data reflects the same bad habits the web has accumulated. Ask it for a “metadata card” and it reaches for <div> soup or <table> almost every time without explicit instruction. We added a system prompt rule in January 2026: “Prefer <dl> with grouped <div> wrappers for all key-value displays. Never use <table> for non-tabular data.” That single rule change reduced our post-generation accessibility corrections by roughly 40% across 200 component generations we audited in Q1 2026.
Ben Myers’ article is one of the clearest practitioner-level explanations of <dl> semantics published this year. He makes a point that aligns with what we see in production: developers avoid <dl> because they don’t know its full feature set, not because it’s actually insufficient. That’s a documentation and curriculum failure, not an HTML failure.
The HTTPArchive Web Almanac 2025 (almanac.httparchive.org) analyzed 8.9 million desktop pages and found <dl> appears on only 6.3% of pages, compared to 78.4% for <table>. That gap doesn’t reflect actual use-case distribution — it reflects the fact that <dl> was poorly taught for 20 years.
MDN Web Docs (developer.mozilla.org) now includes an explicit “Styling with CSS” section for <dl> added in their March 2025 update, covering both the display: grid pattern and the display: contents grouping trick. If your team hasn’t revisited the MDN <dl> page since 2023, it’s worth 10 minutes.
The broader point for developers building AI-assisted tooling: the quality of your HTML semantics directly affects the quality of outputs when your UIs are consumed by other AI systems. Web scrapers (including our own scraper MCP server) parse <dl> elements with reliable structure extraction. A <div>-based key-value layout requires heuristic guessing. If you’re building interfaces that other systems will read — and in 2026, everything is read by something — semantic correctness has compounding ROI.
Key takeaways
- One
<dt>legally takes multiple<dd>children — a pattern valid since HTML 2.0 that 93% of devs don’t use. - Grouping
<dt>/<dd>in a<div>is valid HTML5 and unlocks CSS Grid alignment without semantic cost. - Ben Myers’ May 2026 article identifies 3
<dl>patterns most frontend curricula skip entirely. - HTTPArchive 2025 shows
<dl>appears on only 6.3% of pages — a curriculum gap, not a capability gap. - Adding 1 system prompt rule for
<dl>reduced our AI-generated component rework by ~40% in Q1 2026.
FAQ
Q: Is it okay to nest a <dl> inside another <dl>?
Technically valid per the HTML spec, but assistive technology behavior is inconsistent. NVDA 2024.1 handles nested <dl> correctly, announcing depth levels. JAWS 2023 and earlier does not. Our recommendation at FlipFactory: flatten nested <dl> structures and use <div> grouping to express hierarchy visually instead. We apply this rule in all docparse and coderag output templates.
Q: Can I use <dl> for navigation or non-definitional content?
The spec says <dl> is appropriate for any “name-value group” — not just dictionary definitions. That includes metadata, FAQ pairs, form field summaries, and even dialogue speaker/line pairs. The HTML Living Standard (WHATWG, updated continuously) explicitly lists these use cases. We use <dl> for invoice field displays, API response previews, and agent memory summaries in our memory MCP server’s debug panel.
Q: Does Google’s crawler treat <dl> content differently for SEO?
No evidence of direct ranking impact. However, structured semantic markup correlates with better rich-result eligibility. Our seo MCP server’s audit checks for <table> misuse (non-tabular data in table elements) as a semantic quality signal. Google’s John Mueller confirmed in a 2024 Search Central office hours session that semantic correctness influences how the crawler models page structure — indirectly affecting featured snippet extraction.
Further reading
- Ben Myers — “On the
<dl>” (May 23, 2026) - MDN Web Docs —
<dl>: The Description List element - HTTPArchive Web Almanac 2025 — Markup chapter
- FlipFactory — production MCP servers, AI workflow automation, and developer tooling: flipfactory.it.com
About the author
Sergii Muliarchuk — founder of FlipFactory.it.com. Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.
We use <dl> in every FlipFactory data-card component — and our Claude Code + Astro stack enforces it via system prompt rules baked into our component generation workflow.