Sitemorse Blog

The Linktarget issues reported under "AA" Accessibility are caused by having multiple links on a page that have the same "name" but link to different pages.

A good example I saw recently was on a fashion retailers site.  They had tabs under the banner for things like Men, Women, Denim, Lifestyle.  When you hover over a tab you get a hover box appear with the sub categories for the tab.  The problem was that under both the Men and Women tabs you had sub-categories like Shirts, Shorts, Footwear and Denim.  When you moved the mouse over a sub-category the hover-box came up with just the same word.  So someone using a screen reader reading out the links on the page would struggle to know whether they'd end up at women's shorts or men's shorts.  With Denim it's even worse because the link from the Denim tab as well as the ones under men's and women were all called Denim.

An easy way to remedy this is to use a Title attribute

title="Women's Shorts" href="Store/Browse.aspx?DepartmentId=Womens&amp;CategoryId=Womens_Shorts">Shorts</a>

Most of your navigation will probably be in your Templates so it's a relatively minor change that will have a big impact on the whole of your site

With the advent of our Snapshot product, which is aimed at people developing or updating Webpages, more and more organisations are wanting to test pages in their pre-production environments. (Often referred to as their staging site, development site, UAT site etc.)  The suggestions below would also work for testing Intranets.

Firstly let's be clear how Sitemorse works.  Like a browser Sitemorse makes GET requeststo your web server to fetch a web page and the files that make up the page.  Once downloaded the full suite of tests are run against each page. If we are running an audit we will continue to spider around your site until reaching either a page or time limit.

Snapshot works by passing the URL of the page being viewed in the browser to our servers which then test that page over the internet.  So for Snapshot to work the URL in the browser has to be one that would work from out on the internet as well as internally.  So http://dev/index.html would fail whereas http://dev.example.com/index.html would work.

It is therefore ESSENTIAL that the Webpages to be tested are "visible" to the Internet so Sitemorse can gain access to them.

I'm putting the word visible in quotes because we're not suggesting that you simply make your pre-production sites open to the Internet as if it were one of your production sites.  There are a couple of methods that our customers are using to allow Sitemorse access to their pre-production sites.

Option 1

Open up access to your pre-production sites but password protect them so that the general public can't gain access.

This is the simplest way.  We've seen people use new domains for this but more commonly people use sub-domains e.g. http://staging.example.com.  We've even seen people use sub-directories on their main site e.g. www.example.com/staging.  To stop people "stumbling" across the site you could give it a less obvious name http://stdev1.example.com

If you supply Sitemorse with a login we can configure the system to use this for any tests that are run (Snapshot, scheduled audit runs, ad-hoc audits etc).

Option 2

To make this even more secure you can specify that only traffic from a given IP address can actually get through to the pre-production server.

Sitemorse audits are run from a single, fixed IP address, so it is possible to open a port within a firewall through which only Sitemorse can gain read-only access to your pre-production sites.  Coupled with a login means that it is very secure indeed.

The IP address is 89.234.59.74

Please note IP addresses are liable (though highly unlikely) to change in the future without warning

When things go wrong they always go wrong at the worst possible time.  A rather glum view put somehow always works out to be true.  And it's true for people responsible for controlling their organisations websites.

So last week would be a bad time for a link on the Dept. for Culture, Media and Sport (www.culture.gov.uk) with a title of process of a General Election (which links to a page on the www.parliament.uk website) to go wrong.  And if that link was on the Home page it would probably be noticed and fixed pretty quick, right ?  Well, actually this link first failed at around 1pm on Friday 7^th May - yes that's right, just around the time when everyone would be looking for any info they could find about elections and hung Parliaments.  It was eventually fixed a little over four and a half hours later.

There's a couple of things that are a little alarming about this.

From a culture.gov.uk view point, this link wasn't buried in the depths of their website - it was right there on the front page.  Now most sites use some sort of monitoring service to measure availability and performance of their sites and it would be strange if they didn't use their Home page for this like most organisations do.  To mitigate this a little, the problem with many of these services is that they only measure availability and performance and they don't check the quality of the page the site serves up. So you can end up serving up rubbish with 100% availability with superb performance when what is actually needed is something a little more sophisticated which checks that the page is OK as well.

