Re: HTML5 DL Element vs. WCAG 2.0 Success Criteria

Hi all,

I was curious about this, so I ran my own test (JAWS 15 and Internet
Explorer 8).

I added some buffer text so that I have some "wiggle" room and not just
plop onto the list as the page loads.
Right after the page loaded I clicked "L" and JAWS declared "Definition
list of three items", now I first tried to click through by pressing "I"
only, and got "Name", "Email", "Location", so JAWS just read the <dt>, but
I know it's a definition list, JAWS said so when I pressed "L". Pressing
"L" again JAWS declares "Wrapping to top definition list of 3 items", now
I know that this is a definition list with 3 items, and I know what those
items are, I just arrowed down through the list, and was read the full
content of the list.

Yes, it's not perfect! I'd love to hear JAWS declare "definition term
name" and "definition description Ramón Corominas" etc. but I would also
say it's not all that bad, after all I know what kind of list this is, I
know what the 3 main items on this list are, and now I have filled-in the
blanks.

Given the fact that this is a short list, it's OK. If this would have been
a longer list, I'd probably be lost at some point, and probably sooner
than later.

Cheers,
Geri Druckman

Web Development Specialist - Accessibility
Department of Internet Services
MD Anderson Cancer Center
T 713-792-6293 | F 713-745-8134






On 2/6/14 5:05 PM, "Ramón Corominas" <listas@ramoncorominas.com> wrote:

>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 Friday, 7 February 2014 00:18:55 UTC