Please provide an actual sample or two with content. Right now I’m not seeing from those examples why things need to change in the specification. There are already plenty of methods to get those things handled well.
@Garbee The three examples I mentioned are description lists whose orders are important. There are also plenty of description lists whose orders aren’t important, and I believe we don’t need actual samples to know that those lists exist.
Could you please elaborate on the “plenty of methods” that can get those things handled well?
So, this conversation seems to be stuck on needing some proof which isn’t being provided.
Changing things has a cost, no matter how small it may seem. No one working on browsers is going to change something without some empirical example of proof showing that a thing needs changing because the provided case is not possible in another means. The burden of proof is on people requesting a change to show why it is necessary. Then vendors can do some analysis at some sort of larger scale to see if the problem is widespread enough to be acted upon.
Until a hard physical example with full context is provided you’ll be hard pressed to find anyone willing to put any effort behind it in a standards body. Things don’t move based on abstract notions of what might be good. They move based on vendors seeing actual real-world developers having problems that are extremely difficult to work around or simply not possible any other way with the provided set of technologies.
@Garbee We already have countless examples on the internet, don’t we? Every
dl element we see is a living example.
dd directly inside
li was suggested as an alternative to
dl. It didn’t get much consideration due to compatibility problems.
You can add numbering to description lists via CSS example: http://codepen.io/stevef/pen/PbEVVb Modern Screen readers announce the CSS egenerated content no problem. I just tested with latest JAWS.
@SteveF Thanks for the information. But wouldn’t it be inappropriate to rely on CSS for semantics? Since CSS was designed for presentation, I suggest that we look at HTML on this issue.
Since CSS is for presentation, announcing its generated pseudocontent as real content is probably either a bug of corresponding screen readers, or a desperate measure caused by misuse of generated content by some authors. CSS has nothing to do with HTML semantics.
Also, I doubt the way screen readers read CSS-generated indices is identical to the way those read regular ordered lists (
this may be of interest http://tink.uk/accessibility-support-for-css-generated-content/
Taking JAWS as an example; there is no difference in announcement between ol/ul lists it identifies it as a list and the number of items and if there are visible bullets (ul) or numbers (ol) it announces them along with item content. For description lists if numbers are present it announces them along with the item content. So your doubt is unfounded.
Thierry has provided a more sophisticated demo that handles multiple
I haven’t heard of any spec says that CSS generated contents should be announced by screen readers so I’m not sure if the test results mentioned by @SteveF are working as intended or not.
And I still suggest that HTML needs a way to handle this issue on its own and should not rely on a presentational language. If we should just use CSS to create semantics we need, discussions like [proposal] list head/caption/title would be pointless.
The design of much of HTML is certainly flawed. The relevant question is whether a given flaw creates problems serious enough to justify the cost of fixing it.
I doubt the benefit of explicitly stating that the DOM order in a
dl is meaningful justifies a change to HTML.
dd blocks is, as @crissov mentioned, something that is unfortunately not easy to do in a way compatible with the web.
If the ordering within a block or list is considered important, you “suggest” that, using CSS, or as an explicit part of the content. You could even use schema.org markup to make it machine-readably explicit:
<div vocab="http://schema.org/" typeof="ItemList"> <h2 property="name">Top song covers</h2><br> <link property="itemListOrder" href="http://schema.org/ItemListOrderAscending" /> <dl> <dt property="itemListElement" typeof="ListItem"> <span property="position">3</span> Venus</dt> <dd>The Bangles, who also deserve a shout out for Hazy Shade of Winter</dd> <dt property="itemListElement" typeof="ListItem"> <span property="position">2</span> Hallelujah</dt> <dd>Rufus Wainwright's classic version</dd> <dt property="itemListElement" typeof="ListItem"> <span property="position">1</span> Tainted Love</dt> <dd>Soft Cell's justification of Karaoke</dd> …
ARIA provides another machine-readable way to identify a list, but apparently there wasn’t a need to explicitly note ordering, which can be read as suggesting that for accessibility purposes DOM ordering is good enough for reality.
In any event, there is more than one type of ordering that would be useful.
<dl> <dt>waste</dt> <dd id="def-garbage">1. Noun. Garbage</dd> <dd>2. Noun. Excessive consumption. This is a stronger meaning than <a href="#def-garbage">1</a> above</dd> <dd>3. Verb. To consume unnecessarily</dd> <dd>4. Verb., colloquial. To destroy</dd> …
@chaals This thread does not suggest stating the DOM order in
dl explicitly. It suggests using
And as the spec of microdata says, “It’s important to note that there is no relationship between the microdata and the content of the document where the microdata is marked up.” and “There is no semantic difference, for instance, between the following two examples:”, it appears that we should not use microdata for semantics.
Forgive me for being frank, but I’m confused. First you say you want the user to visually see that a
<dl> list is ordered vs unordered.
This statement is clearly describing that the main benefit is for users to see the difference visually, which is a “presentation” concern. Other’s have provided examples to address this presentation concern using CSS. Then, you say the goal is not just presentational, but should also be read by AT. Then, multiple people address that AT already reads the order of the
<dl> elements in the DOM. Then, your position changes, suggesting that we dismiss these methods in favor of changing the HTML spec as a result. Then we say OK and ask you to give us clear use-cases where it warrants changing the spec. Then you tell us to look at any
<dl> list on the internet, all of which do not appear to suffer from any issue or flaw in using
<dl>s and further illustrate how this change is unnecessary.
Based on what I mentioned above, all of your concerns have been addressed, yet somehow that is still not satisfactory to you. It seems like we’re going in circles and not sure I still have a clear understanding of what the issue is anymore.
@mkay581 I do not want users to know a
<dl> is ordered vs unordered. Instead, I suggest deprecating
<dl> tag and using
<dd> tags inside
<ol> like the two pieces of code in the original post.
ATs never read the “order” of
<dl> has no “order” for ATs to read.
<dl> on the internet does suffer from the flaw that there is no way to define it is ordered or unordered.
This is the whole point of marking them up as one or the other. This goes against the very foundation of your discussion thus far saying that they need to be allowed as a child of one or the other.
Either users need to know this therefore the markup needs changing or they don’t need to know this and what we have currently is just fine.
Unless you provide a case illustrating your point beyond a doubt that change is necessary, I’m not sure what anyone can do here to influence vendors into changing. You’re starting to grind against your own path it seems.
The order should be read in the order they are listed in the document. Is there a known case where this isn’t done?
Not true. You only can’t define them as ordered via markup they are inherently unordered.
Sorry, but I don’t understand what you mean here. Anyway, IMHO, the design of
<dl> is flawed so we don’t need to work on it.
All things are read in the order they are listed in the document. But users still don’t know if that order is important. And that’s why
<ol> are needed.
That’s an arguable flaw anyway.