I did a page and did a check on it using a software called WebKing and it tells me I have duplicate anchors??
<ul >
<li>About The Code</li>
<li>Link 2 is boring</li>
<li>3rd line in</li>
<li>Contact Manny</li>
<h3><a name="toc1" id="toc1">About the code</a></h3>
<h3><a name="toc2" id="toc2">Link 2 test</a></h3>
<h3><a name="toc3" id="toc3">3rd test</a></h3>
<h3><a name="toc4" id="toc4">Contact Manny</a></h3>
</ul>
So what am I doing wrong?? Do I change the id to something else?
This looks like it is just some bad heuristics in the analysis software you are using. There isn't anything technically wrong with that code.
That said, a modern approach (i.e. not pandering to Netscape 4) would be to say:
<h3 id="toc1">About the code</h3>
… and I suspect this would also avoid triggering the aforementioned bad heuristic.
You should probably have better ids too. id="about" — URLs that inform readers where they go are generally better than URLs that don't so /mypage/#about beats /mypage/#toc1
On the subject of bad style, the title attribute is there to provide advisory information about an element. It should contain helpful extra information. Your example has it duplicating the main text of the links. At best this will just be some extra bytes to download. At worst, you can expect some screen reader users to have to listen to the destination of every link being repeated.
The name and id attribute share the same namespace so they need to be different.
http://www.w3.org/TR/html401/struct/links.html#h-12.2.3
If you are writing valid XHTML try not to use the name tag.
http://www.w3.org/TR/xhtml1/
Section 4.10. The elements with 'id' and 'name' attributes
Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML.
Also you have some h3's that aren't inside li's but are inside of a ul.
Related
I'm updating a website, doing an iterative improvement on the accessibility.
I'm using multiple tools to get the pages better: FireFox's accessibility tree viewer; Chrome's lighthouse checker; the "wave" accessibility tool, and I'm trying tenon.io
(sadly, I don't have access to a decent screen reader - nvda is too fast for me to hear, orca seems to read the current line, and I don't have access to JAWS)
So here's what I have:
I have a navigation structure like this:
<nav aria-label="Main navigation">
<section class="desktop-navigation" aria-label="Main Menu">
<ul aria-label="Menu items">
<li>About Example</li>
<li>Documentation</li>
<li>Pricing</li>
<li>Status</li>
<li>Contact us</li>
</ul>
</section>
<section class="main-nav-wrapper" aria-label="Header logos">
<a href="/"><img src="/images/logo_example.svg?v=488a8c6971df396baaa401bb073b4a6b"
class="header-logo" alt="The Example logo" aria-label="Example Logo"/></a>
<div class="site-logos-right" aria-label="Corporate Logos">
<a class="external-link" href="https://www.example.com/" rel="external"><img
src="/images/logo_company.svg?v=98693292e027eca1f27cfc89b68a77d2" class="company-logo"
aria-label="The Company logo" alt="Official logo for Company"/></a>
<a class="external-link" href="https://example.com/department"
rel="external"><img src="/images/logo_department.svg?v=ff0114bb2ebf7eff339341f9554220d0"
class="edina-logo" alt="Official Department logo" aria-label="department logo" /></a>
</div>
</section>
</nav>
..... and this is 100% according the lighthouse, but tenon.io is reporting an issue (multiple times) and I don't understand why:
This element uses multiple strategies to create labels
This element has more than one possible label. The manner in which the
accessible name is calculated for controls uses an algorithm in which
only one of these labelling approaches will win. This means one of
these labels will be ignored by assistive technologies. There should
be only one label provided and the others should be removed.
Examples of items identified:
<nav role="navigation" aria-label="Main navigation">
<section class="desktop-navigation" aria-label="Main Menu">
<ul aria-label="Menu items">
<li><a href="/" aria-label="Return to the home page to read about
(I notice that the W3C site does not label the uls - but then they show as un-named elements in firefox)
I definitely want to label landmarks & sections.... so what's it actually complaing about?
<li>Pricing</li>
.... this is an example of where I want to have a more descriptive label for the element - when scanning the accessibility tree, just having the bare link-text doesn't (to me) read as well as having some context: as a sighted user, I know my eyes have flicked over much of the page, and seen additional text, so subconsciously have some context for the menu items.
My question(s)
How is the accessibility label computed?
Why can't I have a more descriptive label on a link? (lighthouse complains if the alt text doesn't contain the link text... but is happy if it's more than the link text) - or is this tenon.io being over-picky?
The accessible name computation is how accessibility labels are computed.
You're using aria-label too much, and the result may be difficult to listen to or outright confusing for human visitors using assistive technologies.
The first rule of ARIA is don't use ARIA unless you really have to.
It is appropriate to use aria-label on the <nav> and <section> elements. Keep that.
I can't think of any good reason to use aria-label on a <ul> element. I'd recommend removing that.
Using aria-label on anchor elements is normally unnecessary and should be approached with caution. Unless you have a really good reason, you probably shouldn't be presenting different content to visitors using assistive technology.
I would also recommend removing aria-label from your images. This is exactly what alt text is for.
If you really want to use aria-label on anchor elements, WCAG has some guidance:
Per the Accessible Name and Description Computation and the HTML to Platform Accessibility APIs Implementation Guide, the aria-label text will override the text supplied within the link. As such the text supplied will be used instead of the link text by AT. Due to this it is recommended to start the text used in aria-label with the text used within the link. This will allow consistent communication between users.
https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA8.html#description
Don't give up on NVDA just yet. I also found the default speech settings too fast and difficult to understand. You just need to adjust the settings. The voice can also be changed out for better ones. It takes a bit of work to configure, but in my opinion NVDA is the best free screen reader available today. VoiceOver is also very nice if you have access to Mac/iOS products.
Say I have the following DOM tree:
<div class="box">
<ul class="gallery">
<li id="1">text</li>
<li id="2">text</li>
<li id="3">text</li>
<li id="4">text</li>
<li id="5">text</li>
<li id="6">text</li>
<li id="7">text</li>
<li id="8">text</li>
<li id="9">text</li>
</ul>
<div id="random"></div>
<ul class="gallery">
<li id="10">text</li>
<li id="11">text</li>
<li id="12">text</li>
<li id="13">text</li>
<li id="14">text</li>
<li id="15">text</li>
<li id="16">text</li>
<li id="17">text</li>
<li id="18">text</li>
<li id="19">text</li>
<li id="20">text</li>
</ul>
</div>
I want to create a CSS selector that will pick every 6th <li> tag under the div with the class "box". But I need the selector to take into account the entire <li> tags in the page and not to count them per <ul> tag. So in the end, the selector should pick the <li> with IDs 6,12,18. Currently I was only able to create a selector that picks IDs 6 & 15 when I used:
div.box li:nth-of-type(6n)
Notice 1: the IDs numbers are only added for reference. In reality the <li> tags don't have a class or an ID.
Notice 2: the number of <li> tags in each <ul> tag varies from site section to site section. Sometimes there can be even a 3rd and a 4th </ul> with more <li> tags.
Notice 3: I don't have control over the hard-coded HTML, which means I cannot unify tags, add IDs or CSS classes, etc. The selector will be called from an external JS file. While I can edit the DOM with jQuery after the page loads, I prefer to avoid such a solution to make the selector easier to handle.
Thanks
Generally Agree Impossible, except...
I basically agree with Sych and Fabrício that it is not currently possible to do as a pure CSS solution. However, there are always some exceptions, depending on actual html structure.
In your case, there may be an exception, but it does depend on the full constraints of your situation.
When Would it Be Possible?
Based off your given code, if these two constraints are true, then you can still get what you want via CSS:
All ul items that are direct children of .box are of class .gallery.
All gallery groups (except perhaps the very last one) consist of exactly nine li elements (both groups in your example do, but I don't know if that was coincidence or how you are actually setting up your code).
If the above two factors in your html are true, then this code gets what you want (using color to show selection here):
ul.gallery:nth-of-type(2n+1) li:nth-of-type(6n) {
color: red;
}
ul.gallery:nth-of-type(2n+2) li:nth-of-type(6n+3) {
color: red;
}
You can see it works on the code you gave in this fiddle, then you can see it continues to work given an expansion of the html as this fiddle shows, even if the final list is short of nine as both this fiddle and this fiddle shows, but it will fail if the .gallery varies in length at some midpoint of the sequence, as seen in this fiddle (notice how the last two selected texts are not 6 apart from each other because the second to last .gallery has only 7 items).
The Overarching Principle
So in general, if your dynamic html is output in some type of a regular pattern as demonstrated here, then it can open up the possibility of a pure css solution along the lines of that given. It is when the dynamic generation is also fully random (so in your case if either #1 or #2 condition above is not guaranteed true) that a pure css solution is impossible.
CSS does not provide such scope, it only provides traversing "deeper in to the DOM" tree. It does not even have a parent element selector.
If you are in jQuery environment, you can write your own selector, call it, say, ":nth-from-top(n)" that will work using jQuery's DOM traversing functions.
Note, that this type of selector will be much slower, because it cannot take advantage of the performance boost provided by the native DOM methods.
nth-child and nth-of-type match based in the element's position relative to its siblings only.
As far as I know there's currently no CSS-only solution for that unless all lis had the same parent. You will have to add a class to every 6th element or use some JavaScript.
So, constraining the answer to CSS selectors only without altering the markup and without hardcoding the nth start indexes: impossible. I'd like to be proven wrong though.
Looking by the bright side, adding a class will provide better selector performance. nth-child is already considered inefficient, now if what you want would be possible it'd mean that browsers would be forced to recursively evaluate selectors and count matches each time the DOM is updated. Though this would be terrible performance wise, I believe it'd still be possible to implement through new "scoped" nth selectors a la CSS Counters. Just food for thought.
I'm doing frontend design and working with a couple of backend programmers right now--a process that is new to me.
We are trying to set up a system for comments complete with a hierarchy for replies. I thought the easiest way to style the different levels would be using nth child and nested lists, but I can't quite wrap my head around how to do that. Ideas?
As Ian has said, nth-child only works at one level at a time. If you wish to understand nth-child better, here are a few resources:
http://reference.sitepoint.com/css/pseudoclass-nthchild
http://css-tricks.com/how-nth-child-works/
http://www.impressivewebs.com/css3-pseudo-class-expressions/
http://lea.verou.me/demos/nth.html - this one is great, because it's
interactive
In any case, here is something you might want to consider: one thing that can be annoying in the case of hierarchical comments is the fact that, from a certain level, they can get so narrow it looks bad and it even makes reading a bit more difficult. This is why I favour limiting the number of levels - disqus, which was mentioned above, offers the option of limiting the number of nesting levels.
If you have a limited number of levels, let's say three or five, you can add classes for each level (top-level, second-level, third-level) and style them differently. Another option that you have, and this one does not depend on limiting the number of levels is to style odd and even levels differently by adding some odd-level/ even-level classes when you generate the HTML.
Basically, you would have something like this:
<ul class="comments">
<li class="comment first-level">
<div class="comment-data">[date, time, comment author, link]</div>
<div class="comment-body">[whatever is said in the comment]</div>
<div class="comment-footer">[reply option, show/hide comment thread option]</div>
<ul class="comment-thread">
<li class="comment second-level">
<div class="comment-data">[date, time, comment author, link]</div>
<div class="comment-body">[whatever is said in the comment]</div>
<div class="comment-footer">[reply option, show/hide comment thread option]</div>
<ul class="comment-thread">
[... and so on...]
</ul>
</li>
</ul>
</li>
</ul>
If I think better, you can add classes like level-1, level-2,... no matter how many levels you have.
I'm referring to a main menu and a smaller supermenu (don't know the proper term), as seen here:
For something like this, I was going to put two <nav> elements in the <header>. Is there any reason (SEO or otherwise) that this is a bad idea? If so, what would an alternative be?
(this is different from multiple <nav> tags, which referred to multiple on an entire page, not in a single block element)
Short answer: no there is not (probably)
Longer answer: the HTML5 spec itself is a bit fluffy on the subject:
http://dev.w3.org/html5/spec/Overview.html#the-nav-element
The thing is that they designate the <nav> element to 'major' navigation blocks, but leave it to the imagination (of both developers and parsers) what that means. As you can see they even provided an example where they exclude the "site-wide" from the navigation block.
<body itemscope itemtype="http://schema.org/Blog">
<header>
<h1>Wake up sheeple!</h1>
<p>News -
Blog -
Forums</p>
<p>Last Modified: <span itemprop="dateModified">2009-04-01</span></p>
<nav>
<h1>Navigation</h1>
<ul>
<li>Index of all articles</li>
<li>Things sheeple need to wake up for today</li>
<li>Sheeple we have managed to wake</li>
</ul>
</nav>
</header>
They seem to do that because they consider limiting the number of links in nav elements a plus for readability (think screen readers etc).
It is probably a bit too early to know what the search engines are going to do, but it seems safe to think that they will attach more importance to nav element links to detect the structure of you site and maybe more so if you have less of them...
My impression: Twitter and Facebook links seem certainly out, support and blog are debatable
I think it does not matter. NAV element just marks functional role of some content. So if you have two separate navigation blocks (regardless of where it's placed: in header or in other parts of page), you are free to use separate NAV elements for them. Some "penalties" from search engines in that case would be pointless.
Nav can be used multiple times on a page in HTML5.
CAN…yes
SHOULD…probably not.
I’ve always worked on the basis that the NAV tag is only for the primary page/site navigations.
If my main (header) navigation area is used for the [nav] then any other menus can be in divs with some role for ARIA.
I have a page called results.aspx. It shows a list of search results. I have a transport (for want of a better term) at the top and bottom of each page. One of these:
Previous 1 2 [3] 4 5 Next
Each of the text elements in the transport has a link in it, like this:
<a href="results.aspx?page=4" />
Page number varies, of course, based on the intended destination.
My problem is that because the root page name is the same, results.aspx, the browser always scrolls to the same position on the newly loaded page as it was on the page I just clicked away from. Or at least that's what I'm assuming is happening.
I've tried to create tags like
<a name="top">
<a id="top">
and change my link to either of
<a href="results.aspx?page=4#top" />
<a href="results.aspx#top?page=4" />
To no avail. I should point out that this is an inherited code base, so there could be nasties in the javascript that are overriding default behaviors.
Is there an obvious way to fix this? If it should be working by default, is there something in the code that I should be looking for that I should change or remove?
-- EDIT --
Here is a sample of the generated code taken from a browser:
<!-- Page Transport -->
<ul>
<li class="gray">first</li>
<li class="gray">previous</li>
<li class="current">1</li>
<li>2</li>
<li>3</li>
<li>4</li>
<li>next</li>
<li>last</li>
</ul>
Yes, they're just hrefs and for the life of me, I cannot figure out why a browser would remember its position on the page!
-- SOLUTION --
Turns out the original developer included a javascript file, scrollsaver.min.js, which deliberately implemented this behavior. Removing this reference eliminated the behavior.
Are you sure that those links are <a> tags and not buttons or <a> tags with onclick. If they are plain <a> tags what you describe should not happen. If those are postback buttons, somewhere in the code the scroll position is maintained by using MaintainScrollPositionOnPostback. Search for it. Once you can confirm that it is used, you can use Resetting Scroll Position to overcome this.