Now, looking at this from the www.parliament.uk site, I'd say that a page covering how elections are run would be a pretty key page on their site.  And if someone decided to move or rename such a page then you'd expect them to put what's called a "redirect" in place so that if anyone has a link to the original page any clicks on those links will automatically be redirected to the new page.  This is normal practice and happens all the time.  And indeed that's exactly what they did four and a half hours after making the change to solve the problem.

The people at culture.gov.uk probably blissfully unaware that the problem existed because they didn't solve the problem - the people at www.parliament.uk did.

The truth is that at end of the day, or in this case late afternoon, neither set of people come out well in this.

And, of course, the problem occurred at one of the most inconvenient of times possible.

Looking at the results of this years Client Survey it appears that Code Quality is not as high up the priority list as it perhaps should be.  It's not always obvious just what the implications can be if you don't keep on top of these errors.

When I'm running training sessions and discuss Code Quality I point out that although there is a W3C standard for HTML that browser must abide by, there is no standard for what the browsers should do when they come across non-standard code.  Should they ignore it or assume you meant something else ?

The discrepancies between what browsers do under these circumstances is one of the factors that lead to Webpages not rendering in the different browsers - and there's a proliferation of browsers out there especially with the increase in browsers on mobile devices.  With all these browsers out there it's becoming more and more difficult to ensure that your Webpages work across all browsers.

A key way to help with this, though it's not the only thing, is to ensure that all of your code is compliant with the W3C standard.

I came across an example yesterday of a Webpage that was completely jumbled by IE8 (including when I tried viewing the screen in "compatibility mode") yet when I viewed it in Firefox it was fine.  It was a real simple coding error where they'd try to put a couple of words in the Meta Description in double quotes.  This made all of the words after the first double quote (double quote is the delimiter for the Description) to be treated as Attributes, which meant they were all errors.

Here's what it looks like:

Clearly something that would have been spotted if the editor had viewed it in IE.

If they'd have checked the page with Snapshot they'd have had the error clearly pointed out to them both in the Page View and the Source View ==>

In the early days of XHTML many sites had problems where code was declared as HTML or XHTML when in fact there was a mixture of the two in both cases.  If Sitemorse had reported every infringement then most sites would have been reported as having thousands of errors under the Code Quality category and people would have felt overwhelmed by the volume of errors we were reporting.  As most browsers coped well with these errors and rendered the pages OK we didn't want to be in a position where either people gave up on Code Quality or were spending ages clearing problems that had no real impact on their sites.  With the volume of errors that would have been reported there was a definite possibility of being in a situation where people "couldn't see the wood for the trees."

We've kept an eye on this and now feel we can be more picky about the differences between HTML and XHTML.  Having previously been fairly relaxed about the use of XHTML features in HTML, and vice versa, we're now making a proper distinction between the two as most sites seem to have got the distinction correct nowadays.

An example of what might typically come up in reports is to do with "empty" tags, e.g. "<br>". These tags do not contain any content, and in HTML they should not have close-tags. In XHTML, all tags should have close-tags, so they must be written "<br />".

So in short:
HTML: <br>
XHTML: <br />

Other tags that this issue often crops up with include, for example, <link>, <meta>, <img>, <input> and <hr>.

The bottom line is if you declare that the code is HTML make sure it is, likewise for XHTML.

Anchor Points or Fragment Identifiers are used extensively to take users to particular parts of a Webpage.  A classic example of this being a site's FAQs page where you'd have a list of clickable FAQs at the top of the page that, when clicked, take you to the full text of the question and the answer which are either lower down the same page or perhaps are part of another page.

The problem comes when these are coded incorrectly or the page changes and the links no longer reflect what's actually on the target page.

Examples:

