Re: HTML5 DL Element vs. WCAG 2.0 Success Criteria

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.


Sailesh wrote:

> DL-DT-DD is good for  conveying paired relations that can be
> represented in a 2-column data table too ... basically wherever  there
> is a label->data relationship.
> Use either that suits the specific design preference / style as long
> as data relationships are conveyed as intended in order to meet SC
> 1.3.1 (A).

Received on Thursday, 6 February 2014 23:06:29 UTC