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.
Related
I am frequently tasked with displaying a grid of thumbnails for work, such as on a posts/articles page, with each thumbnail linking to a separate post/article, but I have never really been sure of the best way to format these for screen readers/accessibility. More specifically, I have never been sure whether to use the <article> or <figure> tag for this purpose, or neither, or something else entirely. Does anyone know? These are the three methods I am debating between:
<a>
<article>
<img />
<div></div>
</article>
</a>
<a>
<figure>
<img />
<figcaption></figcaption>
</figure>
</a>
<a>
<img />
<div></div>
</a>
The documentation for the article tag says that it "represents a self-contained composition in a document, page, application, or site, which is intended to be independently distributable or reusable". I don't know what that means in this context, but it seems like it could be intended for this purpose, or it could be meant to be used once on the actual article pages and not the overall "articles" list page.
The documentation for the figure tag says that it "represents self-contained content, potentially with an optional caption". It seems like it would work quite well here, except my intuition says that it might be intended more for figures that are inline with the text of articles, so I have my doubts.
The 3rd option is to use neither the article or the figure tag in an effort to just simplify the html as much as possible so that screen readers do not have to look at and interpret as many nested tags.
References:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure
From an accessibility perspective, I have not found much benefit to using an <article>. On iOS and Mac, Safari incorrectly treats an <article> as a landmark even though the definition of an article role specifically says it isn't.
An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion.
Notice that it says AT could pay attention to the article element but other than the aforementioned treatment as a landmark in Safari, I have not found NVDA, JAWS, or Voiceover to do anything special with an <article>.
If you plan on having a caption below the image, then you could use <figcaption>. It's just a handy way to visually display text below an image. But if the thumbnail doesn't have text below it but rather has a heading or link to the article, then <figcaption> isn't needed.
Your last example, the simplest, is the most common way to code what you want and works just fine for accessibility. I know your code snippets were just minimal code but make sure your <img> uses the alt attribute.
If your image is inside your link (as in your example) and there's other text containing the title of the article within the link, then the image can have an empty alt="" (or even just alt with no value). But if there isn't any visible text in the link, then make sure the image has an appropriate alt attribute value.
In my page i need to list last news with title only. I have two methods:
One:
<div>
<p>Title One</p>
<p>Title Two</p>
<p>Title Three</p>
<p>Title .....</p>
<p>Title .....</p>
<p>Title .....</p>
</div>
Two:
<div>
<ul>
<li>TTILE ONE </li>
<li>TTILE Two </li>
<li>TTILE THree</li>
<li>TTILE .....</li>
</ul>
</div>
In HTML5 which way is better and readable?! with <p></p> Or <ul><li>?!
Neither is better in terms of how html can be read. However it is considered a list, and so your question can be answered by means of using <li>
You have there a list of news, so the correct one is UL.
The first option, using paragraphs is bad, because... Do you thing titles are paragraphs? I think title != paragraph, so uou can't use <p> tag.
Using an unordered list, <ul>, would be more semantically correct than using a paragraph, <p>.
Obviously either one could be used, so semantics may feel like a 6 vs half dozen sort of thing, but in the long run using the correct tags will make your job easier.
The <p> will come with native styles, i.e. margins and so on, that will need to be removed in your css if you intend you use them this way. While <ul> and <li> will probably only need to have bullet points accounted for.
Also not everyone experiences the web in the same way, try to keep in mind that screen readers will take markup into account when reading pages to the visually impaired.
In more extreme cases semantics can even effect your search engine optimization (SEO). Google, for instance, may grab your first paragraph and use it as a part of your site description.
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 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.
our site is giving out 'badges' to our authors. they can post these on their personal blogs and they will serve as incoming links to our site.
We want to give out the best possible code for SEO without doing anything that would get us flagged.
i would like to know what you're thoughts are on the following snippet of code and if anyone has any DEFINITE advice on dos and donts with it. Also, let me know if any of it is redundant or not worth it for SEO purposes.
i've kept the css inline since some of the writers would not have access to add link to external css
i've changed the real values, but title, alt etc would be descriptive keywords similar to our page titles etc (no overloading keywords or any of that)
<div id="writer" style="width:100px;height:50px;>
<h1><strong style="float:left;text-indent:-9999px;overflow:hidden;margin:0;padding:0;">articles on x,y,z</strong>
<a href="http://www.site.com/link-to-author" title="site description">
<img style="border:none" src="http://www.site.com/images/badge.png" alt="description of articles" title="View my published work on site.com"/>
</a>
</h1></div>
thanks
Using H1 to enclose your "badge" is a really bad idea—not in so much as it'll negatively affect SEO for your site, but it will very likely ruin the accessibility (and thus SEO) of the author site. H1-H6 are used to provide document structure by semantically delimiting document headings. Random use of heading tags can confuse screen readers and webcrawlers. There's not much you can do in terms of legitimate SEO aside from making correct use of semantic HTML markup.
Edit:
Something like this would be the safest bet:
<div id="writer-badge" style="width: 100px; height: 50px;">
<strong>
Articles on x,y,z
</strong>
<br />
<a href="..." title="site description" rel="profile">
<img style="border: none" src="..." alt="..."
longdesc="http://site.com/badges-explained"
/>
</a>
</div>
I put a line-break between the text and image to treat the text as sort of a badge title. If it's not meant to be displayed that way, then I would omit the <strong> tags altogether (there's no semantic value in encapsulating the text that way, and any styling could be done using the DIV or a weight-neutral SPAN element).
IMO there's really no reason for a achievement badge to have a heading of its own (it's really not even part of the document, just a flourish in the layout), but if you absolutely must, then H6 would be more appropriate and safer to use than H1.
As far as keyword proximity, that is sorta venturing into the grey-hat area of SEO (similar to keyword stuffing), and I wouldn't know anything about that. I've yet to come across any reliable info on how Google or other search engines treat keyword placement. I think if you properly use tag attributes like alt, title, longdesc, rel, rev, etc. in images and links, you'll be alright.
I don't think there is any issue with this code except your <h1> tag. I would probably change it to <h2> simply because pages are supposed to have only 1 <h1> tag per page.
You could also use an iFrame instead if you wanted. That is what SO does but I know you will not get as much linky goodness.