1. A clickable FAQ entry points to a Fragment Identifier called Q10 which should be located further down the page but Q10 doesn't exist. 
2. A clickable FAQ entry points to a Fragment Identifier called Q10 but there are TWO (or more) Q10s

These errors will be reported under Code Quality under the Unknownid for the first example and under the Bad value item for the second.  We added them to the Code Quality category as these types of error won't cause a failure in the same way as, say, a broken link would (though there are similarities) they just won't work as you intended them to.  For instance if you click on one of the clickable FAQs in the example and no Q10 Identifier exists the Webpage would remain in exactly the same place.  Or in the case of duplicate Q10 Identifiers the browser will take you to the FIRST instance of Q10 which may or may not be correct.

Fragment Identifiers may also be used by a site's Style Sheets (CSS) or by JavaScript on the site.  Again missing or duplicated Identifiers will cause unpredictable and, therefore, undesirable results.

Some sites will see these new checks impact their Code Quality score when they've made limited unrelated changes.  It's important that we extend the checks we do to identify issues on your websites.  The side effect of this could be that we find you more problems to fix but all of the issues we raise could be impacting the visitors to your site. 

There have been rumours around since November last year that Google either were already or were about to include the speed of your website as a criteria in their ranking algorithm.

A blog post Google fellow Amit Singhal and principal engineer Matt Cutts from the 9^th April now confirms that this is the case with the post stating that "Speeding up websites is important -- not just to site owners, but to all Internet users. Faster sites create happy users and we've seen in our internal studies that when a site responds slowly, visitors spend less time there"

Website owners now have another incentive to make sure that their sites perform at an acceptable level. A survey conducted by Forrester Consulting at the end of 2009 to examine eCommerce web site performance and its correlation with an on-line shopper's behaviour confirms Google's view . The most compelling results reveal that two seconds is the new threshold in terms of an average on-line shopper's expectation for a web page to load and 40 percent of shoppers will wait no more than three seconds before abandoning a retail or travel site.

Additional findings indicate that quick page loading is a key factor in a consumer's loyalty to an eCommerce site, especially for high spenders. 79 percent of on-line shoppers who experience a dissatisfying visit are less likely to buy from the same site again while 27 percent are less likely to buy from the same site's physical store, suggesting that the impact of a bad on-line experience will reach beyond the web and can result in lost store sales.  52 percent of on-line shoppers stated that quick page loading is important to their site loyalty.

I posted a couple of blog articles covering things to consider to improve your websites performance take a look here and at this one.

Do you know how fast your website is ?  How well does it perform during busy periods.?  As well as monitoring your key pages every, say, 15 mins. you need to also check your site more comprehensively to ensure there are no "problem" pages within the site.  So something that spiders through your site (in a similar way to the way Google does) that will report your average speed and identify any offending pages would be a useful addition to your armoury..

It's all very well creating league tables and making claims about who is best and who is worst.  But the measures used need to have some context and there might be another league table that casts a different light on the sites. 

In the Bowen Craggs Index of corporate website effectiveness league table we have Shell and BP in first and 2nd place.  And yet these two sites fail on a range of very basic quality and compliance measures that must surely call into question their effectiveness.  AstraZeneca, the only other UK site in the top ten, has clear performance issues which again must have an impact on its overall effectiveness.

And it's all very well looking at what "facilities" are available on a website for visitors and the sites use of Social Media etc.  But if the sites are littered with broken links, have basic accessibility issues and poor performance then surely they can't be claimed to be the most effective sites in the world !

To validate our reasoning and our capability to question these findings  we have taken 3 very basic requirements of a corporate website and, looking at the highest rated UK sites in the table, we offer some of the actual issues (we are more than happy to share exact details - the market needs far greater transparency) which we found on the 3 sites:

AstraZeneca - website performance

When looking at performance one of the key tests is 'time to wait' - how long does it take for anything to happen after you click a link.  In checking the top pages of the site, the average wait time of the slowest 10 items was just under 3.75 seconds.  One item leaves you sitting there for over 6 seconds before anything happens!

