> <dl aria-label="Ability Scores">

This is incorrect:

1. <dl> has no corresponding (viz. implicit) role, but can be given the role group, list, none or presentation <https://w3c.github.io/html-aria/#el-dl>.

2. You’re only allowed to define aria-label on elements that have a compatible role, implicit or explicit <https://w3c.github.io/html-aria/#docconformance-naming>.

3. aria-label is allowed on all but a handful of roles <https://www.w3.org/TR/wai-aria-1.2/#aria-label>, which in this case knocks out presentation and none, leaving group and list.

4. group doesn’t feel right, list feels acceptable.

In summary: either ditch the aria-label, or add role="list" (meaning also role="listitem" on children).

—⁂—

One thing the article misses is that you can have multiple <dt> in a row too, not just <dd>. The spec has a good example: https://html.spec.whatwg.org/multipage/grouping-content.html...

They’re not name–value pairs, they’re name–value groups.

The world's first website makes heavy use of <dl>s.

https://info.cern.ch/hypertext/WWW/TheProject.html

https://info.cern.ch/ (A landing page of sorts to give context and orientation about the actual first website.)

> Prior to HTML5, this was called a definition list. This is because the <dl> was originally only intended to represent glossaries of terms and their definitions.

TIL I’ve been naming it wrong for a decade.

Here's a useful note on how well screen readers support DL: https://adrianroselli.com/2025/01/updated-brief-note-on-desc...

The final example of the DnD statt sheet makes me think whether it's legal to nest <dl>s?

I.e. can we do

    <dl>
      <dt>Actions</dt>
      <dd><dl>...</dl></dd>
    </dl>

I love DL. I think tables, at least in the past, were misused as DLs even more in the past and the inconvenience of the table markup is even worse than a bunch of divs.

I'm curious if the spec actually says you can only wrap it with a div because I like to do semantic html and name my elements specific to my domain.

I've used this a good amount of times, when I coded in front end projects. The first time gave me that satisfying feeling of using the right tool for the job, like completing a puzzle of HTML semantics. I remember JAWS not announcing it correctly in 2018, not sure if it's better now.

> Admittedly, however, support for the <dl> element is not yet universal.

Wait what? <DL> has been in HTML since.. the first draft in 1993!

I like DL's but they can be challenging to style. This article is using a lot of fixed pixel widths which would break on really small screens or larger data.

I was a bit surprised to see nested <div>s given as some sort of precursor pattern, when <dl> was part of HTML before 2.0 back in the days of table layout.

The <dl> tag seems to cover a subset of a broad semantic space, but doesn’t easily extend beyond adding another <dd>.

I dunno, I guess I’m a caveman. If it looks right and works (including accessibility) then I figure I’m pursuing something that doesn’t matter a lot.

Hoped to see CSS for the alternative, where <div> is not nested inside the <dl>. Too used to thinking of div as "layout containers."

The GOV.UK Design System summary list component is a description list https://design-system.service.gov.uk/components/summary-list...

And... it also uses the wrapper div for styling

What about multiple '&lt;dt&gt;' for one or more '&lt;dd&gt;'?

Good title

We've always used this in our ebooks for abbreviation and glossary lists. The problem I've always had is that you need to use a bit of css to make two lined-up columns. I've done it with floats. Now, some ebook readers will support grid and flex-box, which give better results, but the Kindle still does not. Kindle is sort of the IE6 of the ebook world.

This seems a clear enough win for things that would fit into a simple python dictionary.

Why is it preferred over <table> for laying out columns via a the character attributes at the bottom of TFA?

it's on archive html5 .flac 16-bit 44.1kHz no <dl> flag.

blog looks beautiful. I really wish I had this kind of talent for frontend.