Definition lists not exposed correctly

[nvaccessAuto]

Steps to reproduce:

I'm not really sure about the correctness or utility of nested DL's. This isn't specifically mentioned in the html spec or on MDN - DL element but I have included in the example any way since many comments seem to mention it.

Example case

See below or codepen:

Test case

Term 1

Definition text for term 1

Term 2

Definition text for term 2

Term 3

Definition text for term 3

Multi definition term 4

Definition 1 for term 4

Definition 2 for term 4

DL's containing DL's

list item 1

Descriptive of nested list item 1

list item 2

Descriptive of nested list item 2

<h3>Test case</h3>
<dl>
  <dt>Term 1</dt>
  <dd>Definition text for term 1 </dd>
<dt>Term 2</dt>
  <dd>Definition text for term 2</dd>
<dt>Term 3</dt>
  <dd>Definition text for term 3</dd>
<dt>Multi definition term 4</dt>
  <dd>Definition 1 for term 4</dd>
  <dd>Definition 2 for term 4</dd>
<dt> DL's containing DL's</dt>
  <dd>
  <dl>
    <dt>list item 1</dt>
    <dd>Descriptive of nested list item 1</dd>
    <dt>list item 2</dt>
    <dd>Descriptive of nested list item 2</dd>
  </dl>
  </dd>
</dl>

Actual behavior:

Reading in browse mode gives the following text:

heading    level 3  Test case
list  with 11 items  Term 1
Definition text for term 1 
Term 2
Definition text for term 2
Term 3
Definition text for term 3
Multi definition term 4
Definition 1 for term 4
Definition 2 for term 4
DL's containing DL's
list  with 4 items  list item 1
Descriptive of nested list item 1
list item 2
Descriptive of nested list item 2

The I key then only navigates through the DT elements, which is more confusing.

Expected behavior:

Criticisms / expectations collected from comments from this issue and other closed duplicates. Bear in mind this is up for discussion.

• dls are read as lists (i.e. "list"), announce instead "Description List" (prior suggestions were "definition list", however see MDN)
• The item count announced should correspond to the number of dt elements.
• Navigate the list using I, NVDA should announce "Term" for each dt element.
  • Then it is ok if the I key moves from dt to dt element.
• When a dt has more than one dd elements associated with it, announce "Term with definitions"
• The nesting of dls is not announced, parent/child relationships should be expressed.
• Relationships between key-value pairs is not expressed
• It also reports the sum of dt and dd elements as the number of items in the list which is misleading.

Name and version of other software in use when reproducing the issue:

Chrome / Edge / Firefox

[nvaccessAuto]

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.

[nvaccessAuto]

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

[bhavyashah]

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

[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.

[ArmandFrvr]

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.

[derekriemer]

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.

[Adriani90]

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.

[brennanyoung]

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.

[masi]

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

[jenstrickland]

Is there a status update on this bug?

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

[talimarcus]

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?

[feerrenrut]

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.

[brunopulis]

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?

[Qchristensen]

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

[brennanyoung]

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.

[paulGeoghegan]

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

elements which is quite annoying for me since it clearly knows that it is a list but there is litterally no aditional information given to the user.

[YetiAnt]

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.

[ferdnyc]

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. :roll_eyes:

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.

[masi]

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.

[ferdnyc]

@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".

[masi]

@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.

[BogdanCerovac]

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...

[ferdnyc]

@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.

[jenstrickland]

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?

[Adriani90]

In my view there is no need to report whether it is a definition list or a description list. A sighted person doesn't see it either what kind of html list it is. Looking at the context, these definition lists are kind of a table, whereby the first column is the term (dt), ant the second is its definition (dd). Every user would understand that Judy is a sub item of "students" and therefore it is a name of a student. There is no need to report that the one is a term and the other one is a definition. So for a definition list where sudents and teachers are defined, there are just two terms that have definitions, so NVDA should report "list with two items" The names of students and teachers are actually subitems of the terms "student" and "teacher" and they should not be treated as separate list items. So NVDA should report "list with 2 items" and not "list with 4 items".

cc: @SaschaCowley

[Adriani90]

Regarding list item navigation, NVDA should ideally report both the dt and all its dd sub items when pressing i to navigate to a list item. E.g.

1. press i, NVDA reports "stutends: Judy, Robin"
2. Press I, NVDA reports "Teacher: Melissa"

[brennanyoung]

I'd like to remind everyone that the spec for <DL> permits multiple <DT> elements for the same <DD> and multiple <DD> elements for the same <DT>.

e.g. in this example, should NVDA report "list of 2 items"? (IMO yes, but if not, then what?)

<dl>
<dt>color</dt>
<dt>colour</dt>
<dd>adj. the visual characteristics of hue, lightness and saturation</dd>
<dt>console</dt>
<dd>v. to reassure and comfort</dd>
<dd>n. a control panel or unit which permits technical interaction</dd>
</dl>

[Adriani90]

Yes, every combination of dt and dd should be one list item. This means a list item begins with dt and ends with the last dd before next dt. This would make the item navigation much more intuitive in my view.Von meinem iPhone gesendetAm 27.10.2024 um 16:55 schrieb Brennan Young @.***>: I'd like to remind everyone that the spec for <DL> permits multiple <DT> elements for the same <DD> and multiple <DD> elements for the same <DT>. e.g. in this example, should NVDA report "list of 2 items"? (IMO yes, but if not, then what?)

color

colour

adj. the visual characteristics of hue, lightness and saturation

console

v. to reassure and comfort

n. a control panel or unit which permits technical interaction

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>