RE: HTML5 DL Element vs. WCAG 2.0 Success Criteria

Adrian Roselli created an informative pen on CodePen in May 2018 that addressed this very issue:
https://codepen.io/aardrian/full/NzGaKP/ 


Amy Carney
Publications Specialist

Andrew P. Kashevaroff Building
Mail: PO Box 110571, Juneau, AK 99811
Visit: 395 Whittier St., Juneau, AK 99801
phone: 907.465.1313

email | web |  sign up for event notifications


-----Original Message-----
From: Duff Johnson <duff@duff-johnson.com> 
Sent: Monday, April 8, 2019 2:21 PM
To: w3c-wai-ig <w3c-wai-ig@w3.org>
Subject: Re: HTML5 DL Element vs. WCAG 2.0 Success Criteria

I was hoping members of this list might have a ready update on the status of AT support for <dl>.

The post below, from 2014, asserts with some authority that common AT did not support <dl> at that time.

Has this situation changed?

Thanks,

Duff.

———————

From: Ramón Corominas <listas@ramoncorominas.com>
Date: Fri, 07 Feb 2014 00:05:45 +0100
Message-ID: <52F41549.5060909@ramoncorominas.com>
CC: w3c-wai-ig@w3.org 

Hi all,

I find it a bit surprising that everyone seems to recommend <dl> just because the "semantics" may be adequate according to the spec, or because it supposedly meets SC 1.3.1 for that "programmatically determinable" possibility, but without really testing the thing with real-world screen readers.

The reality is that most screen readers say nothing about the type of list, nor convey any relationship between <dt> and <dd> parts of the list.

For example, I've created the following list:

<dl>
   <dt>Name</dt>
     <dd>Ramón Corominas</dd>
   <dt>E-mail</dt>
     <dd>
ramon@ramoncorominas.com
</dd>
     <dd>
rcorominas@technosite.es
</dd>
   <dt>Location</dt>
     <dd>Madrid</dd>
</dl>

Now, let's see how different screen readers interpret this:


JAWS 14 + Firefox 24

- Pressing "L" (for lists), JAWS reads a "list of 3 items" (no indication that it is a definition list, but "ok").
- Pressing "I" (for list Items), JAWS jumps through the different <dt> elements (and in principle it only reads the <dt> content).
- If the user wants to read the definition, s/he has to press the down arrow key. Remember that there is no indication that this is a definition list, so the user will not know that the "item" has more information. In any case, this is the same for other types of lists, so lets assume that the user moves down.
- In the second term, there is no indication that there are two different "definitions" (or two different data that are associated to a single <dt>).

In other words, the list contents are read as "plain text" without any semantics or roles that inform the user about the relationships between the data and the "header".


NVDA 2013.3 + Firefox 24

- Pressing the "L" key, NVDA reas a "list of 7 items", which is even worst than the "3 items" read by JAWS, since again there is no indication that the list is a definition list.
- Pressing the "I" key, the user moves through the main <dt> elements. 
Remember that the screen reader announced 7 items, but the user now can only find 3. Where are the other 4 items? There is no indication that the items been read are "definition terms", so the user cannot guess that this is a definition list. But suppose that the user is very smart and simply moves down...
- Again, no semantics are conveyed to indicate that the user is moving through different definitions, so again we have just plain text without no relationship between data and headers.


VoiceOver + Safari 5.1 (Snow Leopard)

- I don't know if there is a quick key to move through lists, but moving using the VO + arrow keys, VoiceOver announces a "list of 7 items", similar to NVDA.
- Moving again with VO + right arrow, the definition terms and the definitions are read as plain text, no semantics, no relationship.


I don't have other screen readers installed, but I think these are probably three of the most used screenreaders. I've only tested using Firefox / Safari, but I guess that the results will be very similar on other browsers.


CONCLUSION

Definition lists are not accessibility supported. Period.

If you use -today- definition lists for conveying relationships between the data and their headers, you are failing to meet Conformance Requirement #4, and therefore you are failing WCAG 2.0. Maybe in the future the situation changes, but I think that this is still not a valid technique to conform.

I admit that tables might not be the best solution and that they look "ugly" in terms of semantics, but they are quite more accessibility supported and far more easy to understand. Even simple <ul> or <ol> lists have better support; at least the screen readers announce a "nesting level" that conveys an extra piece of "relationship".

Ok, maybe single pairs label-value are ok in certain situations, but even in those cases the list would be announced as having double number of items in NVDA and VoiceOver, so I think it is not a technique that can be recommended.

Kind regards,
Ramón.

Received on Monday, 8 April 2019 22:47:50 UTC