The reason to use role="list" and role="listitem"? - html

Are there any benefits of using the following code?
<ul role="list">
<li role="listitem"></li>
<li role="listitem"></li>
<li role="listitem"></li>
</ul>
Does the following code have the same meaning to assistive technologies?
<ul>
<li></li>
<li></li>
<li></li>
</ul>

The answer is yes, assistive technologies work well when correct semantic markup is used for structuring the document. If it is a simple static list then there is no need to mark them with the roles.
For example: Consider the role="listitem" whose baseConcept is defined as HTML li. And the baseConcept HTML li is almost identical to the role="listitem" definition except for the fact that it does not inherit any properties. More info
Thus, consider the following example:
<h3 id="header">Vegetables</h3>
<ul role="list" aria-labelledby="header" aria-owns="external_listitem">
<li role="listitem" aria-level="3">Carrot</li>
<li role="listitem" aria-level="3">Tomato</li>
<li role="listitem" aria-level="3">Lettuce</li>
</ul>
…
<div role="listitem" id="external_listitem">Asparagus</div>
Here the page author wants to use aria-level property for the li. Even though aria-labelledby and aria-owns can be applied to all elements of base markup, aria-level property requires that the element have some role. Since ARIA spec uses Web Ontology Language (OWL) to represent the roles in a class hierarchy. OWL describes these roles as classes along with their states and properties. So inorder to use a aria-level the element has to be defined some role as plain HTML li will not inherit any properties or limitations. Once you mark the role as listitem it requires that listitem be owned by an element with role="list". So you end up using both the roles.
On the other hand roles are also useful if semantic markup is also not used. For example:
<div role="list">
<div role="listitem">dog</div>
<div role="listitem">cat</div>
<div role="listitem">sparrow</div>
<div role="listitem">wolf!</div>
</div>
Here the screen reader software will indicate the ARIA list (made up of divs) as any other normal HTML list.

You question is a bit ambiguous, but if you are asking whether there's a benefit to adding role="listitem" to li items, which already have that as their default role, then the answer to that specific question is 'No.'
(Yes, the use of a li is preferred instead of a div. And role="listitem" is needed if you were using a div. But I don't think that's quite what you are asking.)
Check out Using ARIA by Steve Faulkner; he's put together a draft best-practices document on when and where to use the various ARIA roles in HTML5.
Generally speaking, you don't need to (and shouldn't) specify a role for elements if that role is the same as the element's default role. So since li elements have a default role of listitem, there's no reason to restate that.
There are some exceptions to this rule, and they're mostly concerned with new HTML5 elements that browsers have not yet correctly implemented default roles for. So, for example, since HTML5's article element isn't yet exposed by all browsers as having a role of article, then <article role='article'> is actually recommended in that and similar cases.

Related

How to apply keyboard accessibility when dropdown items are span tags?

I'm having a hard time with a custom dropdown menu I made. I'm trying to make it keyboard accessible, but I'm not having much luck with the listbox option. I'm following the instructions I find under WCAG pages, but I'm not having any luck. Here's one of the dropdowns on my page:
<ul class="custom__options dropdown story-selector" id="storyFilter">
<li class="custom__option selected" data-type="all" tabindex="0">All</li>
<li class="custom__option" data-type="news" tabindex="0">News and media</li>
<li class="custom__option" data-type="analysis" tabindex="0">Analysis</li>
<li class="custom__option" data-type="press" tabindex="0">Press releases</li>
</ul>
Here's a working Codepen to play with.
Your Codepen example uses WAI-ARIA attributes but have missing roles and expected keyboard behaviours.
In order to be accessible, all elements must have a minimum of a role and a name.
Your role sets a promise to the user of what kind of element the thing is and sets an expectation of how that thing will behave. Consider a role of "slider". In that single word, you've conveyed a lot of information to the user as to what that component is and how it would behave.
The name helps the user to understand the purpose of the element. The name of a volume slide would be "Volume".
Related attributes and properties are typically applied to one element, or are implied through coded relationships (using aria-labelledby for example). You would not do the following in HTML, for example:
<span alt="My image's text alternative">
<img src="image.png">
</span>
Yet I see things like this often for ARIA menubar implementations:
<li role="menuitem">
Home
</li>
There are options here, but with similar markup, the following would be more appropriate for the interactive menuitem:
<li role="none">
<button role="menuitem" aria-haspopup="true">Home</button>
</li>
It's best to use HTML elements with the closest semantics to what you are hoping to achieve, hence using the <button> element above. A lot of accessibility comes for free when you take this approach, since browsers add many (or all) of the behaviours expected by the user.
If you were to do the above using <div> and <span> elements, you need to enable appropriate keyboard focus and handle both mouse and keyboard events.
<div role="menuitem" aria-haspopup="true" tabindex="0">Home</div>
The W3C's WAI-ARIA Authoring Practices details approaches and expectations for common design patterns. For example, if you have several top-level items to choose from, you would want to use a Navigation Menubar.
Based on the Codepen example, what you are looking for is probably something like a Menu Button (or this alternative Menu Buttons tutorial), since you only requite a single dropdown menu rather than a whole menubar. This would produce something like the following:
<button aria-expanded="false" aria-haspopup="true">Story type</button>
<div role="menu">
<button role="menuitem">Home</button>
<button role="menuitem">All</button>
<button role="menuitem">News and media</button>
<button role="menuitem">Analysis</button>
<button role="menuitem">Press releases</button>
</div>

