For decorative icon fonts and other applicable components, is there a difference between using aria-hidden="true" and using role="img" alt=""
Yes there is a difference, but not a massive one.
aria-hidden="true" will completely remove it from the accessibility tree.
role="img" alt="" will still add it to the accessibility tree as a decorative image. (well an image with no alt description if we are being technical - it won't get read out and that is what we care about)
Now this doesn't cause issues for majority of screen reader users. But some screen reader users may use a screen reader with very high verbosity settings (how much detail gets read out).
In this case it can actually be possible that with role="img" that the image is read out as "image, no description".
It is an edge case, but one to consider.
As an additional thought - support for role="img" may not be so great (there isn't a lot of data on this)
I would encourage the use of aria-hidden="true" and perhaps add role="presentation" as support is good for that as a nice fall-back.
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.
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.
Let's take an Open Library list page for example. When you visit the page, one of the first things that a user with a screen reader would hear is "link, Mek". Mek is the username. However, in the case of social websites someone could pick any username like "borrow the book" or things that I imagine would be disorienting to people using screen readers.
So, my question is, would it be appropriate to use something like aria-label to say that it is a username since that is not otherwise written on the page? If not, is there another way that people using screen readers deal with this?
I'm new to A11Y and ARIA so maybe I'm looking in the wrong place for answers. I have tried searching this in may ways and read some documents like Using aria-label for link purpose and Using aria-label to provide an invisible label where a visible label cannot be used.
I also looked at the code on social sites such as Twitter, Reddit, and Facebook but as far as I can tell none of do anything special for usernames. Perhaps it is less important for sites that are primarily user generated content.
Linked Example
In the example page you linked those are actually breadcrumbs so technically make sense.
<div class="superNav">
Mek
/
Lists
</div>
With that being said they should be located within an unordered list (as an unordered list is useful for screen reader users to know how many links there are as it will read "1 of 2 option" or similar) and have some form of identification on the <nav> (so it is not considered main navigation):
<nav aria-label="breadcrumbs" class="superNav">
<ul>
<li>
Mek
</li>
<li>
Lists
</li>
<ul>
</nav>
Finally if you have a sophisticated back-end or the first link will always be a link to a user profile then you could add some visually hidden text to the link just for clarity.
HTML
[...]
<ul>
<li>
<span class="visually-hidden">User Profile for </span>Mek
</li>
[...]
CSS
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
Social sites
However for social sites there are loads of things you can do.
For example if the image is a link to their profile you can use the alt attribute to indicate the action of the link.
<a class="profile-container"
<img src="profile-image-user-rayb.jpg" alt="RayB profile page" />
</a>
If it is just a static image (and their username is not shown anywhere else) then the alt attribute would change with the context.
<img src="profile-image-user-rayb.jpg" alt="RayB profile picture / avatar" />
If it is a static image and the persons name is located somewhere else within that article / block then you would likely hide the image:
<article>
<h2>Some article Title</h2>
<img src="profile-image-user-rayb.jpg" alt="" role="presentation" aria-hidden="true"/>
<p class="written by">Author: RayB</p>
</article>
** please note:** in the last example an empty alt attribute is sufficient to hide an image from a screen reader. I add role="presentation" and aria-hidden="true" so that I can check for empty alt attributes that are mistakes (e.g. if they do not have aria-hidden="true" then I know they should have an alt attribute filled in).
Why so many variations?
This is where accessibility turns from a set of rules into an art form, you have to pick the best option depending on the circumstances.
A good place to start for alt attributes for example is the alt text decision tree from W3.
Other than that consider things like:
does this add additional information a screen reader user needs?
Is the information available elsewhere / nearby and does this then just duplicate it?
If this is an image in a link does the alt attribute reflect the action of the link in context. etc....
Above all, grab a screen reader and try it, that is without doubt the quickest way to learn (as you can identify an issue / something that confused you / repetition etc. and then it is easy to look for a fix/).
If you need more info just let me know!
I'm wondering about screen reader accessibility using Twitter Bootstrap framework and FontAwesome icon fonts.
I'm looking at 2 different icon situations:
1) The icon has helper text that a screen reader will pick up:
<span class="fa fa-pencil"></span> Edit
2) And a standalone icon without any helper text:
<span class="fa fa-pencil"></span>
Ideally, in both situations, a screen reader will announce that the element is an "Edit" button.
Per FontAwesome's site:
Font Awesome won't trip up screen readers, unlike other icon fonts.
I don't see any speech css tags related to FontAwesome or Bootstrap and not really clear to me how a screen reader will react to each of these situations.
I'm also aware of aria-hidden and Bootstrap's .sr-only and there has to be an ideal way to handle both situations.
Edit: added title="Edit to example 2.
What advantage does using aria-label="Edit" have over the standard title="Edit"?
Edit 2: I came across this article that explains pros and cons of different use implementations.
First of all, you should probably use <button> instead of <a href="#">. Empty links can be confusing for screen readers, but a button is a button. In short, links take you places, buttons perform actions. (http://www.karlgroves.com/2013/05/14/links-are-not-buttons-neither-are-divs-and-spans/; https://ux.stackexchange.com/questions/5493/what-are-the-differences-between-buttons-and-links).
I would go with a variation of your first code sample, and utilize Bootstraps .sr-only class. If we update your code with button and add in the class, we have:
<button type="button" class="btn btn-default"><span class="fa fa-pencil"></span> <span class="sr-only">Edit</span></button>
We now have a more semantically correct button element; sighted users see the edit pencil icon; and screen reader users will hear "Edit". Everyone wins.
(Note, the button code is straight from Bootstraps CSS Buttons section.)
From my understanding I think it may be useful to also add in:
aria-hidden="true"
to the span class that holds the pencil icon. This will prevent the screen reader from trying to read this element.
<span class="fa fa-pencil" aria-hidden="true"></span>
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do I set retina graphics for my website?
What is the best method for adding 2x images to webpages that will be displayed on the new iPad with Retina graphics?
I've gone through these articles.
http://www.kylejlarson.com/blog/2012/creating-retina-images-for-your-website/
http://www.teamdf.com/web/automatically-serve-retina-artwork/191/
http://retinajs.com/
There are various suggested methods for tackling the problem of Retina displays (and large display screens etc.) unfortunately most of these are just that, suggestions.
The two most popular are the suggestion of adding a tag, which accepts multiple images and the browser will load only one (dependant on media queries specified by the developer):
<picture alt="angry pirate">
<source src=hires.png media="min-width:800px">
<source src=midres.png media="min-width:480px">
<source src=lores.png>
<!-- fallback for browsers without support -->
<img src=midres.png alt="angry pirate">
</picture>
The other suggestion is specifying multiple sources for an image using 'srcset' on an image:
<img alt="Cat Dancing" src="small-1.jpg"
srcset="small-2.jpg 2x, // this is pretty cool
large-2.jpg 100w, // meh
large-2.jpg 100w 2x // meh#2x
">
I personally think this is a lot more ugly (and it leaves you less control as the browser decides which image to load) but from my understanding the second solution has been added to the official spec (in some capacity)
Outside of these suggestions the only real current solution is to start with an image 2x the original size (or 1.5x depending on your preference)
It may be possible to try and get all fancy and do a JavaScript solution, but I think that would be over complicating things ...
Below is a really good articles which discusses the issue you describe (I feel I'm rambling a bit!):
http://www.alistapart.com/articles/mo-pixels-mo-problems/