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.