Comment 1 by bgaraventa on 2014-02-10 19:08
I agree, it would be very helpful to provide feedback that differentiates DT vs DD elements, since currently there is no way to determine which is which other than by guessing based on the content. Often I've had to use ARIA to force this association to be more obvious, but this really shouldn't be necessary.

Comment 2 by jmuheim on 2014-10-07 13:59
I agree.

This does sound like a potential candidate for Project Webfix. Thoughts? @feerrenrut

Firstly, I can still reproduce this by navigating to the definition list displayed in the description of this issue while using NVDA Version: master-14328,c6379eb3

The webfix project is not attempting to fix every issue that occurs when using the web. Rather, it is intended to try to fix a select group of particularly troublesome issues. I don't think this issue fits into that category. While the behaviour here could be improved, and some of the semantics of the definition list are lost, my guess is that definition lists are not frequently encountered by users and the lost semantics can generally be picked up based on the context of the definition list.

Would love to see this addressed. I was contemplating switching our template over from using uls to dls but it's not going to happen if the screen reader support is lacking. It's a lot of overhead to expect people to mark things up with ARIA vs. just having it work as intended.

This doesn't mean you can't use them, it just means the semantics aren't quite correct. I'd advise switching to a DL still, because other screen readers will benefit possibly, and your sighted audience will for sure.

on complex websites where huge databases are displayed such as worldbank or EIU statistics there are such definitions lists. I can also see such lists often in corporate environment on sharepoint solutions. I don't know how hard this is to implement but I think having such a feature in document formating settings would help in boosting efficiency.

Just want to remind folks that DL is not a simple key-value affair.

• A term can have multiple definitions. (e.g. NVDA is a stock code and a screen reader.)
• Multiple terms can have the same definition. (e.g. synonyms, aliases).

The number of child elements of a DL may therefore be more than double the number of actual 'entries'.

And I fully agree that NVDA should not treat DT and DD like LI elements, as it does today. Their distinct semantics are important.

Side note: ARIA doesn't yet have role parity with all of these either.

Is it just technical issues that block this ticket or are there any other reasons not to announce DLs properly?

Is there a status update on this bug?

It would be great if NVDA could implement description lists as JAWS and VoiceOver have.

My team is also blocked on this right now. Are there any plans to address this in the near future so we can determine how to proceed?

Currently no plans to look at this. I have however updated the issue description to make it more readable. This might make it a little easier for some or all of this to get looked at.

Comment 1 by bgaraventa on 2014-02-10 19:08 I agree, it would be very helpful to provide feedback that differentiates DT vs DD elements, since currently there is no way to determine which is which other than by guessing based on the content. Often I've had to use ARIA to force this association to be more obvious, but this really shouldn't be necessary.

I'm quite curious, which ARIA attribute did you use to fix this issue?

Could you share an example?

Just bumping this as there was a query about it from @mausmalone on Twitter overnight.

Link to the draft for ARIA 1.3 which is due to introduce explicit roles to achieve parity with HTML's DL/DT/DD

https://w3c.github.io/aria/#associationlist

Note: There is some dissent about the lengthy nomenclature.

Does anyone know if this issue was ever propperly fixed as I'm using NVDA and all it says is "list with N items" when entering the list and there is no indication of even the individual

As far as I can see, a list entry can have both multiple DT and multiple DD elements.
But whenever a DT follows after a DD or a DL element, a new entry begins.

Incidentally, this not only occurs on the web, but also with many PDF documents.

Just want to remind folks that DL is not a simple key-value affair.

• A term can have multiple definitions. (e.g. NVDA is a stock code and a screen reader.)
• Multiple terms can have the same definition. (e.g. synonyms, aliases).

Sadly, ARIA themselves seem to have failed to get that memo, defining (per the link @brennanyoung posted) <dt> and <dd> as associationlistitemkey and associationlistitemvalue respectively. 🙄

DIV children of DL

From the HTML spec, an additional complication is that the children of <dl> elements are explicitly permitted to be <div>s containing <dt> and <dd>, for grouping/styling purposes. They give this example of a prototypical <dl>:

<dl>
 <div>
  <dt> Last modified time </dt>
  <dd> 2004-12-23T23:33Z </dd>
 </div>
 <div>
  <dt> Recommended update interval </dt>
  <dd> 60s </dd>
 </div>
 <div>
  <dt> Authors </dt>
  <dt> Editors </dt>
  <dd> Robert Rothman </dd>
  <dd> Daniel Jackson </dd>
 </div>
</dl>

As a child of <dl>, what the <div> can contain is restricted to only <dt> and <dd> elements. The <dl> contents is an either/or — it either contains a mix of <dt> and <dd> direct children, or "one or more <div> elements", which would themselves contain the expected <dt>s and <dd>s.

Nested DLs

While the HTML spec doesn't explicitly address nested <dl>s, the <dd> element is defined as a Flow content container, which includes most markup (including <dl>) — basically, anything you can put in a normal <div>, you can technically also put in a <dd>.

