I am using aria-expanded in an attempt to make my tree list more accessible:
Consider the following:
<ul role="tree">
<li role="tree-item">
Link
<ul role="group">
<li role="tree-item">List item</li>
<li role="tree-item">List item</li>
</ul>
</li>
</ul>
Am I using aria-expanded in the correct place or should it be on the nested UL group?
aria-expanded should be on the control that opens the sub-tree, so the short answer is yes, it is in the right place assuming that the first anchor is the one that controls the opening.
However there are a few things to consider with the example given.
First of all you should never have a hyperlink that is empty. This should be a <button>.
"Buttons Do Things, Links point to URLs" is a great way to think of it, or "Buttons Do Things, Links go places".
Secondly from an ordering point of view your hyperlink "link.html" should be above the current hyperlink that I said to turn into a button. Otherwise the focus order is not logical so you might not pass WCAG 2.4.3.
Finally if you are using the first anchor (button) to expand and collapse the section you probably want to add aria-controls="idOfTheItem" to the button as well to ensure the relationship is correct (and add id="idOfTheItem" to the <ul> to correctly associate them).
Above all test it with a screen reader as there are certain behaviours expected of a tree view that may be more difficult as you aren't using a typical pattern for design (for example using arrow keys to navigate).
A typical pattern
Just so you are aware normally you would make the <li> itself open the sub tree. You might get some strange screen reader behaviour adding a button etc. into the tree-item as that is not quite expected.
You may be better building a custom widget here that has a list of links with buttons next to them to expand options / additional information.
Without seeing your use case it is very hard to tell.
If you go this route then you could utilise <details> and <summary> elements.
The following fiddle should give you an idea, notice how it all works without JavaScript (although you will need to polyfill it for IE as details / summary aren't supported in IE)
It would need some visually hidden text or aria-labels etc. to describe each of the <ul> if this is a complex tree but like I said just an idea for you to explore depending on your use case as the role="tree" doesn't seem to quite fit your pattern.
a{
float: left;
width: 100px;
}
<h3 id="descriptionID">An alternative</h3>
<ul aria-labelledby="descriptionID">
<li>
Link
<details>
<summary>Open</summary>
<ul>
<li>List item</li>
<li>List item</li>
</ul>
</details>
</li>
<li>
Link
<details>
<summary>Open</summary>
<ul>
<li>List item</li>
<li>List item</li>
</ul>
</details>
</li>
</ul>
Related
I have a two-sided mobile menu drawer that relies on a hidden checkbox for switching/toggling between its two sides.
There are two LABEL elements, one on each side of the menu drawer. Each LABEL, via its FOR attribute, references the ID of the hidden INPUT checkbox. Clicking a displayed LABEL thus checks the INPUT checkbox and causes the menu to switch sides (via CSS). A distillation of the HTML is:
<ul class=main-menu>
<li>
<input id=toggle-drawer type=checkbox title="hidden checkbox">
<label for=toggle-drawer>See Sub Menu</label>
<ul class=sub-menu>
<li>
<label for=toggle-drawer>See Main Menu</label>
</li>
<li>Sub-menu item 1</li>
<li>Sub-menu item 2</li>
<li>Sub-menu item 3</li>
</ul>
</li>
<li>Main Menu item 1</li>
<li>Main Menu item 2</li>
<li>Main Menu item 3</li>
</ul>
It is, in fact, perfectly valid HTML to have multiple labels that reference the same input item.
See https://www.w3.org/TR/html401/interact/forms.html#h-17.9.1 :
"More than one LABEL may be associated with the same control by
creating multiple references via the for attribute."
However, the WebAIM WAVE (Web Accessibility Evaluation Tool) browser extension flags the two labels as an error, stating,
"A form control should have at most one associated label element. If
more than one label element is associated to the control, assistive
technology may not read the appropriate label."
As a remedy, it goes on to state:
"If multiple form labels are necessary, use aria-labelledby."
aria-labelledby seems not to apply to my case, as it would be put on an INPUT item that is referenced by a DIV, etc.
Is there an ARIA or similar mark-up method I can use to satisfy this accessibility audit? I do not wish to alter my HTML structure.
Although it is perfectly valid HTML, having two labels will cause issues with NVDA and possibly other screen readers where it will only read one label.
This is why WAVE suggests you use aria-labelledby as that is designed to take multiple elements and can combine them (in the order you list them).
It is perfectly valid to use this on an input, also note that aria-labelledby will override any associated <label> elements using for="id"
One thing you could do is use the less often used aria-describedby to associate the second label and ensure that the reading order is correct.
In the example below it would read 'See Main Menu, See Sub Menu' as it will read the <label for="toggle-drawer"> first and then use the aria-describedby="toggle-drawer-label" to add additional information.
The only down side is that it may read the input information in between the <label> and the describedby label.
<ul class=main-menu>
<li>
<input id="toggle-drawer" aria-describedby="toggle-drawer-label" type=checkbox title="hidden checkbox">
<label id="toggle-drawer-label">See Sub Menu</label>
<ul class=sub-menu>
<li>
<label for="toggle-drawer">See Main Menu</label>
</li>
<li>Sub-menu item 1</li>
<li>Sub-menu item 2</li>
<li>Sub-menu item 3</li>
</ul>
</li>
<li>Main Menu item 1</li>
<li>Main Menu item 2</li>
<li>Main Menu item 3</li>
</ul>
The recommended way
I would recommend simply using aria-labelledby="label1 label2" as that is the accepted method and will result in the most consistent results, obviously it means you need to add id attributes to both labels so that is the trade off.
Note that using aria-labelledby="label1 label2" and associating the fields with for="toggle-drawer" on both labels has the added benefit of correctly linking the labels so that you can click on either label and it will focus the <input>.
This question already has answers here:
Does the <li> tag in HTML have an ending tag?
(4 answers)
Closed 4 years ago.
I have been working on a dropdown menu that now works. Just one strange thing is happening that I can't explain/don't understand. Here is a relevant piece of the code:
<ul>
<li><p>Music Theory 1 </p></li>
<li><p>< </p>Music Alphabet
<ul>
<li><a id="l0" class="lesnitem" href="#">Piano Keyboard</a></li>
<li><a id="l1" class="lesnitem" href="#">Note Types</a></li>
...
Notice the absence of the closing "li" tag on the second "li"
If I put it in, the behavior changes drastically. the inner "ul" is no longer hidden and it is laid out differently (across instead of down), so the absence is affecting the CSS, but I don't see it.
I guess I'm Ok with leaving it out, but it grates on me.
Could this have something to do with the inner "a" tag?
Can anyone help me understand this?
The end tag for a <li> is optional. If you don't put it in explicitly it will be automatically inserted before the next <li> or </ul> (or </ol>).
If you insert it manually before the <ul> then you are moving the nested <ul> so it is no longer inside the <li>.
Instead, you try to create the <ul> as a child element of another <ul> which is forbidden in HTML.
You've got a nested list -- that is, a list inside of another list. The way you do this is that you create a new list inside of a list item of the parent list. This is commonly used for "sub menus" in CSS drop downs.
Example:
<ul>
<li>First Item</li>
<li>Second Item</li>
<li>Third item with a sub list
<ul>
<li>Sub item 1</li>
<li>Sub item 2</li>
</ul>
</li>
</ul>
What is commonly done with CSS menus is that the sub list is "hidden" using CSS (eg. by applying display: none) and then when you hover over the containing list item, it is displayed.
Here's an example of a very rudimentarily styled menu using this structure:
#submenu ul {
display: none;
}
#submenu:hover ul {
display: block;
}
ul li {
cursor: pointer;
}
<ul>
<li>First Item</li>
<li>Second Item</li>
<li id="submenu">Submenu (hover to show)
<ul>
<li>Submenu item 1</li>
<li>Submenu item 2</li>
</ul>
</li>
</ul>
Note, of course, that </li> is an optional tag. You can create a list like this:
<ul>
<li>First Item
<li>Second Item
</ul>
What your browser will do is guess at where the closing tag should be and implicitly insert it there. In this case, it is inserting the closing tag after the word "item" in both of those list items.
It is, of course, considered good practice to explicitly close all of your tags.
To specifically answer your questions:
Could this have something to do with the inner "a" tag?
No. This has nothing to do with your "a" tags. As mentioned </li> is technically optional.
But in the case of the code you posted, you're using a nested list setup, not relying on the optional-ness of the closing tag. I can say this assertively because if you had actually closed that li tag that has the sub-list in it, you'd have a ul as a child of a ul, which is not allowed.
Can anyone help me understand this?
Hopefully the above did so. But to summarize:
The </li> tag is technically optional. You don't have to use it, but it's good practice to always close your HTML tags.
The presence of the anchor tags inside of the list items is irrelevant.
In the specific example you posted, you have a nested list or sub-list; this is done by putting a new list inside of an <li> tag.
What can be done to improve the accessibility of a breadcrumb menu similar to:
<ul class="breadcrumbs" aria-label="breadcrumb navigation" role="navigation">
<li>Home</li>
<li>News</li>
<li class="unavailable">#Model.Title</li>
</ul>
Given in this example Home is the site root, News is the first child, and the unavailable class is the current item the /news/article item.
Is there anything that could be done to improve this such as using rel attributes or aria-level attributes?
I would avoid the use of aria-level and use a <ol> element instead. It is best to avoid using aria attributes wherever a native alternative exists. Using aria adds an extra layer of complexity. Simple HTML is far better and already has semantics that are surfaced to AT. This is the first rule of ARIA.
Borrowing from the WAI-ARIA-Practices document, breadcrumbs would look like something like this:
<nav aria-label="Breadcrumb" class="breadcrumb">
<ol>
<li>
<a href="../../">
WAI-ARIA Authoring Practices 1.1
</a>
</li>
<li>
<a href="../../#aria_ex">
Design Patterns
</a>
</li>
<li>
<a href="../../#breadcrumb">
Breadcrumb Pattern
</a>
</li>
<li>
<a href="./index.html" aria-current="page">
Breadcrumb Example
</a>
</li>
</ol>
</nav>
Some notes:
Wrapping the breadcrumbs in a <nav> element lets screen reader users quickly find and jump to the breadcrumbs.
Using <ol> element surfaces an order to screen reader users.
The <ol> should be a child of the <nav>. Some implementations apply role="nav" to the <ol> itself. This is wrong and will override the default <ol> semantics.
aria-current informs screen reader users that this is the current page. If the last breadcrumb for the current page is not a link, the aria-current attribute is optional.
Going from using a screen reader and reading this blog post, the rel attributes won't make a difference to A.T. As for using aria-level, it works if you put it on the anchor tags. I'd also advise wrapping the list in a nav element, for semantic purposes and to save the need of putting a navigation role on the list when you don't need to.
I wound up with this markup for what I think is a not-too-bad breadcrumb. Hide the bullets using CSS (I didn't stop to do that I'm afraid) and I'd say its good.
<nav aria-label="breadcrumb" role="navigation">
<ul>
<li>Home</li>
<li>News</li>
</ul>
</nav>
Hope this helps!
You can use like below
<nav role="navigation" aria-label="breadcrumbs">
<p id="breadcrumblabel">You are here:</p>
<ol id="breadcrumb" aria-labelledby="breadcrumblabel">
<li>Home</li>
<li>Menu1</li>
<li>Menu2</li>
</ol>
</nav>
When searching the Web for a thorough solution on accessible breadcrumbs, #Craig Brett's solution seemed good at first sight. But after reading several sources, aria-level seems to be misused there (besides a W3C Validation problem, see my comment above).
Therefor I like to propose this approach:
<nav aria-labelledby="bc-title" role="navigation">
<h6 id="bc-title" class="vis-off">You are here:</h6>
<a href="~/" aria-labelledby="bc-level-1">
<span id="bc-level-1" class="vis-off">Homepage Website-Title </span>Home
</a>
<a href="~/news" aria-labelledby="bc-level-2">
<span id="bc-level-2" class="vis-off">Level 2: News </span>News
</a>
#Model.Title
</nav>
In this solution we have an HTML5 sectioning element (nav), which should have a heading, and *tada* there it is. Class vis-off signifies an element that is just available to screen readers. With aria-labelledby I'm telling the screen reader to read that headline.
In contrast to Chris' solution, either the <ul> or aria-level is gone.
I'd so or so go for an <ol> if necessary, because the items are in order. Better leaving it out, otherwise it gets very verbose in many screen readers on every page ("List item 1…").
aria-level seems to be misused in the solution above in my understanding. It must be child of a role attribute like f.e. role="list" and that role just signifies not structurally marked-up non-interactive lists.
Maybe a role treeitem might be more appropriate. IMHO it's overkill.
PS: I'm not using BEM notation here to shorten the ids and classes for readability.
Recently I've been implementing ARIA into a web application and I found this question to be quite helpful in the improving the navigation parts.
After implementing this in all modules, I discovered this HTML validation error:
Attribute aria-selected not allowed on element a at this point.
Looking at the ARIA specification, I see that aria-selected is only used in roles gridcell, option, row, and tab. In my case, the role of the link is menuitem.
This is a representative sample of the HTML code:
<nav role=navigation>
<ul role=menubar>
<li role=presentation><a href='page1.php' role=menuitem>Page 1</a></li>
<li role=presentation><a href='page2.php' role=menuitem>Page 2</a></li>
<li role=presentation><a href='page3.php' role=menuitem aria-selected=true>Page 3</a></li>
<li role=presentation><a href='page4.php' role=menuitem>Page 4</a></li>
</ul>
</nav>
As you can see, this is taken on "page 3".
What is the correct ARIA role to use here?
you may also use aria-current="page" for describing current displayed page among navigation items.
I believe that aria-selected is for 'widgets' that are one-tab stop, like a set of tabs that you then arrow around to select. The selected aspect is about which one is in focus, not which page you are on.
I would check out this as a well tested example:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Horizontal%20(Internal%20Content)/demo.htm
From: http://whatsock.com/tsg/
For showing the current page I would probably use a more traditional method: Make it not a link. E.g:
<li><a href='page2.php'>Page 2</a></li>
<li><strong>Page 3</strong></li>
This also prevents people from clicking on the same-page link by accident (which I see quite often in usability testing). You can apply the same CSS to nav ul a and nav ul strong and then override the styling for the strong.
Short answer: you can use aria-current="page" or aria-current="location" to indicate the current link in a list of links.
Your pagination component could be improved in terms of accessibility (you can see this as a variation of the similar breadcrumbs pattern):
<nav aria-label="pagination">
<ol>
<li>
Page 1
</li>
<li>
Page 2
</li>
<li>
Page 3
</li>
<li>
Page 4
</li>
</ol>
</nav>
A few notes:
Use <nav> to automatically use the navigation landmark (<nav> is equivalent to <div role="navigation"> but shorter and more elegant)
Use aria-label to provide a meaningful name to the <nav> (most likely, you have more <nav> elements on the page and you should label each one accordingly).
Use to make the set of links structured. This can also help screen reader users as it will be announced as "pagination, navigation (next) list, 4 items, helping users understand how many pages there are.
Use aria-current="location"oraria-current="page"` current page of the list (this is most likely shown in a different style as the other pages, but we need to mark it for screen reader users).
Is it semantically correct to markup a ul in HTML with another embedded ul that has only one single list item?
For example, I have a ul with several lis, and one of those lis has an embedded ul with a single li:
<ul>
<li>Example LI 1
<ul>
<li>Example LI 1a</li>
</ul>
</li>
<li>Example LI 2</li>
<li>Example LI 3</li>
</ul>
Absolutely. A list is not defined by quantity. It's defined by semantics. So a list can consist of only one element if only one item applies to the list's purpose. For example, I have only crashed one computer today so that list would be only one element long.
Yes, it is semantically correct to have a list with a single item if used correctly, even if it does feel a little strange (it’s not really a list if there is only one item because by definition, a list is, well, a list of items, otherwise it would just be an item).
In the example you provided, the items were placeholders and had no meaning, so it is hard to tell if it applies. Whether it is correct or not depends on why you are putting it in a sub-item. It is perfectly reasonable to have a single-item sub-list if it is indeed a list item, especially if there are other sub-lists with multiple items. In that case, the meaning is clear. For example, the following is fine:
<h1>Auto Insurance Customers</h1>
<ul>
<li>
<strong>#1234</strong>
<ul>
<li>2003 Ford Focus</li>
<li>1998 Ford Escort</li>
<ul>
</li>
<li>
<strong>#2468</strong>
<ul>
<li>1999 Lamborghini Diablo VT Roadster</li>
</ul>
</li>
…
</ul>
There is nothing wrong with this example because it is perfectly reasonable for a customer to have a single car while others may have more.
On the other hand, if the reason that you are making the single-item sub-list is simply to create an indent to offset and highlight part of a list item, then it is incorrect.
For example, say you have a list of paragraphs of text. In one of the paragraphs, you have a passage that needs some sort of attention and you want to indent and offset it. While putting it in a list would work, it is incorrect because you are mixing style with structure.
The correct way to accomplish this would be to wrap the section in another tag (like <blockquote>, styled <div>, etc.) and leave it in the regular flow of that list item. In the following example, there is a part of one of the list items that needs to be highlighted. Putting it in a (single-item) list is the wrong way to do it:
<h1>Blog posts or something…</h1>
<ul>
<li>
<strong>Foo</strong>
<p>Some long paragraph about Foos, what they do, how they work, etc.</p>
<p>More information about Foos and where they originated.</p>
<p>Instructions on care and feeding of Foos.</p>
</li>
<li>
<strong>Bar</strong>
<p>Detailed description of local watering holes for lawyers.</p>
<p>Anecdotes about experiences of drinking & lawyering.</p>
<!-- This section is to be highlighted and offset to draw attention to it from the rest of this list item. -->
<ul>
<li>
<p>Highlighted account of the subsequent problems and what happened that one strange night.</p>
</li>
</ul>
<p>Summary of what to not do when out drinking with lawyers.</p>
</li>
<li>
<strong>Baaz Luhrmann</strong>
<p>A bunch of stuff about a brass-skinned movie director who made a widely-panned film adaptation of a Shakespeare play who turns to stone and traps your sword when he dies.
</li>
</ul>
Instead, you should use the correct tag for this purpose. Not only is it semantically and structurally correct, it is also clearer and even reduces the size of the page a little:
<style…>
p.highlight {
margin : 20px 50px;
width : 150px;
}
</style>
…
<li>
<strong>Bar</strong>
<p>Detailed description of local watering holes for lawyers.</p>
<p>Anecdotes about experiences of drinking and lawyering.</p>
<!-- This section is to be highlighted and offset to draw attention to it from the rest of this list item. -->
<p class="highlight">
Highlighted account of the subsequent problems and what happened that one strange night.
</p>
<p>Summary of what to not do when out drinking with lawyers.</p>
</li>
According to dictionary.com, a list is a meaningfully grouped series of items and a series is a group of similar or related items. (Results are similar at oxforddictionaries.com and thefreedictionary.com.) Anything that contains only one item can't contain meaningful grouping or a similarity or relatedness between its contents. Thus, for a one-item list, the semantics of the markup don't match the semantics of the content.
A single-item list also just doesn't seem to fit with what people mean when they say "list".
(On that note, contemporary dictionaries are more focused on recording common usage than proper usage (which is why "bling" is in the OED).)
Additionally, even if it wasn't technically wrong, there just doesn't seem to be much editorial value in marking up such a simple statement as a list instead of a paragraph. It seems to me that the first of the three following examples would be the easiest for the user to parse and comprehend.
<p>XYZ is the only computer that crashed.</p>
<p>
The computer that crashed:
<ul><li>XYZ</li></ul>
<p>
<ul>
<li>
The computer that crashed:
<ul><li>XYZ</li></ul>
</li>
<ul>