I want to put an online counter on my (tumblr) blog.
I get a script as a result.
I know where and how to add that code, but I'm wondering how to make this link/script unclickable? Otherwise you can click on it and view a map of all the people that are currently online and I find that rather creepy.
How can I make this unclickable?
Easy CSS way: add a css-class to the document.write-span-tag part of the code which is inserted to your document via the code snippet you included:
<span id='o_"+fhs_id+"'></span>
change to
<span class='unclickable' id='o_"+fhs_id+"'></span>
and add a CSS rule to where ever you have your CSS like this:
.unclickable {
pointer-events: none;
}
(works in most browsers, also internet explorer 10 and newer.
for older browsers you'll probably need a javascript solution)
javascript solution:
add onClick='return false' to the same snippet part:
<span id='o_"+fhs_id+"' onClick='return false'></span>
<a class="btn" href="http://freehostedscripts.net/oc.php?id=SUQ5MDAwMDAwMXxmcmVlaG9zdGVkc2NyaXB0cy5uZXR8MA==" title="319 Online [FHS]" target="_blank">319 Online Users</a>
so that's what you have you can do
<a class="btn" onclick="return false"...
Related
I am trying to put outline on a font awsome while navigating with keyboard, but it is not working. I tried to add aria-hidden="true" tabindex="1" like suggested in another post but it still doesn´t work.
<div class="faContainer">
<a class="homeAnchor" href="" aria-hidden="true" tabindex="1">
<i class="fas fa-home fa-2x">
</i>
</a>
</div>
CSS
a:focus{
outline: 3px solid white;
}
tried also targeting i element
Few issues to address here:-
Never use positive tab index
A positive tab index disrupts the natural tabbing order, you want tabindex="0" in order to make something that isn't normally focusable able to accept focus. It is also not needed in your example as <a> elements are focusable by default.
aria-hidden has nothing to do with focus
aria-hidden is to do with the accessibility tree. By adding this attribute you are telling assistive technology (i.e. screen readers) to ignore this item. Remove this.
empty hrefs can get ignored
Your href="" attribute can be ignored in certain circumstances as it is not a valid hyperlink.
Add href="#" during testing if you do not know the URL you want to point it at currently.
If it is going to be used to make a change on the current page use a <button> element instead as that is semantically correct (i.e. it is going to work with a JavaScript function rather than function as a link).
how to find out why outline isn't working
The above CSS (on a dark theme) should work fine.
On Google Chrome -> Open developer tools (F12) -> inspect the element.
Top right you will see Filter :hov .cls +
Select :hov and click the :focus checkbox.
There will be a rule set that is over-riding your a:focus rule, either by being more specific (e.g. a.homeanchor:focus) or by using !important.
That rule is likely to be outline:0 or outline:none so you could also try doing a search within your CSS for those terms to identify the issue.
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>
I have a portfolio that works fine but I'm currently building a CMS for it so that I can simply upload the image and it adds it to the site for me. Before I build it, I'm rebuilding some of the scrappy code and converting the what was a JS powered gallery to a CSS powered one.
I'm trying to achieve this click effect in CSS. http://www.tomdwyerdesign.com/graphics/
I thought I could do it via the :focus selector but I've run into a little problem.
This is the HTML:
<a class="tile" href="#">
<img src="images/thumbs/DLPWD.png" class="dlpwd" />
</a>
and this is the CSS:
.tile:focus img{
background-image: url("images/large/DLPWD.png");
width: 771px;
height: 600px;
}
It doesn't seem to select it properly. Any one know why?
Thanks.
The problem is that a link is not necessarily focused when it's clicked, it's focused when you navigate to it. You can do this with the keyboard, or you could add a click handler to the link. Of course at that point, you're back into javascript, but it shows what's happening.
E.g.
<a class="tile" href="#" onclick="this.focus()">
<img src="images/thumbs/DLPWD.png" class="dlpwd" />
</a>
Luckily, there is a better solution, and one that doesn't require javascript. If you add a tabindex to the link, clicking it will focus it even if the href is going nowhere. So...
<a class="tile" href="#" tabindex="0">
<img src="images/thumbs/DLPWD.png" class="dlpwd" />
</a>
Should do what you want.
(your next problem is going to be that the background-image won't be visible in front of the src image - you're just going to get a stretched version of the thumbnail. But I think that's a different question)
:focus is only available on elements that receive keyboard input (i.e. form elements). You could try :active but it will only apply the CSS while the mouse button is down.
I've got an ASP.NET 4 app being developed and tested against http:// localhost/mysite - I spent a while looking into a problem with Twitter Bootstrap buttons in Firefox (v12.0) where they looked weird.
However I noted that, when testing, if I swapped the URL and changed 'localhost' for my machine's FQDN (e.g. http://mymachine.mydomain.com/mysite) then it worked normally and as expected.
This is kinda good news because it means that there isn't a "bug" as such that I have to fix but I'm curious about why it's happened in the first place.
The weird behaviour is as follows:
The 'button' is marked up as follows (in this case, a <a> to look like a button):
<p><a class="btn btn-success" href="checkout.aspx"><i class="icon-shopping-cart icon-white"></i> Checkout</a></p>
I also have the same behaviour when using a 'real' button, marked up as follows:
<p><input type="submit" name="ctl00$cphMainContent$btnProceedToCustomerDetails" value="Next: Your details" onclick="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions("ctl00$cphMainContent$btnProceedToCustomerDetails", "", true, "", "", false, false))" id="cphMainContent_btnProceedToCustomerDetails" class="btn btn-primary" /></p>
In both cases, the buttons render in a grey, unreadable state and then sort of 'fill up' in green colour when you hover over, until it is about 75% filled up and then stops filling up.
Here's some images
The <a class="btn btn-success">
On load (before mouseover)
When you put your mouse over it, it fills up with colour from the bottom up in about 0.5 seconds, finishing up looking like this:
The <input type="submit" class="btn btn-primary">
On load (before mouseover)
After mouseover, again it fills up with colour from bottom up, in about 0.5 seconds, and looks like this:
Like I say, this only happens when using Firefox, and only when looking at localhost. Other browsers are fine. I am using a freshly downloaded copy of bootstrap.js (downloaded today) with no amendments, I only include one other css file, and even when I don't include it, it's the same behaviour.
I ran into this problem earlier today. This link: twitter bootstrap button changes rendering oddly in firefox and chrome helped me.
In my css, I applied the following:
.btn-primary, .btn-danger, .btn-success { background-image: none; filter: none;}
It worked. My pages now render correctly in firefox. Chrome worked fine for me.
After lots of efforts, I was finally able to pin down this issue to a specific CSS-Hack in Twitter Bootstrap.
Removing * (asterisk) from *background-image of btn-primary and other similar classes resolves this issue.
But the problem itself is not in the CSS. It has got to do with the implementation.
For example, I was using AjaxMin to minify and combine CSS and since *property is not a valid CSS, Ajaxmin was ignoring it rendering the final CSS without those properties. Buggy button effects being one such side-effect.
I'm trying to make a "clickable" region.
<a
style="display: block"
href="http://stackoverflow.com">
StackOverflow
</a>
A is an inline element but the CSS made it a block.
If the above is valid, then the following should be valid too:
<a
style="display: block"
href="http://stackoverflow.com">
<div>Some DIV that links to StackOverflow</div>
</a>
But validator.w3.org shouldn't be flagging it as invalid (which it is right now).
If it is invalid, what would be the most proper way to make a block element "clickable" and redirects to an arbitrary page. I'm aware I can use JS onclick to achieve this behaviour, but how will Google see this?
The validator is correct - you can't put <div> inside <a>, no matter what you do afterwards with CSS.
The proper thing to do is what you did in your first code block - <a style="display: block;">
If you want something inside that you can do <a style="display: block;"><span style="display: block;">
Don't confuse valid HTML with valid CSS. It is valid to use the display css property to make inline elements block. It is not valid to put block HTML elements within inline ones.
It doesn't follow that the one being valid implies the other has to be. There are nesting rules for HTML, and div-within-anchor doesn't fit them, which is why validator.w3.org is giving you a hard time.
If you truly must have a div, rather than text, images or <span style="display: block">s, that's clickable, then yes, you will have to use an onclick event. Google will not understand or acknowledge the existence of the link. (You may be able to cope with this by having an anchor on something that anchors can apply to, in addition to the onclick div.)
Something I've done in the past with this sort of problem is invoke the click on the parent element (My example uses jQuery):
<div class="link">
Visit Google
</div>
$(".link").click(function(){
document.location = $(this).find("a:first").attr("href");
});
With styles you could make the entire area appear to be the link by setting the cursor, a roll-over state, etc.
First you need to know whether you want to use strict or transitional XHTML (frameset is not useful here). Then you look into the DTD (link) and you'll see that A cannot have a DIV inside.
Why don't you use an area tag for this? It is supposed to define the clickable area in an imagemap.
Google bots now follow simple javascript links, so using JS on the onClick event of your div is an option. Other search engine bots don't do that, but sooner or later they will.
More info in this article.