A 2009 survey by Forrester Consulting showed that 40% of visitors will wait no more than three seconds before abandoning a website.

Shell - website accessibility 

How can they be the top site when looking at accessibility, which Shell make great claims about on their website, they have basic failures like missing alt text on images and missing page titles ?

It's generally accepted that making sites accessible for people with disabilities not only fulfils your social responsibilities (and meets your legal obligations) but also makes your site much easier to use  for those people without disabilities.  A great win-win scenario.

If a site doesn't meet even the basic accessibility requirements then it is ineffective for a significant minority of the population.

BP - basic quality issues - broken links 

Again looking at the top pages of their website we found Webpages and some important IR documents (an area that should be key to a corporate website used for investor communications) contain broken links, and some have out of date links to pre-launch/staging servers. 

I found one link that just displays a completely blank page.  I would count that as pretty ineffective on lots of counts !

We are in the final stages of testing a new feature for the Sitemorse service that will test the syntax of any JavaScripts we find as we spider through a site.

JavaScript is in increasing use on all types of web sites, ranging from simple rollover
images and form validation scripts, to complex "Web 2.0"-style dynamic AJAX interactive web applications. These scripts are no less susceptible to coding errors and mistakes than the HTML code that makes up the rest of the web pages they appear on.

Up until now, there has been no way of automatically checking a web site for these errors. Sitemorse's new Javascript testing feature examines the Javascript code used on your site, be it "event handlers" processing keypresses and mouse clicks, or in-line or included scripts, and comprehensively examines it all for syntax errors.

Unlike syntax errors in your HTML that a browser might compensate for, these types of errors will prevent your scripts from performing their intended operation - with results ranging from faulty image rollovers, to missing analytics data, to forms that cannot be submitted, to pages whose major functions fail to operate correctly.

We're finalising the report layout of the results at the moment.  There will be a new section to cover JavaScript and the results will be formatted in a similar way to the Code Quality section.

Initially the results wont affect your Overall Score and will therefore not influence your ranking in our surveys.  Once we have the results from across the many hundreds of sites we audit we'll be in a better position to understand when we should look to include them.

We'll keep you posted on the launch date.

Following on from the previous post, looking at responsibility of providers, the twittering at Sitecore was a little frantic - we weren't trying to offer their client services people 'free' re-tweets, but we acknowledge their thanks for the assistance via this tweet from SitecoreUK to Sitemorse: "thx. agency has bn notified". Shame the Chairman was so aggressive and threatening - something to protect or worse, to hide?... a reminder of the email exchange.

We also noticed there were a number of questions around the capability of the CMS to support accessibility - based on their own marketing (http://www.sitecore.net/en/Products/Sitecore-CMS/Sitecore-feature-comparison.aspx) which states (under the "Site Control Tools" section) that they have an accessibility checker, the most basic of needs we would have thought would have been covered - missing "Alt" text for an image - especially on the home page of their international award winner... come on Sitecore, time to be a little more accurate in your products capability - advise clients of the limitations....

Here's the site, www.stokke.com/​en-us/​, that won Sitecore's International Site of the Year award for 2009.  That's quite an accolade !

So I did a quick Sitemorse Snapshot of the site's Home Page and found that the 3 main product images were missing AltTxt (that's a basic Priority 1 (A) Accessibility failure) and there were 3 associated links to separate product info pages which all said "Read more" (so those are all Priority 2 (AA) Accessibility failures (linktarget).  Both these errors are basic and should be identified by any Accessibility checking, which most CMS vendors claim that they do.

Oh, and from a usability point of view the page also has lots of Flash, so that won't look good on the new Apple iPad ! (or in the Opera browser that's used by the Wii and is probably problematic on several other platforms)

Here's the bottom of the page where the errors are

Here's a larger version

Back to my point on other blogs on this topic.  Are the people responsible for the site aware of these errors ? Would they be happy if they knew they existed ?  I wouldn't think so.  So perhaps they are under the misapprehension that these types of problems can't exist on their site.

More about Sitemorse at www.sitemorse.com