Definition Lists vs. Data Tables [Was: HTML5 DL Element vs. WCAG 2.0 Success Criteria]

Hi, Olaf and all,

Maybe WCAG 2.0 itself is a "real world example" <wink>

WCAG 2.0 Recommendation
http://www.w3.org/TR/WCAG20/

It contains 4 definition lists:

1. Document info (the introductory section of every W3C document that 
contains info about "this version", "latest version", "editors" and so on)
2. Important terms in WCAG 2.0
3. Glossary
4. References


DEFINITION LISTS VS. DATA TABLES

I will concentrate on two of these lists:

a) Definition List 1: Document info

This is the only one that has more than one <dd> per <dt>, for the 
"Editors" and "Previous Editors". In this list, navigating with the I 
key gives you the "terms" of the terms, and from there you have to move 
down to obtain the -plain- information of the "definitions".

You can also press "P" after reading the term, but then all the <dd> 
elements AND the next <dt> will be read as a single thing (I suppose 
this is the reason that someone suggested to include <p> inside each <dd>).

Now suppose that we used a simple table instead of a <dl>, using row 
headers to identify each data. The structure will be more or less this:

<table>
<tr>
   <th scope="row">This version:</th>
   <td>http://www.w3.org/...</td>
</tr>
...
<tr>
   <th scope="row">Editors</th>
   <td>
     <ul>
       <li>Ben Caldwell ...</li>
       <li>Michael Cooper ...</li>
       ...
     </ul>
   </td>
</tr>

With this structure, the screen reader user will receive first the 
number of rows in the table (that is, the number of "terms" = labels). 
Then the user can move through the rows to identify the labels and 
through the columns to get the associated info. Since the headers will 
be read when moving up and down through the data cells, the user does 
not even need to go to the left to read the labels that identify the info.

For those rows with multiple names, the user will get the label and know 
that they contain a list of "N" items associated to that label; this way 
it's easy to navigate the different items ("definitions") independently 
and retaining the association with the label. Unfortunately, JAWS does 
not read the <th> info if the user jumps to the next list using the "L" 
key, but it would still be easy to just move to the left to know which 
is the label for that list, or move up and down through the table cells 
to force JAWS to announce the header.

In addition, this behaviour is virtually the same using JAWS, NVDA or 
VoiceOver.


b) Definition List 4. The glossary

Nagiating the glossary as a definition list is even harder, because 
there are several nested lists in some terms. Thus, pressing the "I" key 
does not simply jump through the terms of the main definition list, but 
also through the nested items.

Certainly, JAWS makes a "beep"  that somehow indicates that the list has 
changed, but there are lists with more than one nesting level and the 
beep is always the same. You cannot distinguish if the beep indicates a 
deeper nesting level or if it indicates that you are going back to the 
upper level. You can only know about the nesting level if you move up 
and get the list information.

Since the only way to move through the terms is the "I" key, this 
behaviour causes great confusion and makes the glossary almost 
impossible to navigate in an efficient way. Of course the user can jump 
and jump trying to reach the intended term, but in the way he will 
encounter many nested lists that introduce a lot of clutter.

Now, suppose that we create the glossary as a data table similar to the 
previous one. We can even add two columns on top to indicate "term" and 
"definition", although they are probably unnecessary. In any case, these 
column headers and the caption can be visually hidden to preserve the 
design. The glosarry table might be as follows:

<table>
<caption>Glossary</caption>
<tr>
   <th scope="col">term</th>
   <th scope="col">definition</th>
</tr>
<tr>
   <th scope="row">accessibility supported</th>
   <td>
     <p>supported by users' assistive technologies...</p>
     <p>To qualify...</p>
     <ol>
       <li>The way that...</li>
       <li>The Web content...
       <ol>
         <li>The technology is supported...</li>
         ...
       </ol>
       </li>
     </ol>
     <p>Note 1: ...</p>
     ...
   </td>
</tr>
...
</table>

Once again, you will get the number of rows (which is the number of 
terms + 1), and it is easy to quickly navigate through the first column 
reading only the term name. When you reach the proper term, you can 
simply move to the right and obtain the complete definition, which can 
also be navigated simply moving down.

Again, the behaviour is similar using JAWS, NVDA and VoiceOver.


A BIT ABOUT SEMANTICS...

The main argument in favour of definition lists is that they are more 
"semantically correct". I assume that this means that the user receives 
better information about the structure being navigated, so it is more 
understandable.

Really? Are the above data tables less "semantic" than definition lists? 
Are they conveying a strange or confusing structure to the user? Will 
the user have difficulties understanding the association between the 
"term" and its "definitions". Indeed, I guess that the table structure 
will be much more clear for most users.

Of course, a data table can be easily styled to look like a definition 
list using display: block for the <th> and <td>, and adjusting 
text-indents, margins, list styles, font properties and so on.


SHOULD <DL> BE DEPRECATED?

In my opinion, yes. <dl> should be deprecated in future versions of 
HTML, in favour of data structures or maybe simple lists in certain cases.

Indeed, it would probably be better to have a single <l> element, 
similar to the PDF tag, since the <ol> and <ul> convey exactly the same 
structure to the screen reader and both can be re-styled to look like 
the other type.

Nevertheless, the <ol> and <ul> elements have been more widely used, and 
are the preferred element for navigation menus, toolbars, etc., so they 
are probably used nearly in 100% of current pages, and therefore the 
consequences of the change would be much more important.

Regards,
Ramón.


Olaf wrote:

> can you point me to some real world content that uses definition lists?
> 
> I have yet to run into them (and I kept looking for them for a while after I was made aware they exist, and I haven't found any in real world content, as opposed to examples put together for demonstration).
> 
> My criticism still holds though, as I honestly believe definition lists have been invented for a very special use case. If I look on the web for example at online dictionaries (I use dict.leo.org a lot),  definition lists would bot cut it - the structure presented is richer than can be easily accommodated using definition lists. Also the leading German dictionary site duden.de does not use this structure. 
> 
> Furthermore, if I look at various online resources like http://www.abbreviations.com/ none of them seems to be using definition lists anywhere, most of them use tables, partly probably because they can organise additional bits and pieces more easily, and to be honest, in a fashion that is more useful to users (with and without disabilities).
> 
> So where are those websites or documents that use definition lists?
> 
> What authoring tools exist that allow you to create definition lists?
> 
> Thanks,
> 
> Olaf
> 
> PS: Why is a page like 
> 	HTML 4.01, Index of Elements 
> 	http://www.w3.org/TR/html401/index/elements.html
> using a table, not a definition list?
> 
> Same for:
> 	XHTML 2, J. List of Attributes
> 	http://www.w3.org/TR/xhtml2/attributes.html
> 
> and here an unordered list is used:
> 	HTML: The Markup Language (an HTML language reference), 5. HTML elements organized by function
> 	http://dev.w3.org/html5/markup/elements-by-function.html
> 
> OK, now I found an example for definition lists are used:
> 	HTML: The Markup Language (an HTML language reference), 2. Terminology
> 	http://dev.w3.org/html5/markup/terminology.html#terminology
> and it makes use of another tag I have just now knowingly seen for the first time - the dfn tag. I have difficulty seeing why I need another tag called  dfn inside a dt  tag, if the meaning of dt is definition term and the meaning of dfn is definition term? In all politeness, but this looks like a big mess to me.
>

Received on Saturday, 8 February 2014 14:40:42 UTC