I am getting H2 violation for below anchor tags.
It says 'H2: Combining adjacent image and text links for the same resource'
<div class="selected-label ccyImage">
</div>
<a href="javascript:void(0);" class="btn dropdown-html-toggle" tabindex="-1">
<span class="caret"></span>
</a>
But there is no any image used. Not getting how to resolve it.
So you have some unspecified tool which is detecting an accessibility problem which is different to the accessibility problem you actually have (or it is being really smart and noticing that you are expressing content using background images … don't do that).
There's not much you can do about the misidentification of the problem other than to report a bug to whomever makes the tool.
You can make your HTML more accessible by:
Not using links when you aren't linking somewhere. If you're using href="javascript:void(0);" then you're doing something wrong.
Link to somewhere useful and progressively enhance or
Use a button (not a link) if you can't make it work without JS
Putting content in your links (or buttons). There is no text at all there to give any clue to the user what the interactive element is going to do.
Related
I have be rewriting my website to be accessibility friendly and have a really good handle on good behavior, but I'm having a problem with the following pattern:
I have a list page of blog entries that I am trying to remove a duplicate link alert for (I know it's just an alert, but it's right to alert me).
<article>
<a href="destination">
<img src="decorative picture.jpg" alt="">
<h2>Blog entry title</h2>
</a>
<p>Summary of blog post and other meta info about the post</p>
<p>
<a href="destination" class="btn btn-details" tabindex="-1"
aria-label="Continue reading about Blog Entry Title">
Continue reading
</a>
</p>
</article>
The usual pattern discussed is when you have an image and title together (solved), but what should I do with the "continue reading" part? It is not, nor should it be, near the image/title, but it really is redundant. I thought about either making the link or the surrounding paragraph aria-hidden="true" because "Continue reading" is really stylistic, someone in a screen reader would know to click the link above, but I know we're not supposed to put links in a hidden context. I thought tabindex="-1" would solve that problem, but there is still a link there, it's just not focusable and is weird for visual navigators because they can't tab to it.
I found the following article, which makes me wonder if I should remove tabindex and use aria-labeledby to bring some semantic connection to the previous link?
<article>
<a id="md5-hash-of-destination" href="destination">
<img src="decorative picture.jpg" alt="">
<h2>Blog entry title</h2>
</a>
<p>Summary of blog post and other meta info about the post</p>
<p>
<a aria-labeledby="md5-hash-of-destination" href="destination"
class="btn btn-details">
Continue reading
</a>
</p>
</article>
What is the optimal way to "eliminate" the entire Continue reading link to give the best UX to people who use screen readers et al?
I think the key to your question is at the very end where you're asking about the UX since the code you have is technically accessible according to WCAG.
Having two adjacent links go to the same destination isn't ideal but it's not a horrible UX either. Users with mobility issues will have two tab stops to navigate through for each article, which can be draining for some assistive technology such as a sip-and-puff device.
I'm not sure I see the need for the "continue reading" link at all. Hearing the blog title and that it's a link, then a summary afterwards seems sufficient. What benefit is the "continue reading" link? I suppose my question might be better asked on https://ux.stackexchange.com/.
If you have to keep the second link for whatever reason, you definitely don't want tabindex="-1" on the link. That would give you a link that mouse users can click on but keyboard users couldn't. Technically, that's not a failure of WCAG 2.1.1 since that guideline says that all functionality of the page must be available to keyboard users, and since your first link is available, having the second link unavailable doesn't fail.
But if you shouldn't have tabindex="-1" on the link, then you shouldn't have aria-hidden="true" either. As you said, interactive elements should not be aria-hidden.
If you really want to keep the second link, my first choice is just leave it as is. If you only want one link clickable, then perhaps make the entire <article> a link. That would cause the blog title and the blog summary/metadata and the "continue reading" to all be read as the link name. That makes for a pretty wordy link, which isn't a great UX either.
So I'm not sure you have a win-win situation. My first choice is to remove the second link completely. The "continue reading" doesn't seem to have any benefit.
Your second code example is not much different from your first. You changed the label of the second link so it ends up being less accessible than your original code. You'll hear "blog entry title" as the name of both links. The "continue reading" will not be announced because you're overriding the link text with the aria-labelledby.
The fa-sticky-note-o icon is not being displayed in
<em class="fa fa-sticky-note-o" aria-hidden="true"></em> on my Chromebook, which is current. Other icons, such as <em class="fa fa-desktop" aria-hidden="true"></em> are displayed. It does appear when expressed as Unfortunately, this is a major documentary feature on https://marlinfw.org/docs/configuration/configuration.html I doubt that they are going to want to code their page differently just for my benefit. :)
I looked at the source of the Marlin document when it became evident that something was missing. I checked the FontAwesome cheatsheet https://fontawesome.com/v4/cheatsheet/ and see that it is displayed when expressed as I was hoping to find how to update or define the icon, but didn't find anything that told me how to do that. I see that "/assets/stylesheets/fontawesome.min.css" is part of the of the head.load javascript at top of the page. Could that be corrupted somehow? How would I force a reload?
Your fontawsome.min.css file appears to be missing a class definition for .fa-note-stick-o.
You'll want to add the following class definition(s) to it:
.fa-note-sticky-o:before,.fa-sticky-note-o:before{
content:"\f24a"
}
This question already has answers here:
Anchor or Button in React SPA?
(3 answers)
Closed 9 months ago.
I see a lot of discussion on the internet about <a> tags that look like buttons, and rules that all links must obey. However, I am confused about <button> tags that are styled to look like links.
I am creating a single-page-app and my navigation component is responsible for rendering / hiding different sections of the website. Only one section would be visible at a time, so I'm treating each section as if it was a unique page with its own route.
My navigation controls are buttons, instead of links. I did this because there is nothing valid that I'm aware of, which I can put inside the hrefs (given that the hidden content is not present in the DOM).
I read on the internet that buttons must have styling to identify the priority of the button, for accessibility reasons. Ideally, I want the buttons to look like links since they behave similarly to links (although not identical).
Are there any accessibility concerns with styling buttons to look like links? Would it make more sense to style these buttons as buttons? If they should look like buttons then what should be the priority? Does it make more sense just to hide the hidden "pages" with css, so that I can turn the buttons into <a> tags and add an href?
Here is the typical markup for single page apps
<div>
<nav>
<ul>
<li>
<button data-name="Skills">Skills</button>
</li>
<li>
<button data-name="Projects">Projects</button>
</li>
<li>
<button data-name="History">History</button>
</li>
<li>
<button data-name="Employment">Employment</button>
</li>
<li>
<button data-name="Contact">Contact</button>
</li>
</ul>
</nav>
<div id="content-panel">
Home
</div>
</div>
The part at the bottom div#content-panel represents the Home page. It will be replaced with the other pages using JavaScript, which will contain the main content of the website.
For those who stumble across this, please don't use <a> without an href, it results in an element that is not longer focusable with the keyboard.
The following fiddle shows this. Try using Tab to focus the links.
You could obviously add tabindex="0" to add them back to the focus order, but this is an anti-pattern and if you ever find yourself doing this it is an indication that you have made a mistake with your HTML.
<div>
<nav>
<ul>
<li>
<a data-name="Skills">Skills</a>
</li>
<li>
<a data-name="Projects">Projects</a>
</li>
<li>
<a data-name="History">History</a>
</li>
<li>
<a data-name="Employment">Employment</a>
</li>
<li>
<a data-name="Contact">Contact</a>
</li>
</ul>
</nav>
<div id="content-panel">
Home
</div>
</div>
If you are building a SPA in a fashion similar to that described by the OP you should still be using anchors <a> for navigation.
There are a few things you should consider:
When each section is shown you should update the URL on the site via JavaScript.
If your site also has Server Side Rendering (SSR) and can function in a limited fashion without JavaScript (recommended as JavaScript does fail more often than you think due to network errors, JS errors for certain scenarios you missed etc. etc.) then the href of the anchors should point to the correct URL.
On SPA navigation it is recommended that once the new page is loaded you programatically set focus on that pages <h1>. You can do this by adding tabindex="-1" to the <h1> (which allows it to receive focus programatically without being added to the focus order of the page) and then using header1.focus()
For an even better experience for people who use a screen reader it may also be beneficial to add an aria-live section to the page with the value of assertive that announces "loading" once a link is clicked. <div aria-live="assertive"><!--add "loading" here programatically when the link is clicked, remove it once the page has loaded--></div>
I have a reasonably long answer with a bit more detail of this technique here that explains why.
To answer the original question finally!
You can style a button to look like a link. However consistency across a site is key.
So make sure that if that is the styling you use for buttons that the majority of buttons look the same.
Also if you make a button look like a standard link then really you should make your links look different to your buttons styled as links.
This avoids confusion as a button has the expectation it will change something on the current page or submit a form, a link has the expectation of changing the page / URL / navigation.
However the advice is not quite the same for a link styled like a button. It has become acceptable that links can be styled like buttons if they are a Call To Action for example. Yet again though, consistency across a site is key for a great user experience.
As stated on MDN Navigation expects to have a links as children. So if you want to prevent any accesibility issue, I suggest you to stick to them, just remove the href attribute and add a type="button" to your a tags.
Anything that looks like something else fools the user. This applies to a link looking like a button, a link looking like plain text, an h1 looking like an h2, a ul looking like an ol, etc. When the user is fooled, the user can get confused or be misled into errors. With a link that looks like a button, for example, the user may press Space to activate it and be surprised to find that it is not activated, but instead the page is scrolled.
The first Google search result for "html links" says (paraphrased) that to create a bookmark / section inside a webpage, we've to do this:
<a id='section-2'>Section 2</a>
so that we can link to it like this:
<a href='page.php#section-2' >Click</a>
But why the site is recommending using anchor tag around "Section 2"? -When it can be done using span:
<span id='section-2'>Section 2</span>
Are there compatibility issues? Because the first search result for "creating bookmarks within a webpage" also says to surround the heading with anchor tag:
<p><a name="title">Title</p>
Though this particular example is incorrect for various other reasons.
I've a supplementary question:
Why to surround the heading with the container when it can be done simply like this:
<span id='section-2'></span>Section 2
Does it matter?
<span id='section-2'>Sec</span>tion 2
<a href='page.php#section-2' >Click</a>
There is no point. W3schools is unreliable, just don’t use it, and you will avoid confusion and wrong information; see http://w3fools.com
In the old days, the only way to set a destination anchor within a page was to use <a name=...>...</a> element (at the text level). Later, the id attribute was added and is now supported by all browsers in use, so you can make any element a destination anchor simply by attaching an id attribute to it. E.g., to make it possible to link to a heading like <h2>Section 2</h3>, you could make it just <h2 id=section-2>Section 2</h2>. No need for an artificial extra element.
Using <span id='section-2'></span>Section 2, though formally correct, is not a good idea. You win nothing by using it, as opposite to the more logical markup. And if you e.g. later want to style (highlight) the element to which the user has “jumped” into with a link, using the :target pseudo-class, you will find yourself in an awkward position: the pseudo-class would let you style just the empty content of the span.
Regarding the question in the title, there is no reason to make the top of a page an destination anchror, with <a id='top'>Top of page</a> or otherwise. First, you can refer to the start of the page using just href=# since by URL specifications, # denotes the start of the current resource. Second, “Back to top” links are basically useless or worse: every browser has a simple command for going to the start of the page, and an explicit “Back to top” link can be confusing: back to top of what?
In the early days of html an anchor element was the only way to do this, but just because you can now do it with other element types doesn't mean you should: using an anchor for this purpose is semantically correct because it makes it clear to anybody reading or maintaining your markup that the element is intended as a navigation target. (Noting that there will often be many elements on the page that have an id but are not navigation targets.)
"Why to surround the heading with the container when it can be done simply like this:
<span id='section-2'></span>Section 2
Because if you put the text of your heading inside an element you can style it and/or easily mess with it from JavaScript. Indeed, if it is a heading you may want to put it in an <h1>, <h2>, etc. tag rather than a <span>.
Probably a stupid question, but I honestly can't wrap my head around what's going wrong here.
http://harrisonfjord.com/thinkinc/
A site I'm building at the moment. I want to make an anchor link at http://harrisonfjord.com/thinkinc/index.php#sponsors. I've set up the anchor to occur just before in the following code:
<a name="sponsors"></a>
<div class="sponsors">
<div class="sponsors-left">
<h2>Sponsors</h2>
<p>Support the lovely folks who support us! Visit their websites, join their mailing lists and peruse their wares. They are all highly-deserving of your custom, and we're thrilled to have each and everyone one of them on-board!</p>
</div>
However, when you click on the anchor link it lands about halfway down the div. I thought it might have been a problem with the images loading after the anchor link loads, so I manually put in widths/heights for all of the tags. I also did the same for the cufon text replacement in the title bar.
None of that helped, so now I turn to you. The anchor is also not working in Firefox, for whatever reason. Any thoughts on what I've done wrong here?
Cheers!
I think the problem is resulting from the anchors with no contents that you are using.
Also, it appears that name= has been deprecated in favor of id= as a fragment identifier in certain elements (including A) which makes a kind of sense as ID attributes are unique whereas NAME attributes are not so guaranteed.
I'd try sticking the fragment identifier in the actual renderable entity such as:
<h2 id="sponsors">Sponsors</h2>
and see where that gets you. Incidentally, it looks like a good conference, I hope you get a comp admission.
I got the exact same issue in Firefox and solved it with this (same as sasi answer but more generic - it detect if there is an anchor in the url and scroll to it):
$(document).ready(function() {
if(window.location.hash.length > 0) {
window.scrollTo(0, $(window.location.hash).offset().top);
}
});
It seems it's a well known issue, see https://bugzilla.mozilla.org/show_bug.cgi?id=60307
I got problem in iphone for links with fragments, having
TYPES OF INFORMATION WE COLLECT, correctly linking to
<h3 id="info">TYPES OF INFORMATION WE COLLECT</h3>.
That wasn't working properly, and I fixed with a solution like this (using jQuery):
window.scrollTo(0,$('#info').offset().top);
I solved this with a trick, I have put an empty span element with the required ID and a line break before the div
<span id="sponsors"> </span>
<br>
<div class="sponsors">
<div class="sponsors-left">
<h2>Sponsors</h2>
<p>Support the lovely folks who support us! Visit their websites, join their mailing lists and peruse their wares. They are all highly-deserving of your custom, and we're thrilled to have each and everyone one of them on-board!</p>
</div>
</div>
GO TO SPONSORS
I don't know what standard your page is trying to conform to, but it is full of errors:
http://validator.w3.org/check?uri=http%3A%2F%2Fharrisonfjord.com%2Fthinkinc%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
Some of them so severe, for example:
Unable to Determine Parse Mode!
No DOCTYPE found, and unknown root element. Aborting validation.
that the validator gives up. Contrasted with a page like gnu.org
http://validator.w3.org/check?uri=www.gnu.org&charset=%28detect+automatically%29&doctype=Inline&group=0
You should be pleased that the site renders at all.
I had a problem with scrolling to the wrong position and I fixed it by disabling the Development Tools panel in Chrome :) Apparently Chrome calculates the position incorrectly when DevTools is open.