Re: HTML5 DL Element vs. WCAG 2.0 Success Criteria

At least two of the three screen readers I use at least announce DL's if not fully  parse out term vs definition.

I can check with latest versions of JAWS, NVDA, and VoiceOVer for Macintosh against the site mentioned in the list if it would be appreciated.

Jonathan


On 4/8/19, 6:26 PM, "Duff Johnson" <duff@duff-johnson.com> wrote:

    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 Tuesday, 9 April 2019 12:33:28 UTC