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.
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.
I am trying to transfer a text from a printed book into HTML5, but meanwhile I am trying to keep its thematic and page/paragraph/lines layout structure exactly as it is. For example, every page of the printed book is divided as a <div> section eg. <div class=page id=55> so that it emulates/represents exactly the page unit of the printed book, and also facilitate referencing. I don't care much how the text will be rendered on the browser, this is something that I can think about later. I just want the HTML and the browser to "know" the original pagination and layout of the printed book.
The problem is that in the printed book, some paragraphs or even boxes, tables etc span over to the next page. If I translate it to HTML, I do it like this:
<div class=page id=1>
<p>Once upon a time...</p>
...
<p>...and so the bold knight
</div>
<div class=page id=2>
slew the evil dragon.</p>
<p>Text...</p>
...
This is illegal in HTML, as we have a <p> tag being interrupted by a </div> tag, and then a new div element beginning with a plain text, which is closed by a </p> tag.
HTML would expect me to close the first part of the broken paragraph with a </p>, and continue with a new <p> tag after the div, but I am not doing this because it doesn't correspond to the pagnation of the original book, and would result in half-paragraphs being understood are 2 proper paragraphs.
So, how to use legal HTML while maintaining the theoretical page/paragraph/broken paragraph/page break structure and information, or at least making the brower "know" the original pagination? Is there a more appropriate tag or method to emulate the page break while keeping the page number id?
Perhaps something like
<p>...and so the brave knight<some tag(s) that show page 2 begins here>killed the dragon</p>
How about instead of encapsulating each page within a div you include a tag at the start of each page designating the page number. An aside tag seems appropriate for this.
<aside class="page-number" data-page="1">Page 1</aside>
<p>Once upon a time...</p>
<p>...and so the bold knight</p>
<aside class="page-number" data-page="2">Page 2</aside>
<p class="continued">slew the evil dragon.</p>
<p>Text...</p>
If you need to continue a paragraph then you'll have to break into multiple elements, but perhaps you can specify when a paragraph is a continuation of a previous one. For instance using the continued class as shown above.
If you really don't want to break the p tag then you could put a span within it that is only used for semantic reasons. Something like this;
<p>...and so the bold knight
<span class="page-marker" aria-hidden="true" data-page="1"></span>
slew the evil dragon.</p>
But this kind of makes less semantic sense than the previous solution.
Try adding display: inline; to either the CSS style of the class page or the style attribute of each page div.
I’m trying to make a search result list more accessible.
Lets say I have a list of search results that are structured in the following way:
<article>
<h2>Name of the author</h2>
<h1><a>Name of the book</a></h1>
<div class="seperator">
<div class="availability-status status1" title="available"></div>
<div class="icon icon-book" title="Book"></div>
<div class="result-button-group">
Sharing
…
</div>
</div>
<p class="imprint">Publishing house (Year)</p>
<p class="series">Part of: name of the series</p>
</article>
The name of the book is a link to another page, while the other elements around it are additional information for the corresponding item.
Visually it looks like this:
How do I structure the markup semantically correct so that users with screen readers can make sense of the result item?
When they navigate on a link to link basis they land on the name of the book, but might miss the author field that is above the title, right? Can I achieve this with aria-attributes? Or is this structured enough to make sense of regardless?
I played around with VoiceOver myself to try to make sense of it but I’m far from an expert. So any input is appreciated.
Outline
You should not use a h2 for the author name. This heading would become the heading for the article element (as it’s the first one), and the heading for the book title would create another section on the same level.
Instead, use only one heading (the book title would make the most sense) and group it with the author name (for which you could use a cite element) in a header element.
<article>
<header>
<cite>Name of the author</cite>
<h1><cite>Name of the book</cite></h1>
</header>
<!-- … -->
</article>
Link
When they navigate on a link to link basis they land on the name of the book, but might miss the author field that is above the title, right?
Yes. But that’s not a problem, it’s exactly what the screen reader user expects/wants to do (finding links, not anything else).
You could, however, consider adding the author name to the link/heading, too:
<h1><cite>Name of the author</cite>: <cite>Name of the book</cite></h1>
Font icons
Note that this is likely inaccessible (details), because the element has no content (the generated image is useless for user agents without CSS, blind users, etc., and the meaning that it conveys is not represented in an alternative way in addition):
<div class="availability-status status1" title="available"></div>
The title attribute is not sufficient. Either use an img (with alt), or add alternative text (and visually hide it).
And this seems to be pure decoration, so there’s no need for a title attribute (and it would be inaccessible to many users anyway, because the element has no content):
<div class="icon icon-book" title="Book"></div>
(But if the information that it’s a book is important, e.g. because there are magazine etc. too, then you should provide an alternative, just like in the case above.)
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.
I found many different views on many articles on presentation tags, with some people thinking all tags are presentational, but some others do not think so.
For example: in the HTML 5 specification, they do not think <small> is presentational.
In this list of tags - which are all HTML 5 supported - which tag is presentational and which is not?
<abbr>
<address>
<area>
<b>
<bdo>
<blockquote>
<br>
<button>
<cite>
<dd>
<del>
<dfn>
<dl>
<dt>
<em>
<hr>
<i>
<ins>
<kbd>
<map>
<menu>
<pre>
<q>
<samp>
<small>
<span>
<strong>
<sub>
<sup>
<var>
Who decides which HTML tag is presentational and Which is not - and how do they make that decision? Is it a particularly large group such as the W3C or is it based on groups of web developers, i.e. the web community? Also, between the two, which advice we should follow for deciding which tags are presentational?
If a tag is valid as according to the W3C in accepted doctypes, then what are the pros to not using any xhtml tag from any point of view?
in user/usability/accessibility point of view
if we use more HTML tags then pages without CSS will better.
in developer point of view
if we make use of more available tags in HTML, than we do not need to use <span class=className">
it takes more time to write and it uses more charter space than tags in HTML and CSS both.
For example:
instead of using:
<span class="boldtext">Some text<span>
.boldtext {font-weight:700}
We can use:
<b>Some text<b>
b {font-weight:700}
it looks cleaner, it is easier to use , it uses less characters - which will reduce the page size - and it is more readable in source. It also does not break the rule of content and presentation separation.
We can also do this:
<b class="important">Some text<b>
b.important {font-weight:700}
and whenever we want to change font-weight then we can change css only in both examples.
If a tag is considered valid by w3c in their recognized doctypes, then what are the pros to not using any X/HTML presentational tags which are not directly recognized by either the W3C, or by the HTML specifications?
Can we change any design parameters without changing anything in HTML? Does this fit within the meme of content and presentation separation?
If any HTML tag breaks the rule of separation, then does not the css property Content break as well?
see this article.
Why are the HEIGHT and WIDTH attributes for the IMG element permitted?. does it not break the rule of separation? A good debate on this matter can be found here.
W3C decides the semantics of tags. The specification documents of HTML5 gives conditions on the use of the various tags.
HTML5
To continue with your example, there is nothing wrong with using <b> to bold some text unless:
The text being bolded is a single entity already represented by a tag:
Incorrect:
<label for="name"><b>Name:</b></label>
Correct: (Use CSS to style the element)
label { font-weight: bold; }
<label for="name">Name:</label>
The text is being bolded to put added emphasis and weight on a section or words of a block of text.
Incorrect:
<p>HTML has been created to <b>semantically</b> represent documents.</p>
Correct: (Use <strong>)
<p>HTML has been created to <strong>semantically</strong> represent documents.</p>
The following is an example of proper use of the <b> tag:
Correct:
<p>You may <b>logout</b> at any time.</p>
I realize that there doesn't seem to be a lot of difference between the above example and the one using <strong> as the proper example. To simply explain it, the word semantically plays an important role in the sentence and its emphasis is being strengthened by bold font, while logout is simply bolded for presentation purposes.
The following would be an improper usage.
Incorrect:
<p><b>Warning:</b> Following the procedure described below may irreparably damage your equipment.</p>
Correct: (This is used to add strong emphasis, therefore use <strong>)
<p><strong>Warning:</strong> Following the procedure described below may irreparably damage your equipment.</p>
Using <span class="bold"> is markup-smell and simply shouldn't be allowed. The <span> element is used to apply style on inline elements when a generic presentation tag (ie.: <b> doesn't apply) For example to make some text green:
Incorrect:
<p>You will also be happy to know <span class="bold">ACME Corp</span> is a <span class="eco-green">certified green</span> company.</p>
Correct: (Explanation below)
<p>You will also be happy to know <b>ACME Corp</b> is a <em class="eco-green">certified green</em> company.</p>
The reason here why you would want to use <em> as opposed to <span> for the word green is because the color green here is used to add emphasis on the fact that ACME Corp is a certified green company.
The following would be a good example of the use of a <span> tag:
Correct:
<p>You may press <kbd>CTRL+G</hbd> at any time to change your pen color to <span class="pen-green">green</span>.</p>
In this example, the word green is styled in green simply to reflect the color, not to add any emphasis (<em>) or strong emphasis (<strong>).
The whole distinction between "presentation" elements versus "structure" element is, in my opinion, a matter of common sense, not something defined by W3C or anyone else. :-P
An element that describes what its content is (as opposed to how it should look) is a structure element. Everything else is, by definition, not structural, and therefore a presentation element.
Now, I'll answer the second part of your post. I understand this is a contentious topic, but I'll speak my mind anyway.
Well-made HTML should not concern itself with how it should look. That's the job of the stylesheet. The reason it should leave it to the stylesheet, is so you can deliver one stylesheet for desktop computers, another one for netbooks, smartphones, "dumbphones" (for lack of a better term), Kindles, and (if you care about accessibility, and you should) screen readers.
By using presentation markup in your HTML, you force a certain "look" across all these different types of media, removing the ability of the designer to choose a look that works best for such devices. This is micromanagement of the worst sort, and designers will hate you for it. :-)
To use your example, instead of using <b>, you should ask yourself what the boldness is supposed to express. If you're trying to express a section title, use one of the header tags (<h1> through <h6>). If you're trying to express strong emphasis, use <strong>. You get the idea. Express the what, not the how; leave the how to the stylesheet designers.
</soapbox>
It's not that presentational elements should be avoided, it's that markup should be as semantic as possible. When designing a document structure, default styling should be considered a secondary affect. If an element is used solely for presentation, it's not semantic, no matter what element is used.
The example usage of <b> isn't semantic, because <b> imparts no meaning. <span class="boldtext"> also isn't semantic. As such, their usage is mixing presentation into the structure.