RE: HTML5 DL Element vs. WCAG 2.0 Success Criteria

Hi,

a couple of weeks ago I went through some of that. As far as I could see
there were no browsers on Windows that expose the roles "definition" or
"term" in the accessibility tree. That goes for <dt>/dd>, for <dfn> and for
role="term"/role="definition". 


Jan

> -----Original Message-----
> From: Duff Johnson <duff@duff-johnson.com>
> Sent: Tuesday, April 9, 2019 12:21 AM
> 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.
>