I am trying to determine the best way to create an accessible accordion/list that has sub-headers (or group separators/collapsible headers, if you will).
To illustrate, this is how a default one would look (schematically):
Some of the items are clickable (and provide a hint to that by changing the background color and changing the cursor) and some are not (like "List item 13").
Some (or all) sub-headers may be collapsible (with some additional hints added later):
Now, the structure can be implemented in several possible ways:
Option 1. To hell with standards and accessibility
<ul>
<div class="header"><a href="...">Header 1</div>
<li>List item 11</li>
<li>List item 12</li>
<li><span>List item 13</span></li>
<div class="header"><a href="...">Header 2</div>
<li>List item 21</li>
<li><span>List item 22</span></li>
</ul>
This one does work. It is not accessible and doesn't pass HTML validation, but it works.
Option 2. Well, at least it passes validator
<ul>
<li class="header">Header 1</li>
<li>List item 11</li>
<li>List item 12</li>
<li><span>List item 13</span></li>
<li class="header">Header 2</li>
<li>List item 21</li>
<li><span>List item 22</span></li>
</ul>
This one passes validation and is accessible to an extent, but doesn't allow for distinction (as far as screen readers go) between a header and a regular clickable list item.
Options 3. TL;DR
<ul>
<li>
<a class="header" href="...">Header 1</a>
<ul>
<li>List item 11</li>
<li>List item 12</li>
</ul>
</li>
<li>
<a class="header" href="...">Header 2</a>
<ul>
<li>List item 21</li>
<li><span>List item 22</span></li>
</ul>
</li>
</ul>
This one, or some more thought-out variation of it seems to be the one. Accessible, as I assume outer or inner bullets should be read properly by a screen reader and passes validation.
It's just a bit more PITA to code and maintain. Both from JS and CSS perspective and especially if it's a plugin that is intended to be extended and customized.
So the question is - which one, if any, of the above would be better. Or, alternatively, what would be the ultimate accordion/list implementation? (which, from my experience, may be a pipe dream)
The third option beats the other two by far in terms of accessibility. If the accordion/list did have a lot of content then it may be worth adding headings (<h1>, <h2>, etc.) to each of the list items. This would provide more semantic structure to the page which would be helpful to users using assistive technology.
<h1>Some sections</h1>
<ul>
<li>
<h2><a class="header" href="...">Header 1</a></h2>
<ul>
<li>List item 11</li>
<li>List item 12</li>
</ul>
</li>
<li>
<h2><a class="header" href="...">Header 2</a></h2>
<ul>
<li>List item 21</li>
<li>List item 22</li>
</ul>
</li>
</ul>
The third option is also the nicest to style and manipulate with JavaScript due to its hierarchical nature.
Implicit sectioning
There was a discussion about implied and explicit sections in the comments so I thought I would address it. I attempted to download the HTML5 Outlier Chrome extension to test this but unfortunately it didn't seem to show up in the bar. Here is how I understand it:
The sectioning root elements in HTML5 are:
<body>
<blockquote>
<details>
<fieldset>
<figure>
<td>
<nav>
<aside>
<footer>
<header>
Since none of them are present the sections are implicit from the usage of the heading elements much like in HTML4 so the document outline for the markup above would look like this:
Some sections
1.1. Header 1
1.2. Header 2
This is exactly what we expect and what we want. This is from unor's comment
It's allowed syntactically. But it would be an issue for the document outline: the start of a new section (→ opening li), introduced by the heading, would still be part of the previous section. If you use the section (or any other sectioning element) expliclty, the start and end of that section is clearly specified.
I believe he's saying that the <li> before '1.1. Header 1' would be part of the section '1. Some sections' which is true and I'm my opinion not a problem as the <li> should belong to the section above. The usage of a sectioning root element like <section> to explicitly define a section block would lead to very much the same result as we had previously:
<ul>
<li>
<section>
<h2><a class="header" href="...">Header 1</a></h2>
<ul>
<li>List item 11</li>
<li>List item 12</li>
</ul>
</section>
</li>
I'm of the opinion (can't find a source) that implicit sectioning is just as 'scoped' as explicit sectioning would be. Since the document outline is a list the </li> after the </section> in the above would still be part of 1.1 Header 1 according to the document outline like this.
<!-- start 1. Some sections -->
<h1>Some sections</h1>
<ul>
<li>
<section>
<!-- start 1.1. Header 1 -->
<h2><a class="header" href="...">Header 1</a></h2>
<ul>
<li>List item 11</li>
<li>List item 12</li>
</ul>
</section>
</li>
<li>
<!-- end 1.1. Header 1 -->
<section>
<!-- start 1.2. Header 2 -->
<h2><a class="header" href="...">Header 2</a></h2>
<ul>
<li>List item 21</li>
<li>List item 22</li>
</ul>
</section>
</li>
</ul>
<!-- end 1. Some sections -->
That is to say, once you start a sub-section you cannot end it until you start another section so </li><li> would be included at the end of '1.1. Header 1' and also included in its parent section '1. Some sections'.
References
Mozilla Developer - Implicit sectioning
Smashing Magazine - HTML5 And The Document Outlining Algorithm
HTML5 Doctor - Outlines
Related
I have a list of agenda items I want to display.
For that I would use a simple ul.
The thing is that within this list I have grouped the items by month. So in general they are sorted by date and now they are also grouped by month.
Example:
January 2010
- Item 1
– Item 2
February 2010
- Item 3
– Item 4
March 2010
- Item 5
– Item 6
How could I make this information more accessible.
I found this POST about role="group" which seems to be right here?!
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_group_role
So would the following structure make sense?
<ul>
<li role="group">
<h3>January 2010</h3>
<ul>
<li>Item 1</li>
<li>Item 2</li>
</ul>
</li>
<li role="group">
<h3>February 2010</h3>
<ul>
<li>Item 3</li>
<li>Item 4</li>
</ul>
</li>
</ul>
Or how would I make clear that the nested ul is a group.
Or would I leave away the nested uls, build everything with a single ul with equal li for every entry?
Or would I do something like:
<div role="list">
<div>
<h3 id="label-1">January 2010</h3>
<ul aria-labelledby="label-1" role="group">
<div role="listitem">Item 1</div>
<div role="listitem">Item 2</div>
</ul>
</div>
<div>
<h3 id="label-2">February 2010</h3>
<ul aria-labelledby="label-2" role="group">
<div role="listitem">Item 3</div>
<div role="listitem">Item 4</div>
</ul>
</div>
</div>
I would be very glad for some inputs.
Thank you in advance.
cheers
role="group" is not intended for use on non-interactive items. It is designed to group controls such as inputs, buttons together or for grouping elements that are related.
Your third example is closest to the way this should be structured. The headings are great for quick navigation (as heading levels are one of the primary ways screen reader users navigate a page) and the relationships are created within the HTML itself, removing the need for any extra WAI-ARIA.
Yet again there is no need for role="group".
The following example would be perfectly acceptable and accessible. I have change it to a set of listed <ul> and <li> as that is semantically correct and removes the need for any WAI-ARIA there also. (Golden rule, use semantic elements if you can as support is 100% for those, support for WAI-ARIA is a little patchy still. and so should be used for complimentary information / if there is no way to achieve the desired document structure / relationships using standard HTML5 elements.)
Obviously if the Items 1 to 4 are interactive elements and you have left that out for brevity then that is a different matter entirely and I will change this answer.
<ul>
<li>
<h3>January 2010</h3>
<ul>
<li>Item 1</li>
<li>Item 2</li>
</ul>
</li>
<li>
<h3>February 2010</h3>
<ul>
<li>Item 3</li>
<li>Item 4</li>
</ul>
</li>
</ul>
I am trying to solve the reason that the unit test on testdome.com failing >my HTML code.
The output seems to be all right.
The URL of the task: https://www.testdome.com/Questions/HtmlCss/Inspector/6932?testId=13&testDifficulty=Easy
I am getting message: Lists and images: Wrong.
<ol>
<li><em>Company's logo</em></li>
<li>List of employees</li>
</ol>
<ul>
<li>New logo:</li>
<img src="new_logo.gif" />
<li>Old logo:</li>
<img src="old_logo.gif" />
</ul>
Omit the end slash from the img tag and add an alt tag. Also, enclose the img tag within the li tags (so you have 2 list items instead of 4 - the names with the images underneath is how it's currently coded). Then you should be ok.
Sample :
<ol>
<li><em>Company's logo</em></li>
<li>List of employees</li>
</ol>
<ul>
<li>New logo:<img src="new_logo.gif" alt="new logo"></li>
<li>Old logo:<img src="old_logo.gif" alt="old logo"></li>
</ul>
For a list of portfolio-items, which all have a year, I am assuming an ordered list is the way to go semantically since it is a list ordered by year. However, I don't want the value to be a number starting at 1, but the year in which the item was created. To reach this result I wrote the following.
<ol>
<li value="2015">Last made item</li>
<li value="2015">Item before that</li>
<li value="2014">Earliest item</li>
</ol>
However, this
reverses the natural order of <ol>'s;
Uses the same marker multiple times;
so I would think this isn't exactly the best way to accomplish this. So I would like to know:
Do you have any suggestions on how to do improve this?
Are there any more reasons why this should not be done this way?
Edit: Please note the list has already been sorted, but I want the marker to be the year in which the item was created. This happens using the method mentioned earlier (see this Fiddle, too), but I'm doubting this is the best way to go, semantically.
1. Do you have any suggestions on how to do improve this?
Alternative A
A good alternative would be a structure like this:
<article>
<time datetime="2015">2015</time>
<h1>Last made item</h1>
<p>Description</p>
</article>
<article>
<time datetime="2015">2015</time>
<h1>Item before that</h1>
<p>Description</p>
</article>
<!-- etc. -->
This assumes the items in the list could be representable as a "independent item of content" (W3C specification) and a portfolio-item, which was the type of item in my question, meets this specification.
Alternative B
<ol>
<li>
<time datetime="2015">2015</time> Last made item
</li>
<li>
<time datetime="2015">2015</time> Item before that
</li>
<!-- etc. -->
</ol>
With CSS you could remove the marker if desirable. Thanks to TotempaaltJ for this alternative.
Either way the year is now machine readable as being time, see MDN.
This element is intended to be used presenting dates and times in a machine readable format. This can be helpful for user agents to offer any event scheduling for user's calendar.
Read Bruce Lawson's post on the time tag to see this datetime notation works/is allowed.
Now, “fuzzy dates” are possible:
<time datetime="1905"> means the year 1905
2. Are there any more reasons why this should not be done this way?
When using <li value="year"> you're losing the meaning of the number as being a year.
Other thoughts
#Michael_B's answer gave me more insight into the meaning of <ol> and <ul> and #tibzon gave an example with the reversed attribute of an ordered list, see his fiddle.
tag is not going to do any sorting algorithm for you. HTML is a markup language which is only used for displayed purpose. is only used for a order-list and you have to do the ordering your self.
If you content is generated using a backend language, then you can use the backend language to do the sorting algorithm and print whatever number you want in front. And since you don't want the number starting with 1, I would suggest you using instead.
For example, if you are using PHP for the backend language, you can use the following code:
echo "<li>".$year." - $content."</li>";
I am not sure your sorting algorithm so can't help with that. Hope this help.
If you want to create an ordered list in HTML and specify a starting number other than 1, you can use the start attribute in the ol tag.
<ol start="2014">
<li>Last made item</li>
<li>Item before that</li>
<li>Earliest item</li>
</ol>
Here's a DEMO.
UPDATE
Based on your revised question and new comments, I see that your focus is primarily on the semantics of the code. Specifically, is this code...
<ol>
<li value="2015">Last made item</li>
<li value="2015">Item before that</li>
<li value="2014">Earliest item</li>
</ol>
... semantically correct?
The answer is yes. Semantically, you're totally fine.
Features of the HTML Ordered List <ol>
An ordered list (ol) simply means the order of the list matters, whereas in an unordered list (ul) the order of each list item is unimportant, and each list item can be sorted randomly because the order doesn't matter.
Here's what the HTML5 spec says about ordered lists:
The ol element represents a list of items, where the items have been
intentionally ordered, such that changing the order would change the
meaning of the document.
Here's how MDN puts it:
The <ol> and <ul> both represent a list of items. They differ in the
way that, with the <ol> element, the order is meaningful. As a rule of
thumb to determine which one to use, try changing the order of the
list items; if the meaning is changed, the <ol> element should be
used, else the <ul> is adequate.
Here's what the HTML5 spec doesn't say:
It doesn't say the numbers or letters marking each line item have to be numbers or letters. They don't.
It doesn't say the numbers or letters marking each line item have to be in chronological order. They don't.
It doesn't even say that each line item must have a number, letter or other marker. It doesn't. It can be left blank (see CSS list-style-type: none).
These examples, where the order of the list has meaning, are valid and semantically correct HTML.
<ol>
<li value="2025">Portfolio 1</li>
<li value="2010">Portfolio 2</li>
<li value="1999">Portfolio 3</li>
<li value="2005">Portfolio 4</li>
<li value="2015">Portfolio 5</li>
<li value="2014">Portfolio 6</li>
</ol>
<ol type="a" reversed>
<li>Portfolio 1</li>
<li>Portfolio 2</li>
<li>Portfolio 3</li>
<li>Portfolio 4</li>
<li>Portfolio 5</li>
<li>Portfolio 6</li>
</ol>
<ol style="list-style-type: none;">
<li>Portfolio 1</li>
<li>Portfolio 2</li>
<li>Portfolio 3</li>
<li>Portfolio 4</li>
<li>Portfolio 5</li>
<li>Portfolio 6</li>
</ol>
Run examples in Fiddle
Our site has two primary navigation links to two completely different pages. Something like this:
<section>
<header>
<nav>
<ul>
<li>Link 1</li>
<li>Link 2</li>
</ul>
</nav>
</header>
</section>
On one of the pages, we also have a filtering component made up of a list of links that uses Ajax to change the result set listed in the main content area (similar to how kayak.com filters their flight options in real time as you adjust sliders, click checkboxes, etc.)
My question is, should that group of filtering links be wrapped in a <nav> element?
It would look like this:
<section>
<nav>
<ul>
<li>Filter 1</li>
<li>Filter 2</li>
<li>Filter 3</li>
<li>Filter 4</li>
<li>Filter 5</li>
</ul>
</nav>
</section>
The reason for my confusion is that the spec is not clear as to whether materially changing the content of the page via a method such as filtering constitutes "primary navigation". Also, I'm not sure if having two nav elements on the page like this would be semantically confusing from an accessibility standpoint.
You could, but it's not semantically correct. I'd go for a command tag here, because you're not navigating the content, you're giving the command to show/hide certain content based on some criteria.
The W3 docs have a nested list example prefixed by DEPRECATED EXAMPLE:, but they never corrected it with a non-deprecated example, nor explained exactly what is wrong with the example.
So which of these ways is the correct way to write an HTML list?
Option 1: the nested <ul> is a child of the parent <ul>
<ul>
<li>List item one</li>
<li>List item two with subitems:</li>
<ul>
<li>Subitem 1</li>
<li>Subitem 2</li>
</ul>
<li>Final list item</li>
</ul>
Option 2: the nested <ul> is a child of the <li> it belongs in
<ul>
<li>List item one</li>
<li>List item two with subitems:
<ul>
<li>Subitem 1</li>
<li>Subitem 2</li>
</ul>
</li>
<li>Final list item</li>
</ul>
Option 2 is correct.
The nested list should be inside a <li> element of the list in which it is nested.
Link to the W3C Wiki on Lists (taken from comment below): HTML Lists Wiki.
Link to the HTML5 W3C ul spec: HTML5 ul. Note that a ul element may contain exactly zero or more li elements. The same applies to HTML5 ol.
The description list (HTML5 dl) is similar,
but allows both dt and dd elements.
More Notes:
dl = definition list.
ol = ordered list (numbers).
ul = unordered list (bullets).
Official W3C link (updated).
Option 2
<ul>
<li>Choice A</li>
<li>Choice B
<ul>
<li>Sub 1</li>
<li>Sub 2</li>
</ul>
</li>
</ul>
Nesting Lists - UL
Option 2 is correct: The nested <ul> is a child of the <li> it belongs in.
If you validate, option 1 comes up as an error in html 5 -- credit: user3272456
Correct: <ul> as child of <li>
The proper way to make HTML nested list is with the nested <ul> as a child of the <li> to which it belongs. The nested list should be inside of the <li> element of the list in which it is nested.
<ul>
<li>Parent/Item
<ul>
<li>Child/Subitem
</li>
</ul>
</li>
</ul>
W3C Standard for Nesting Lists
A list item can contain another entire list — this is known as "nesting" a list. It is useful for things like tables of contents, such as the one at the start of this article:
Chapter One
Section One
Section Two
Section Three
Chapter Two
Chapter Three
The key to nesting lists is to remember that the nested list should relate to one specific list item. To reflect that in the code, the nested list is contained inside that list item. The code for the list above looks something like this:
<ol>
<li>Chapter One
<ol>
<li>Section One</li>
<li>Section Two </li>
<li>Section Three </li>
</ol>
</li>
<li>Chapter Two</li>
<li>Chapter Three </li>
</ol>
Note how the nested list starts after the <li> and the text of the containing list item (“Chapter One”); then ends before the </li> of the containing list item. Nested lists often form the basis for website navigation menus, as they are a good way to define the hierarchical structure of the website.
Theoretically you can nest as many lists as you like, although in practice it can become confusing to nest lists too deeply. For very large lists, you may be better off splitting the content up into several lists with headings instead, or even splitting it up into separate pages.
If you validate , option 1 comes up as an error in html 5, so option 2 is correct.
I prefer option two because it clearly shows the list item as the possessor of that nested list. I would always lean towards semantically sound HTML.
Have you thought about using the TAG "dt" instead of "ul" for nesting lists? It's inherit style and structure allow you to have a title per section and it automatically tabulates the content that goes inside.
<dl>
<dt>Coffee</dt>
<dd>Black hot drink</dd>
<dt>Milk</dt>
<dd>White cold drink</dd>
</dl>
VS
<ul>
<li>Choice A</li>
<li>Choice B
<ul>
<li>Sub 1</li>
<li>Sub 2</li>
</ul>
</li>
</ul>
What's not mentioned here is that option 1 allows you arbitrarily deep nesting of lists.
This shouldn't matter if you control the content/css, but if you're making a rich text editor it comes in handy.
For example, gmail, inbox, and evernote all allow creating lists like this:
With option 2 you cannot do that (you'll have an extra list item), with option 1, you can.