I am currently developing a site that needs to be ADA Compliant. When I check the site in WAVE I get a perfect score with 0 errors. However, when I put it in this checker, it says there are 6 errors that are missing alt tags.
These images are svgs and when I view page source and inspect element, I can see the alt tags, they are clearly there. For some reason the checker is looking inside the actual svg itself
Here is the code:
<div class="footer-desktop">
<img src="<?php echo get_template_directory_uri(); ?>/img/fc-footer-logo.svg" alt="Footer Logo">
</div>
I have tried adding role="image" and that just causes more errors. I've also tried adding a title tag.
Not all automated validators are accurate and they shouldn't be relied on as authoritative. They are merely tools to assist you in finding things that may be an issue. Your best bet is testing and confirming if things are accessible. That being said, here are some tips for making it a bit better for SVGs...
On your SVG, use <title> and <desc> tags and give each unique ID. Then include an aria-labelledby on the tag. For example:
<svg width="300" height="100" xmlns="http://www.w3.org/2000/svg" aria-labelledby="svgTitle svgDesc" >
<title id="svgTitle">This is my title.</title>
<desc id="svgDesc">This is my description.</desc>
<...>
</svg>
This should give you pretty good screen reader support. However, I can't claim that it will pass any specific automated tests. Alternatively, you can just use an aria-label on the SVG, but then you don't get the tooltip in standard browsers from the title tag.
Note: The <svg> tag doesn't have an "alt" attribute,so it wouldn't be valid HTML5.
BTW, it should be role="img" not role="image".
Related
I'm not a fan of using images for site logos, I prefer using text with a designed font style... Since they are just text, browsers and crawlers might not understand what it stands for and I keep wondering how I can initialize my text-based logo to be recognized by HTML.
So I thought of doing something like this:
<h1 role="logo">Stack Overflow</h1>
But this isn't correct because there is nothing like role=logo in HTML.
How can I do this?
If you want browsers and assistive technologies to interpret something as an image, you can use the ARIA img role. But don't place this on the <h1> element, because the role="img" attribute will replace the semantics of the heading with an image. Instead wrap it in a <span> and place the role attribute on it, in order to preserve the heading. Also, don't forget your aria-label attribute.
Don't do this:
<!-- don't do this -->
<h1 role="img" aria-label="Logo">Logo</h1>
<!-- because it gets interpreted as this -->
<img alt="Logo">
Instead, if you must:
<!-- if you must, do this -->
<h1><span role="img" aria-label="Logo">Logo</span></h1>
<!-- because it gets interpreted as this, preserving the heading -->
<h1><img alt="Logo"></h1>
However, I can't think of any tangible benefits to forcing browsers to see your text logo as an image. You're fine just leaving it as a normal <h1>.
It seems your use case is covered by existing ARIA img role. Quoting the docs:
Any set of content that should be consumed as a single image (which
could include images, video, audio, code snippets, emojis, or other
content) can be identified using role="img".
I am currently studying the web accessibility guidelines that concern HTML5.
Concerning images, I am currently adding images in HTML as follows:
<!-- Normal Images -->
<img src="https://placeholder.pics/svg/300x300" title="Image Placeholder" alt="Image Placeholder" aria-labelledby="Image Placeholder" width="300" height="300">
<!-- Decorative images -->
<img src="https://placeholder.pics/svg/100x100" role="presentation" aria-hidden="true" alt="" width="100" height="100">
Is it recommended by WAI-ARIA to add both aria-labelledby and alt tags together for normal images? or is there something else that I should adopt?
Do I need to add role="presentation", aria-hidden="true", and alt="" to every decorative image? All three of them should go together? or only one of them? (if only one or two of them then which ones?)
Is it a good practice to add both aria-labelledby and alt tags together for normal images? or is there a better practice that I should adopt.
aria-labelledby
No, in fact adding aria-labelledby and alt together will result in some screen readers reading the name twice. Just use an alt attribute, that is what it is there for, it has the widest support (100%) and will do the job just fine.
Also aria-labelledby requires at least one element in the DOM that contains text, you reference it by ID. You can have more than one label too just for reference. It is designed to be used on other elements that can't be labelled using semantic HTML, not really for images (there are always exceptions but they are rare and this is general guidance).
e.g.
<span id="ID1">Read First</span>
<span id="ID2">You can add a second label that will be read second</span>
<div aria-labelledby="ID1 ID2"></div>
title attribute
Also don't use a title attribute unless you are planning on making it the same as the alt attribute. Otherwise mouse users get a different experience to screen reader users as the title attribute is not accessible to most screen readers. See this in-depth answer I gave about the title attribute and how to roll an accessible version if you want to use it.
accessible image example
So your final, accessible image would look like this:-
<img src="https://placeholder.pics/svg/300x300" alt="Image Placeholder" width="300" height="300">
Perfectly accessible and easy to maintain.
Do I need to add role="presentation", aria-hidden="true", and alt="" to every decorative image? All three of them should go together? or only one of them? (if only one or two of them then which ones?)
alt attribute
All you need to do is add an empty alt attribute. Notice how I said empty and not null.
e.g. alt="" NOT just alt. Using alt as a null attribute will result in it being ignored by some screen readers so the file name will get read out.
role="presentation"
For completeness you can add role="presentation" but it will not add any extra support as far as I am aware.
With that being said I personally add role="presentation" to decorative images as our unit testing will flag any empty alt attributes unless this is added. This was a deliberate decision so when we run tests we don't keep checking the same empty alt attributes are correct.
As support for empty alt attributes is also at 99/100% it is also perfectly valid and accessible to just use alt="".
aria-hidden
The only place (well the main time, there are always exceptions) where you would want to use aria-hidden on an external image is if you are going to dynamically hide and show it. Some screen readers monitor WAI-ARIA changes better than DOM changes.
aria-hidden and inline SVGs
I would recommend adding aria-hidden="true", role="presentation" and focusable="false" on inline SVGs that are purely decorative though as Internet Explorer can sometimes allow them to be focused.
Note that you don't use alt attributes on inline SVGs anyway.
decorative images examples
So your final decorative image would be:-
<!--all image types loaded externally using `img` including SVGs-->
<img src="https://placeholder.pics/svg/100x100" alt="" width="100" height="100">
<!--exception for inline SVGs due to focus bug in IE-->
<svg aria-hidden="true" role="presentation" focusable="false">...</svg>
final note on WAI-ARIA
WAI-ARIA is there to provide information when there is no semantic way to do so.
Adding extra WAI-ARIA all over actually makes accessibility worse. You should always start with 'is there a native way to give the information to a screen reader', if there is, WAI-ARIA is not needed or in fact recommended.
After Thought
I mentioned inline SVGs not using the alt attribute, instead you want to use <title> as part of the SVG. Read this quick article on accessible SVGs for a quick overview.
<a href='' itemscope itemtype='http://schema.org/Brand' itemprop='brand'><i class="logo" itemprop='logo'></i></a>
The above class='logo' applies a font to the icon element. Can we apply the 'glyph' defined in the class (e.g., font-family: 'AnyFont'; content: '/e600') as a Microdata Markup DataType "Brand > Logo" to render the Logo in a rich-snippet the same as a image would render in the rich-snippet?
This doesn't seem likely as an image has a URL based src="..." property and a font character does not, none the less I've been researching this I've found no documentation or discussion on this and need to know if the community is aware of a way to make this work if it does't already work. Or do we have to forfeit the many well-known benefits of using an icon-font to display a logo in rich-snippets?
As validation to the common application of microdata to an image and not an font-character we see that this heavily used microdata generator doesn't give us an option to apply microdata to an element with a font applied to it. And based on the 'Brand > Logo' documentation, the only options are ImageObject and URL (which many very well may believe this answers the question (there's bound to be a way to do this without having to go back 4 years and use an image instead of a font)).
You could use a link element (which may be used in the body in HTML5+Microdata) to provide the URL of the logo:
<a itemprop="brand" href="" itemscope itemtype="http://schema.org/Brand">
<span class="logo"></span>
<link itemprop="logo" href="logo.png" />
</a>
(I used span instead of i. And for the record, I don’t agree that it’s a good idea to include a site’s logo via CSS instead of HTML.)
My html anchor tags work in chrome and IE but in Firefox, Safari, iPad and iPhone they do not work, how come? and what can I do to fix it?
Underpinning
Any help would be appreciated.
Thanks.
This is what I am trying to link it to on the services page:
<h1 id="#underpinning" name="underpinning">Underpinning</h1>
This is where I left off:
This is my link:
<li><h2 id="underpinning">Underpinning<a href="services#underpinning"><img class="alignnone size-full wp-image-127" alt="home" src="http://powellgroupconstruction.com/wp-content/uploads/2013/12/home.jpg" width="500" height="337"></h2></a></li>
This is where on my services page I want the link to goto:
<a name="underpinning"><h1 id="underpinning" name="underpinning">Underpinning</h1></a>
If I goto the url directly: http://powellgroupconstruction.com/services/#underpinning into safari or firefox, it works.
There are several issues in your code.
On your example website you're using HTML5 Doctype, so I'm just answering respectively with HTML5 in mind:
Forget about name attribute in general and <a name> markup as link target in particular. As the HTML5 Candidate Recommendation spec states: "An element's unique identifier can be used for a variety of purposes, most notably as a way to link to specific parts of a document using fragment identifiers, as a way to target an element when scripting, and as a way to style a specific element from CSS." That means, you can use any id as a link target.
As Itay Gal has already stated in his answer, don't use the same id more than once. From the HTML5 spec again: "The id attribute specifies its element's unique identifier (ID)".That said, change your current code: <a id="underpinning" name="underpinning"><h1 id="underpinning" name="underpinning">Underpinning</h1></a> to <h1 id="underpinning">Underpinning</h1>
You're using as link address currently /services#underpinning. As you're going with the WordPress rewrite functionality, entering http://powellgroupconstruction.com/services gets redirected to http://powellgroupconstruction.com/services/.Therefore you should better put a slash at the end of your pages' names, so the link address should be Underpinning
You are using the same id in multiple elements. The id needs to be unique, make sure you use each id only once and it should work.
Are href for both h2 and img tags are same? then have you tried this one:
<a href="services#underpinning">
<h2 id="underpinning">Underpinning
<a href="services#underpinning"><img class="alignnone size-full wp-image-127" alt="home" src="http://powellgroupconstruction.com/wp-content/uploads/2013/12/home.jpg" width="500" height="337">
</a></h2>
</a>
I had an issue very similar to this. I believe your problem is that Firefox and Safari do not like an <h2> tag inside an anchor <a> tag. Try :
<span id="underpinning">Underpinning</span>
I encountered this page https://www.google.com/accounts/ServiceLogin, a Google service login page that (beyond just omitting a doctype), contains 6 instances of </img>
For example,
<img src="https://www.google.com/accounts/google_transparent.gif"
alt="Google">
</img>
Why would they ever do that? What benefit/functionality/grandfathering do they possibly achieve?
Anything I've ever read about HTML and XHTML has made it pretty unequovical:
In HTML 4.01 and prior, <img> tags are never to be closed ( <img src="img.gif" alt="text" >).
In XHTML, <img> tags are to be closed using self-closing syntax ( <img src='img.gif' alt="text" />)
In HTML5, (my understanding is that) either syntax (open or self-closed) is acceptable, but still never </img>.
I'd say this is a bug. In at least one case it seems to be just producing totally invalid code:
<img class=logo
src='https://www.google.com/intl/en/images/logos/accounts_logo.gif'
alt="Google" />
</img>
You can see the img tag is self closing and being closed by a separate closing tag. Clearly unintended. And its inconsistent which is a little weird too. I'd suggest e-mailing them and asking. :)
I've found the only (proposed) way this code is ever actually compliant, though it does not apply in Google's case (since they lack a DOCTYPE).
XHTML 2, which was proposed and then scrapped, implements a </img> tag as a way to replace the alt attribute.
So, instead of this in XHTML 1.0/1.1:
<img src="monkeys.gif" alt="Monkeys throwing feces" />
You'd have this
<img src="monkeys.gif">Monkeys throwing feces</img>
Where 'Monkeys throwing feces' only displays if monkeys.gif fails to load.
This would make <img> behave as other content embedding tags, like <object>.
In the spec's words,
The img element is a holder for
embedding attributes such as src.
Since these attributes may be applied
to any element, the img element is not
strictly necessary, but is included to
ease the transition to XHTML2. Like
the object element, this element's
content is only presented if the
referenced resource is unavailable.
Maybe their HTML-generator closes every <tag> with a corresponding </tag>, which is just a programmatically lazier alternative to writing <tag/> for such single tags.