Legitimately hide/prevent Rich Snippet html from rendering on screen - is this OK to do? - css

I am using rich snippets on my site, I have all of the code for them in the footer so that they are centrally located and easy to access. I do not want the text around these snippets rendered on the page because that info is elsewhere on the site. Is it ok to hide this text by using style="display:none" or will Google ignore the rich snippet entirely because the fields are hidden?
<!-- start rich snippet code -->
<div itemscope itemtype="http://schema.org/LocalBusiness">
<span itemprop="name" style="display:none">My Business Name</span>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
<span itemprop="streetAddress" style="display:none">123 Example Street, Suite 456</span>
<span itemprop="addressLocality" style="display:none">Major City</span>
<span itemprop="addressRegion" style="display:none">NY</span>
<span itemprop="postalCode" style="display:none">12345</span>
<span itemprop="addressCountry" style="display:none">US</span>
</div>
<span itemprop="telephone" style="display:none">(123) 456-7890</span>
<a itemprop="URL" style="display:none">http://www.mycompanysite.com/</a>
</div>
<!-- end rich snippet code -->
Any info would be much appreciated! Thanks in advance!

As #Diodeus said, ideally you'd have these rich snippets on the actual info that is shown to the user elsewhere on the site. Duplicating it is usually unnecessary.
Yes, Google may well ignore this content based on the display:nones. Can I ask why you're setting it on each element rather than just once on the highest level div?
A way around the display:none potential SEO issue would be to hide it in a different way. For example give the parent div a class of .visuallyhidden and add this to your stylesheet:
.visuallyhidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}

I would like to mention that Google tries heavily (using combination of algorithmic and manual things) to find websites which illegitimately use hidden text.
The typical penalty for that would be a removal from index for 30 days. However, you should not be concerned if you use hidden fields legitimate ways.
There is a very nice article Eric Enge Interviews Google's Matt Cutts regarding Google attitude toward illegitimately use of hidden text.

Have a look at this: https://sites.google.com/site/webmasterhelpforum/en/faq-rich-snippets and search for the word 'tempting'.
' It can be tempting to add all the content relevant for a rich snippet
in one place on the page, mark it up, and then hide the entire block
of text using CSS or other techniques. Don't do this! Mark up the
content where it already exists. Except in special circumstances ... '
It might seem like a clever idea to hide elements in a more complex way than by just display:none but, and i guess the same can be applied for hidden honeypot form fields, you are not the only one who can think of that.
Note: It is as easy to determine if a field is hidden by display:none as it is by margin:0; padding:0; width:1px; height:1px; overflow:hidden or by position:absolute; top:-[a value bigger than the page height]px or by something similar.
People would rich-snippet everything as an Apple product page if it would be ok to hide the snippet and provide any other kind of information on the porn - i mean page.
You got all that information already hanging out on the site, so just add the correct microdata tags to the corresponding text passages and google (other search engines, too by the way) will be happy.
So, for example, if your main page title already exists, put the itemprop="description" tag in the <div> tag thats is wrapping the title and you should be fine.
:)

Related

Should aria-label be used to describe user generated content like username links?

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!

How "safe" are Angular 2 custom html tags? (selectors: Custom tags vs. Custom attributes)