<dt>s can contain "Flow content, but with no header, footer, sectioning content, or heading content descendants." So, only slightly more restrictive. And it doesn't rule out <dl>, which is flow content but not sectioning/header. So, technically you could even put a <dl> inside a <dt>. ...Please, nobody ever do this.

<dl>s are not supported children of <dl> — only <div>, <dt>, and <dd> — so <dl>s inside <dl>s have to be nested as children of either the <dt> or <dd> child/grandchild, not directly.

IMHO multiple DT or DD elements nested within a DIV or not could be treated as an LI within a virtual UL.

<dl>
 <dt>Authors</dt>
 <dd>John</dd>
 <dd> Luke</dd>
 <dt lang="en-US"> <dfn>color</dfn> </dt>
 <dt lang="en-GB"> <dfn>colour</dfn> </dt>
 <dd> A sensation which (in humans) derives from the ability of
 the fine structure of the eye to distinguish three differently
 filtered analyses of a view. </dd>
</dl>

becomes

<dl>
 <dt>Authors</dt>
 <dd>
  <ul>
    <li>John</li>
   <li>Luke</li>
 </ul>
 <dt>
  <ul>
   <li lang="en-US"> <dfn>color</dfn> </li>
   <li lang="en-GB"> <dfn>colour</dfn> <lit>
 </dt>
 <dd> A sensation which (in humans) derives from the ability of
 the fine structure of the eye to distinguish three differently
 filtered analyses of a view. </dd>
</dl>

Now the DL is a key-value pair.

I see that there is a semantic point for having multiple DT elements, but I guess that it could be sufficient to slump them all together into a single virtual DT without the virtual nested list I described above.

@masi

IMHO multiple DT or DD elements nested within a DIV or not could be treated as an LI within a virtual UL.

I largely agree, but the sake of information fidelity it might make more sense to view them as items of an ordered list. As the HTML spec cautions, "The order of the list of groups, and of the names and values within each group, may be significant."

They also present this example:

The following example shows the dl element used to give a set of instructions. The order of the instructions here is important (in the other examples, the order of the blocks was not important).

<p>Determine the victory points as follows (use the
first matching case):</p>
<dl>
 <dt> If you have exactly five gold coins </dt>
 <dd> You get five victory points </dd>
 <dt> If you have one or more gold coins, and you have one or more silver coins </dt>
 <dd> You get two victory points </dd>
 <dt> If you have one or more silver coins </dt>
 <dd> You get one victory point </dd>
 <dt> Otherwise </dt>
 <dd> You get no victory points </dd>
</dl>

The intent, it seems, is to support a <dl> being used semantically as an "unnumbered ordered list".

@ferdnyc I shortly thought about proposing an OL, but didn't think the ordering important. But you (and the authors of the spec) are right, the order could be important.

May I suggest to split this problem into two issues:

1. Single level definition list - I see they are now quite wide spread (single level, no nesting) and NVDA announcing a list, not communicating "Key > Value" semantics is sub-optimal or even dangerous.
2. Multilevel definition lists - I understand the implementation complexity and lack of proper definitions for it.

In this way we can cover most (anecdotally) issues and had the multilevel implementation open until more is known.

Just tested an example with:

<dl>
  <dt>Student</dt>
  <dd>Judy</dd>
  <dt>Teacher</dt>
  <dd>Melissa</dd>
</dl>

And it's announced as "list with 4 items" not communicating the term > definition semantics at all (as I would expect it to do).

Sometimes term definition hierarchy is probably logical to users, but sometimes it is crucial for the understanding and lack of it may be a huge problem...

@BogdanCerovac

Just tested an example with:

<dl>
  <dt>Student</dt>
  <dd>Judy</dd>
  <dt>Teacher</dt>
  <dd>Melissa</dd>
</dl>

And it's announced as "list with 4 items" not communicating the term > definition semantics at all (as I would expect it to do).

Agreed, the ideal situation (in my view) would have it announced as a "description list with two entries" or "...two items".

Ditto this one, with the structure of the first entry being read out only when it's visited.

<dl>
  <dt>Students</dt>
  <dd>Judy</dd>
  <dd>Robin</dd>
  <dt>Teacher</dt>
  <dd>Melissa</dd>
</dl>

Whether this should be announced as having two or three entries/items, I don't know:

<dl>
  <dt>Student</dt>
  <dd>Judy</dd>
  <dt>Staff</dt>
  <dt>Teacher</dt>
  <dd>Melissa</dd>
</dl>

...though I do feel it's a question worth answering definitively, in order to implement correct behavior.

I'd love to see @nvaccess address this. Other screen readers handle it (it's been a while since I last tested this). For a dl with two dt and one dd for the first dt, two dd for the second, I'd expect to hear there is a list with two terms, then when I get to the first dt I'd expect to hear it associated with one item; for the second term, a list with two items.

Should I work with the W3C HTML or AGWG to clarify expected behavior, or is this left for AT to decide, or browsers?