what's the difference between block__element__element and block__element-element in BEM

For example:
<div class="menu">
<div class="menu__item">
<div class="menu__item-title">
</div>
</div>
</div>
There's some solution like menu__title.
But if menu has its own title, then how to recognize menu's title and menu item's title?
The main difference is that block__element__element is not a valid BEM selector. The markup you showed in your question is the CORRECT way of naming your elements.
Create a block
If a section of code might be reused and it doesn't depend on other
page components being implemented.
Create an element
If a section of code can't be used separately without the parent
entity (the block).
The exception is elements that must be divided into smaller parts –
subelements – in order to simplify development. In the BEM
methodology, you can't create elements of elements. In a case like
this, instead of creating an element, you need to create a service
block.
More info in the official documentation: https://en.bem.info/methodology/quick-start/#should-i-create-a-block-or-an-element
If you want to have Menu title, the markup should look something like this:
<div class="menu">
<h2 class="menu__title">..</h2>
<div class="menu__item">
<div class="menu__item-title">
</div>
</div>
</div>
BEM gets a bit tricky when you have "children" of an element. But either use the menu__item-title naming convention or rethink your element, perhaps it can be separated and reused as a Block?

Proper ARIA handling of breadcrumb navigation

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.

Why does `ul` have ARIA role `menu` but `menuitem` is forbidden for `li`?

Just covered out some strage specs regarding ARIA roles. Why does ul have ARIA role menu but menuitem is forbidden for li?
I would like to describe a navigation bar using ul, li and HTML5's nav element in combination with the ARIA roles navigation, menu and menuitem.
<!DOCTYPE html>
<html>
<head><title>ARIA role bug?</title></head>
<body>
<nav role="navigation">
<ul role="menu">
<li role="menuitem">example.com</li>
</ul>
</nav>
</body>
</html>
W3's HTML5 validator nag me here:
Bad value menuitem for attribute role on element li.
Jukka is incorrect here. The W3C validator does not check against the WHATWG LS, instead it checks against the W3C HTML specification. The W3C HTML spec is the authoritative source for conformance checking requirements for the W3C Validator.
In regards to menuitem not being allowed as per the HTML spec, I believe this is a bug. And as such I have filed a bug. It is now in my bug queue to be resolved.
I have filed a bug against the W3C validator and wai-aria in HTML doc as well.
Until such times the validator is fixed, I suggest you use the roles as per the WAI-ARIA spec and ignore the validator.
addendum:
I looked back at history of ARIA integration into HTML could not find any reason why menuitem was not allowed, so believe it was an oversight. I fixed and resolved the bug I referenced above.
The following HTML markup is in the ARIA spec itself (the one you linked), and clearly shows a LI (nested, even) being used as a menuitem. Im guessing the particular markup you are using is forcing it to non-conform but thats just a hunch.
<ul role="menubar">
<!-- Rule 2A: "File" label via aria-labelledby -->
<li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span>
<ul role="menu">
<!-- Rule 2C: "New" label via Namefrom:contents -->
<li role="menuitem">New</li>
<li role="menuitem">Open…</li>
…
</ul>
</li>
…
</ul>
You shouldn't put role="menuitem" on an li element when it contains an a element since a menuitem widget cannot contain any intereactive elements (e.g links).
Take a look at the aria-practices examples for menu.
<li role="none">
<a role="menuitem">my menuitem here</a>
</li>
or
<li role="menuitem">my menuitem here</li>
The W3C validator, when applying HTML5 rules, actually checks against (some version of) the WHATWG “Living HTML standard”, which currently says, in clause 3.2.7 WAI-ARIA, about “li element whose parent is an ol or ul element” the following: “Role must be either listitem, menuitemcheckbox, menuitemradio, option, tab, or treeitem”.
This corresponds to the rules in the “Using WAI-ARIA in HTML” W3C draft, in 2.9 Recommendations Table.
I was using a similar DOM and changing an li submenu's role to presentation made the the page validate. Although perhaps semantically incorrect, in my situation it is inconsequential.

Is unordered list necessary on the following example?

As it's valid markup, I have done the following;
<div class="list">
Link 1
Link 2
</div>
My question is, does it have to be written as this;
<ul class="list">
<li>Login to Broker Site</li>
<li>Register</li>
</ul>
what are the + and - of doing one than the other? And are these both correct according to semantic web?
Thanks.
It totally depends on the greater context, but seeing as it seems to be a navigational sub-menu, a ul is indeed the most semantically correct element to use.
The clue is in the class name you chose.
As you see it as a list then use a list. This is a lot more semantic and is helpful for screen readers, which will then treat the contents as a list of links.