This is a question regarding Angular 2 selectors, Custom tags vs. Custom attributes, SEO and browser rendering.
When I first started to look over Angular 2, the very first thing I did when following their quickstart, right of the bat, was to change my selector to '[my-component]' (attribute selector) instead of 'my-component' (tag selector), so I could have <div my-component></div> in my html instead of <my-component></my-component>, which isn't valid html. So I would write html according to standards. Well, at least pretty close to standards (because my-component isn't a valid html attribute, but I could live with only that html validation error)
Then, at some point in a video on youtube, someone from the angular team mentioned that we should use the tag selector, performance wise at least.
Alright I said, screw html validation... or shouldn't I?
So:
Say I ignore the W3C screaming about my html being completely invalid because of the <custom-tags>. I actually have another bigger and more real concern: how does this impact SEO?
I mean don't just think client-side app, because in the real world (and for my angular 2 project as well) I also have server-side rendering, for 2 very important reasons: SEO and Fast initial rendering of the site to the user for that initial view, before the app bootstraps. You can not have a very high traffic SPA otherwise.
Sure, google will crawl my site, regardless of the tags I use, but will it rank it the same in both scenarios: one with <custom-make-believe-tags> and the other with only standard html tags?
Let's talk browsers and css:
As I started to build my first SPA site in Angular 2, I was immediately faced with another concern:
Say (in a non SPA site) I have the following html markup:
<header>
<a class="logo">
...
</a>
<div class="widgets">
<form class="frm-quicksearch"> ... </form>
<div class="dropdown">
<!-- a user dropdown menu here -->
</div>
</div>
</header>
<div class="video-listing">
<div class="video-item"> ... </div>
<div class="video-item"> ... </div>
...
</div>
Angular 2 wise I would have the following component tree:
<header-component>
<logo-component></logo-component>
<widgets-component>
<quicksearch-component></quicksearch-component>
<dropdown-component></dropdown-component>
</widgets-component>
</header-component>
<video-listing-component>
<video-item-component></video-item-component>
...
</video-listing-component>
Now, I have 2 options. Let's just take the <video-listing-component> for example, to keep this simple... I either
A) place the entire standard html tags which I already have (<div class="video-item"></div>) within the <video-item-component> tag, and once rendered will result in this:
<video-listing-component>
<div class="video-listing>
<video-item-component>
<div class="video-item>...</div>
</video-item-component>
...
...
</div>
</video-listing-component>
OR:
B) Only put the content of <div class="video-item"> directly into my <video-item-component> component and adding the required class (class="video-item") for styling on the component tag, resulting in something like this:
<video-listing-component class="video-listing">
<video-item-component class="video-item"></video-item-component>
<video-item-component class="video-item"></video-item-component>
...
</video-listing-component>
Either way (A or B), the browser renders everything just fine.
BUT if you take a closer look (after everything is rendered in the dom, of course), by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I don't get it how come the browser still renders everything as you would want to see it, I mean in the first case (A):
While having float: left; width: 25%; on the div class="video-item", but each of these divs being within a <video-item-component> tag, which doesn't have any styling... Isn't it just a fortunate side-effect that the browser renders everything as you'd expect? With all the <div class="video-item"> floating next to eachother, even though each of them are within another tag, the <video-item-component> which does NOT have float: left? I've tested on IE10+, Firefox, Chrome, all fine. Is it just fortunate or is there a solid explanation for this and we can safely rely for this kind of markup to be rendered as we'd expect by all (or at least most) browsers?
Second case (B):
If we use classes and styling directly on the custom tags (<video-item-component>)... again, everything shows up fine. But as far as I know, we shouldn't style custom components, right? Isn't this also just a fortunate expected outcome? Or is this fine also? I don't know, maybe I'm still living in 2009... am I?
Which of these 2 approaches (A or B) would be the recommended one? Or are both just fine?
I have no ideea!!
EDIT:
D'oh, thanks Günter Zöchbauer. Yeah, since my divs have float: left, that's why the (custom or not) tag they're wrapped in doesn't expand it's height. Seems I've forgotten how css works since I started to look over Angular 2:)
But one thing still remains:
If I set a percentage width on a block element (call it E), I would assume it takes x% of it's immediate parent. If I set float: left, I would expect floating within the immediate parent. In my A case, since the immediate parent is a custom tag with no display type and no width, I would expect for things to break somehow, but still... my E elements behave like their parent isn't the custom tag they're each wrapped in, but the next one in the dom (which is <div class="video-listing> in my case). And they occupy x% of that and they float within that. I don't expect this to be normal, I would think this is just a fortunate effect, and I'm afraid that one day, after some browser update... I'll wake up to find all my Angular 2 sites looking completely broken.
So... are both A and B an equally proper approach? Or am I doing it wrong in case A?
EDIT2:
Let's simplify things a bit. As I got part of my question answered, let's take another example of generated html (simplified a bit, with inlined css):
<footer>
<angular-component-left>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-left>
<angular-component-right>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-right>
</footer>
In the original, not yet implemented html (whithout <angular-component-...>, those divs should float left and each occupy 50% of the <footer>. Surprisingly, once they're wrapped in the <angular-component-...> custom tags, they do the same: occupy 50% of the footer. But this just seems like good fortune to me, dumb luck... Unintended effect.
So, is it or isn't it "dumb luck"?
Should I leave it like that, or rewrite so instead of the above code, I would have something like this:
<footer>
<angular-component-left style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-left>
<angular-component-right style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-right>
</footer>
Note that the inline styling is introduced here for simplicity, I would actually have a class instead which would be in an external css file included in the <head> of my document, not through style or styleUrls from my angular components.
The issue is your HTML validator. The - in the element name is required for elements to be treated as custom elements and it is valid HTML5. Angular doesn't require - in element names but it's good practice.
Check for example https://www.w3.org/TR/custom-elements/#registering-custom-elements (search for x-foo) or https://w3c.github.io/webcomponents/spec/custom/#custom-elements-custom-tag-example. I'm sure this dash rule is specified somewhere but wasn't able to find the spec. It is for example required in Polymer that depends on elements being proper custom elements while this doesn't matter much in Angular. The only difference as far as I know is that when you query the element, you get a HTMLUnknownElement when the - is missing in the name and a HTMLElement when it contains a -.
See also this question I asked a few years ago Why does Angular not need a dash in component name
BUT if you take a closer look, by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I just don't get it how come the browser still renders everything as you would want to see it
I'm not sure I understand this question. When Angular processes the template it adds the content dynamically. When you see the content in the browser than it's also available in the DOM and has actual dimensions.
Search engine crawlers are able to process pages that are generated by JavaScript. If this isn't enough, server-side rendered pages can provide static HTML to crawlers that contain the whole view.

CSS to open text box when clicking on image

I have a SharePoint 2010 site and would like to use CSS only in the wikipage.
On my page I have a paragraph of information and at the end of it, has a question. After the viewers read the information and the question I would like them to be able to click on an image that says 'answer'. When clicking on the 'answer' image a text box comes up under the question with the answer. I would like the answer to stay on the page, not just hovering over the image.
My preference is to do this solely in css. I don't think I have the capabilities to do it in javascript.
I'm open to both options, I guess. If it is javascript can it be done inline?
Like mentioned by #JofryHS, css doesn't really respond to clicks.
Using inline js click handlers isn't great as it'll leave you having to repeat yourself a lot, but from the sounds of things you're fighting against not having enough access to Sharepoint (sigh, corporate networks).
This uses an inline click handler to show the answer:
<div class="question" id="q1">
What colour is the sky?
<button class="answerButton" onClick="document.getElementById('q1Answer').style.display='block'">Answer</button>
<div class="answer" id="q1Answer">
Overcast and grey, because I live in the UK.
</div>
</div>
<div class="question" id="q2">
Why does it always rain on me?
<button class="answerButton" onClick="document.getElementById('q2Answer').style.display='block'">Answer</button>
<div class="answer" id="q2Answer">
I'd have thought you figured this out already... It's Britain, of course it always rains on you!
</div>
</div>
the answers are hidden using css (note the display:none inside the .answer block):
.answer {
display:none;
background-color:#e5e5ff;
padding:15px;
}
.question {
background-color:#f5f5f5;
padding:15px;
border-radius:5px;
margin:7px;
}
Essentially, all the onClick does is change the css of the answer from display:none to display:block, rendering the answer visible.
There's also a tad of css to make it look shinier, and here's a demo jsfiddle

what is the correct way to code incoming links for SEO?

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.

Apply a href-like attribute to non-<a> elements

I've been working on a page where there are several entries contained in different <div>s. Each is only a title linked to a page, an image and a short description. However, the description may contain arbitrary tags, including <a> tags.
Since these are pretty straightforward and the actual link isn't that big, I've made it so a click on the <div> will call location.href = (link URL). However, that's a pretty sad thing, because it's browser-unfriendly: for instance, under Google Chrome, a middle-click on one of said <div>s won't open the link in a new tab.
Considering you shouldn't nest <a> tags, is it possible to make any element in XHTML behave like a link without resorting to Javascript?
I'm using XHTML 1.1, sent with the proper MIME type, and that's the only restriction I'm bound to.
Not really, no. Though it's worth reading Eric Meyer's thoughts on this. Also, it appears that HTML51 includes the capacity for any element to become a link, so it might be worth using that doctype instead of xhtml, if possible.
It's worth also adding that html 5 does allow for an <a> element to enclose block-level elements, see: http://www.brucelawson.co.uk/2008/any-element-linking-in-html-5/, example taken from the linked page:
Instead of:
<h3>Bruce Lawson as Obama's running mate!</h3>
<img src="bruce.jpg" alt="lovegod" />
<p>In answer to McCain's appointment of MILF, Sarah Palin, Obama hires DILF, Bruce Lawson, as his running mate. Read more!</p>
you can say:
<a href="story.htm">
<h3>Bruce Lawson as Obama's running mate!</h3>
<img src="bruce.jpg" alt="lovegod" />
<p>In answer to McCain's appointment of MILF, Sarah Palin, Obama hires DILF, Bruce Lawson, as his running mate. Read more!</p>
</a>
Updated to mention possible inaccuracy
1: I may have misinterpreted part of the document to which I linked, having tried to find support for my claim that '...appears that HTML5...any element to become a link' (in the W3C's html 5 overview) it doesn't seem to be there. I think I was over-encouraged when I saw Meyer's proposal to include that possibility.
I'm too gullible, and naive... =/
If you want a link to cover an entire div, an idea would be to create an empty <a> tag as the first child:
<div class="covered-div">
<a class="cover-link" href="/my-link"></a>
<!-- other content as usual -->
</div>
div.covered-div {
position: relative;
}
a.cover-link {
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
}
This works especially great when using <ul> to create block sections or slideshows and you want the whole slide to be a link (instead of simply the text on the slide). In the case of an <li> it's not valid to wrap it with an <a> so you'd have to put the cover link inside the item and use CSS to expand it over the entire <li> block.
Do note that having it as the first child means it will make other links or buttons inside the text unreachable by clicks. If you want them to be clickable, then you'd have to make it the last child instead.

Resources