I am writing a menu with material design lite and I need a separator between two categories of item in this menu.
I recreated a simpler example of what I am doing here:
http://codepen.io/anon/pen/jbJXQP
In this example I would like to have something to delimit the two different categories. In the example "Trip planner" and "Layers" are some map related widget whereas "Help" and "Send feedback" are more info related.
Specificaly here:
<li class="mdl-menu__item"
<i class="material-icons" >layers</i>
Layers</li>
<li class="mdl-menu__item"
onClick="javascript:webapp.infoWidgets['otp-infoWidget-0'].show();" >
Help</li>
I am fairly new to web development (a few month), so I don't really have an idea of what is a good solution to do that.
For the separator it need to be something noticeable but not obtrusive to the user. I was thinking at just a straight black line in the middle but I don't know if this is possible.
An additional MDL class (I'm not familiar with MDL but sure there must be one, if not, just create one) for the first each special type of menu item which could then have a top border would be most logical.
So, let's assume that the first of each informational list item has a class of info:
Then we can do.
.mdl-menu__item.info {
border-top:1px solid lightgrey;
}
Codepen Demo
There are a variety of techniques for selecting which list item to apply the border to.
You can set a separate line, like you said. The <hr> tag defines a thematic break in an HTML page (e.g. a shift of topic). try this:
HTML
<li class="mdl-menu__item">
<i class="material-icons" >layers</i>
Layers</li>
<li><hr></li>
<li class="mdl-menu__item"
onClick="javascript:webapp.infoWidgets['otp-infoWidget-0'].show();" >
Help</li>
DEMO HERE
Note: You can style by CSS the <hr> - https://css-tricks.com/examples/hrs/
Related
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 is best practice to enhance the semantic accessibility of a website <nav> landmark with a nested <ul> list for screen reader users? (aria-label and list level are currently not pronounced by all screen readers)
I tested with Voiceover on iOS 9, Talkback on Android 5 and NVDA 2016-1 on Win10 (in Firefox). I used (mostly) default settings in the screen reader applications.
I thought the following list should be optimal prepared for screen reader users:
Demo code 1
<nav>
<ul aria-label="product navigation">
<li>Product A
<ul aria-label="sub menu Product A">
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
<li>Product B
<ul aria-label="sub menu Product B">
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
</ul>
</nav>
Expected result: Screen reader say something like this:
Beginning of navigation landmark
Beginning list level 1 "product navigation" with two elements
"Product A" link
Beginning list level 2 "sub menu Product A" with two elements
"Specifications" link
"Accessories" link
End of list level 2 "sub menu Product A"
"Product B" link
Beginning list level 2 "sub menu Product B" with two elements
"Specifications" link
"Accessories" link
End of list level 2 "sub menu Product B"
End of list level 1 "product navigation"
End navigation landmark
I also expected detailed info when touching sub menu items on table/phone, e.g.
"Specifications" link level 2 list "sub menu Product B"
But unfortunately this is not working in Voiceover, Talkback or NVDA.
The list labels and the list level are both not spoken.
When using a screen reader and jumping from list to list (like using l key or the list rotator/navigation) you have no idea, what list you're in. In case the elements of the children lists have similar links (like in the demo code) this problem seems for me to be even worse.
I also think it is very confusing (at least for me) to hear "beginning of list" and "end of list" multiple times with no hint, what kind of list is beginning or ending - especially when you are on a mobile or tablet and discovering the display content randomly with your finger.
I made a test series and tried different variations, e.g. I added explicit role="list" and "listitem". I also added aria-level="1" and "2" to the listitems as shown in this example - without success. Are list levels supported by any screen reader software?
One of my findings: At least Voiceover (on iOS) is telling the aria-label of the <ul> elements, but only when defining explicit role="list" like in the following code. But this also only works when the <nav> container is not used - Voiceover (on iOS) is ignoring the fact that there is a list completely when using <ul> within <nav>. So when using a <nav> landmark the list is gone in Voiceover and also not accessible via the rotator/list navigator.
Demo code 2
<ul role="list" aria-label="product navigation">
<li role="listitem">Product A
<ul role="list" aria-label="sub menu Product A">
<li role="listitem">Specifications</li>
<li role="listitem">Accessories</li>
</ul>
</li>
<li role="listitem">Product B
<ul role="list" aria-label="sub menu Product B">
<li role="listitem">Specifications</li>
<li role="listitem">Accessories</li>
</ul>
</li>
</ul>
I think when using a nested list it is important to tell the blind user the nesting level and the list label (at least for the sub level lists, so you know that it is a sub level list) - is there currently a way to solve this?
In case it is not possible, I'd say that it is not a good advice to use nested lists in <nav> for navigation... or nested lists at all?
Edit 1: Updated demo code
Edit 2: More findings
In this answer to another question is made clear, that there are no fixed rules about how screen reader should handle/read aria-label.
<nav> and <ul> are grouping elements - according to the answer the labels are more likely to be read - unfortunately not in my tests when there are nested lists in a navigation landmark.
I also found a page listing some screen reader test results for unordered nested lists - at the beginning they state what "should be announced", so it's optional. :/ The Voiceover results of this page are not valid for Voiceover on iOS 9, the nesting level is not announced in my test.
On the NVDA GitHub issue tracker there are also multiple discussions about the way to implement support for aria-label. And I also found this long but really interessting article about the ridiculous complicated world of aria-label.
Anyway, so now I know I can't expect that nesting levels or aria-labels are announced by default. I'm still wondering if there is a way to enhance accessibility for blind users when the screen reader software doesn't support this functionality...
I know there are some people on Stack Overflow who use screenreader software everyday by necessity, while I only use it for testing. So if any of them contradict my answer, go with their suggestions.
But to me, all the additional ARIA you want to add would just make the menu longer to listen to. The content itself is what makes it clear these are submenus (when there is real content and not example content), so there is no need for aria-label attributes. It's confusing for you, but remember that you only use a screenreader on the sites you build, not every site. Being consistent with the rest of the web's navigation helps people understand your site more quickly.
Also, ARIA roles as in your second example are intended to change the way HTML elements are reported to screenreaders (e.g. A div which behaves like a button). Since you are adding matching roles, you are increasing your workload without adding usability for anyone.
So using semantically correct HTML is all you need to do in this case to make a perfectly accessibile menu. There is no need to add ARIA until you are building unusual widgets, not standard links and text.
You won't help users by giving them the nesting level number, or ask them to remember the menu section they are into.
If you really want to help the users, tell them where they are everywhere.
See https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html
<nav>
<h2>Product navigation</h2>
<ul>
<li>Product A
<ul>
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
<li>Product B
<ul>
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
</ul>
</nav>
You can use the title attribute conjointly with the aria-label attribute in order to be compatible with the majority of screenreaders and be accessible for non-screenreaders users.
The reason you're not getting the labels read out is because you have them as arial-label instead of aria-label in your code. If you change this to aria-label they will be read as the screenreader is going through the document. If you are tabbing through the links, however, the aria label of the list element will not be read as it's not a focusable element. The screenreader should handle the nesting properly without the need for additional labelling - I've tested this in NVDA and it works as expected - it will announce 'list with two items' when I tab from 'Product A' into "specifications'. Hope this helps.
Trying to add heart/like buttons on each individual link in a list in Wordpress.
You can see it here : http://theroadmap.co/strategy/.
I want the likes/fav be linked to the items, and not to the individual post (I have over 20 links in one post, split into 5 sections).
I used shortcodes of several plugins (ZillaLikes) and they always mess up the CSS + are linked to the individual post and not the item themselves.
You can see my HTML code of one of the sections of a post below:
<ol class="rectangle-list">
<li class="tooltip" title="What does a startup CEO actually do?"><a href="LINK TO ARTICLE </a></li>
<p>What does a startup CEO actually do?</p>
<li class="tooltip" title="How to find your competitive advantage">Be the Company Customers Can't Live Without</li>
<p>How to find your competitive advantage</p>
</ol>
Thanks!
Dan.
I would suggest something simple like Font-Awesome. It's very easy to add to your site where-ever you want it and control size, colour etc via CSS.
Font-Awesome
For example a solid heart icon would be added like
<i class="fa fa-heart"></i>
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).
I'm currently trying to come up with a good and accessible way to format a status indicator which should be rendered within a set of wizard-like pages on a website. The website should provide a multipage form with a status indicator on top of it as demonstrated in the wireframe below:
Given the new progress-tag in HTML my first thought was to do something like this:
<progress value="2" max="3">
<ul>
<li>Beginning</li>
<li class="now">Right now</li>
<li>End</li>
</ul>
</progress>
... but since <progress> only accepts phrasing content using a list is not really an option. So right now I would probably go with something like this, integratinng the ARIA progressbar-role:
<ul aria-role="progressbar" aria-valuenow="2" aria-valuemin="1" aria-valuemax="3" aria-describedby="state2" aria-valuetext="Right now">
<li id="state1">Beginning</li>
<li id="state2" class="now">Right now</li>
<li id="state3">End</li>
</ul>
But again, I'm not really sure if the progressbar role can be applied in such a way to a list.
Another problem is, that <progress> is rendered as progress bar in Opera, for instance, so >progress> itself is probably not really a viable solution altogether :-(
Can anyone perhaps recommend an accessible status bar that does not only rely on using a single image?
Current solution
For now I will go with following markup:
<section class="progress">
<h1 class="supportive">Your current progress</h1>
<ol>
<li><span class="supportive">Completed step:</span> Login</li>
<li class="now"><span class="supportive">Current step:</span> Right now</li>
<li><span class="supportive">Future step:</span> End</li>
</ol>
</section>
All elements of the class "supportive" will be positioned off-screen. IMO this way we should have a nice compromise of semantic markup (the state succession is in my opinion really an ordered list ;-)) and accessibility thanks to the additional header and status text for each step.
According to whatwg, you're not supposed to assign progressbar role to <ul> elements.
I'd just ditch <ul> and describe progress using (surprise) phrasing content:
<section role="status">
<h2>Task Progress</h2>
<p>You're now at <progress value=2 max=3>"Right now" step</progress>.
</section>
Update: You're right, progress doesn't suit here, it's more like an interactive form widget. I should've checked first, before taking it from your first example. But anyway, the point is there's no need to use a list (even more so, unordered list), when you can just describe what's going on in plain text. In the case that the list of past and future steps is necessary, I'd just add two more paragraphs, one before the status (‘You've completed the "Beginning" step’), and one after (‘Next step will be the "End" step’).
However, I admit that this isn't a complete answer to your question.
Also, I'd say some aria attributes look redundant to me. For example, aria-valuetext perhaps would make more sense in the context of interactive widget, when there's no other human-friendly description of its state. Though I may be wrong here.