Support for Definition/Description Lists

[Marimbadog]

Summary

While definition/description lists (DL) are read as lists, the relationship between the DT and DD children is not conveyed to the user.

Expected result

Since there is a semantic relationship between the DT and DD elements with in a DL, I would expect that relationship would be read to the user.

Actual result

What I get is "List of 6 items" followed by a list of a straight reading of the list items.

Example

Term 1

This is the first definition

Term 2

This is the second definition

Term 3

This is the third definition

Additional Information

None

JAWS version and build number

2018.1811.2 ILM

Operating System and version

Windows 7

Browser and version:

Tried in Chrome, FF and IE11 for windows.

[mitchellevan]

With the above example, new behavior in JAWS 2023 + Chrome 108:

• DOWN ARROW to the top of the list: announces "Definition list of 3 items"
• L hotkey to jump to list: announces "Definition list of 3 items"
• I hotkey to jump to a list item: jumps only to dt elements; announces the text content of the dt element; does not announce role information.
• DOWN ARROW from dt to the related dd: announces the text content of the dd element like a line of text; does not announce role information.
• DOWN ARROW from dd to the unrelated dt: announces the text content of the dt element like a line of text; does not announce role information.

My opinion (as a part-time screen reader user for accessibility engineering): This is nicely low verbosity and usable if I know I can use the "I" hotkey to jump to dt elements. If I don't know the "I" hotkey, the low verbosity is okay if the text content makes the terms obvious as terms; otherwise it's easy to mix up terms and descriptions.

I couldn't find a verbosity setting to change these behaviors. Nevertheless I would say JAWS now provides enough information to close this issue -- just my two cents.

[TPGJRogers]

@mitchellevan, thanks for pointing this out. I still think there is work for FS to do on this issue.

Lemonade

A mixture of water, sugar, and the juice of one or more lemon often consumed with ice and associated with treats on warm or hot summer days. Some varieties incorporate pulp of the lemon to add texture.

Orangeade

A mixture of water, sugar, and the juice of one or more oranges often consumed with ice and associated with treats on warm or hot summer days. Some varieties incorporate pulp of the orange to add texture.

When read using UP ARROW or DOWN ARROW, the lengthy descriptions break into multiple lines, relying on the user to deduce there is no 1:1 correlation between pressing DOWN ARROW and transitioning between DD and DT elements.

[mitchellevan]

Great example @TPGJRogers.

I still think there is work for FS to do on this issue.

Is this because jumping to the terms with the "I" hotkey is not usable enough, to help distinguish items and grok the structure, even for a user who knows the hotkey? Or is the "I" hotkey okay, but not enough people knowing it? (And I would add, no obvious path to training the public on this)

[TPGJRogers]

@mitchellevan, I think the I hotkey is sufficient. I just think the role of term and the role of description need to be explicitly conveyed. Somehow saying something like "Term: Lemonade," "Description: …," would be my preference. I suspect adding these options to the HTML Verbosity settings would fit within user expectations.

[JAWS-test]

I would like to add that, according to the HTML specification, a definition list can have multiple dt and multiple dd immediately after each other, e.g. 2 dt for 1 dd or 1 dt with 2 dd. There is no one-to-one mapping from dt to dd. Therefore, it is important that JAWS not only jump after pressing I to the next dt, but also to hear whether it is currently a dt or dd when navigating through the list

[stevefaulkner]

@RFischer-FS @ggordon-vispero @BrettLewisVispero for discussion. The current behaviour is non - optimal, but need user research/feedback on how to best support.

[stevefaulkner]

@RFischer-FS @ggordon-vispero @BrettLewisVispero for discussion. The current behaviour is non - optimal, but need user research/feedback on how to best support.

i will test in other screen readers to see how they support