Knowing that search engine crawlers have limited JavaScript support, I went to see if Google thinks his page links to paypal or not.

If you search in google for link:www.paypal.co.uk site:bilaw.al, you will see that his post shows up.

To check I wasn’t getting a false positive, I tried a slightly different URL.

If you search for link:www.paypal.com site:bilaw.al instead, you get no results.

Is it a problem? Can it be exploited for profit? Not as far as I’m aware, beyond damaging the quality of Google’s search engine data.

Take the following example: user tabs onto a select element and then uses the arrow key to move through the list. In IE (tested versions 7-9), this triggers the change event whereas other browsers will wait until you’ve moved off the element.

Try this demo on jsfiddle, it will alert the value of the option you’ve selected when ‘change’ event gets fired.

If you are using your select element for navigating to another page, the keyboard user will never be able to get past the first and second item in your list. If you are using the select element for loading in more content via AJAX (e.g. updating other field items based on a select box selection is quite common), then you are going to be hitting your server far more than necessary.

The solution is to bind to blur, click and keydown for IE and change for everything else (should include touch devices), and then a) filter out keypresses that aren’t spacebar or enter and b) check to see if the selected option has actually changed. The below code uses jQuery, but it is all possible via native JS or other libraries. Sadly it relies on checking the browser’s user agent as there isn’t a feature you can test for (if I’ve overlooked something I’d love to hear about it).

Have a look at the accessibile version on jsfiddle

var somemodule = (function () {
  var obj = {
    //some code
    bindDOM: function () {
      var evts = "";
      //accessibility workaround: onchange is good for non-ie; keydown, click and blur is good for ie (but not for chrome)
      //unfortunately we cannot detect this with feature support so must rely on browser support
      if ($jQ.browser.msie) {
        evts = "keydown click blur";
      }
      else {
        evts = "change";
      }
      this.elem.on(evts, $jQ.proxy(this.onFooChange, this));
    },
    onFooChange: function (e) {
      var id;
      if (e.type !== "keydown" || (e.which === 13 || e.which === 32)) {
        id = $jQ(e.target).val();
        if (id !== this.currentFoo) {
          this.currentFoo = id;
          this.getBar(id);
        }
      }
    },
  };
  
  //more code
  return obj;
}());

If you’ve not seen it before, it is definitely worth the five minutes it will take you to scan through. Its results contradict a lot of received wisdom about screenreader behaviour, and highlight which features are actually really helpful (and which aren’t).

Main takeaways:

• Screenereader users love headings for navigating around a page
• 1.4% don’t have JS on, so your biggest user base without JS is going to be search bots.
• 82.7% update their software
• JAWS is still dominant, but decreasing due to uptake in NVDA (free) and VoiceOver (Mac, iOS)
• CAPTCHA is still a massive pain. Only Flash is worse for difficulty
• Quite a lot are using mobiles with screenreaders

Here was our problem:
When dragging a sortable element, positioning was fine unless you were scrolled down the page a little.

After some trial and error, we found it was created by a combination of body{offset-x: hidden;} and position:relative on one of the parent elements of the sortable widget.

Now we don’t want to go removing things from other people’s pages to fix our work, because it will almost certainly break something else (these are templates, so the risk is high and regression testing a big task). The solution was to put offset-x: auto on the same element that gets scrollable applied to it.

This is due to get fixed in jQuery UI 2 as they rewrite the sortable plugin.

1. Don’t install your Android SDK in Program Files, or any other folder with a space in it. Eclipse will fail on the build, and uninstalling and reinstalling the SDK somewhere else is just a pain.
2. If you want to deploy to your device in developer mode and you’re on windows, you’ll need the USB driver. This is buried in the Android SDK installation guide
3. Another way to deploy to your device is plain old file transfer. Unlike iOS, you don’t need a specific developer or enterprise license to do this. This involves exporting a signed app, which is a bit more involved.
   • Luckily http://www.androiddevelopment.org/2009/01/19/signing-an-android-application-for-real-life-mobile-device-usage-installation/ tells you all you need to know. You can now however create a signed application through Eclipse export, so the last step can be missed.
   • Once you have a signed app, all you need to do is connect your device to your PC, go into file transfer mode and copy across the apk file.
   • To install it, you’ll finally need to find the .apk file in My files and click to install. Job done. You can delete the apk file and open the application as normal from the Applications screen.

Excel exports to HTML but fills it with rubbish. Using regular expression-based find and replace in my IDE is normally fine, but with a file this large it froze. Command line is the only solution in such a case.

On the mac Terminal, the sed command is a little bit different from what you might use on *nix (and totally different from what you would do with a PC).

After manually cleaning up the head section, the following 3 commands cleaned up the table cells in my export:

sed -i '' 's/class=xl[0-9]*//g' Table.htm
sed -i '' 's/width=[0-9]*//g' Table.htm
sed -i '' 's/height=[0-9]*//g' Table.htm

sed is a stream editor, the -i switch makes it edit in place, the ” is where Mac differs. It requires a backup file name even if that is blank (therefore overwriting the original file) whereas for *nix it is optional.

The next bit is the regular expression and these particular ones are tailored to remove the class, width and height attributes that Excel adds to all the <td> elements. Finally, the name of the file to edit goes in.

I’ve made use of JSON.js for handling JSON and jQuery in the code below for some convenience, you should be able to swap out for your library of choice.

Some caveats:

• potential for data collisions if you edit on another device or browser between saving offline and synching.
  • you could feasibly solve this by dynamically building duplicate form fields that sit next to the server version and contain the local data.  A button to copy across from one field to another is quite a simple trick.
• you get 5MB of localstorage per domain, meaning it isn’t suitable for documents over 5000 characters (including input names and syntax) or for saving a vast amount of forms without synchronising. There’s a warning provided but it happens at a stage where the storage is already refusing to save, so the user has to copy their content to another file
• local storage only handles text in key-value strings, so you can’t save your data as a JSON object, you have to stringify it.
• Try…Catch is not my favourite way of handling detection or errors, but in the 2 cases below it is the only practical option

Inspiration:

• http://diveintohtml5.org/storage.html
• http://paperkilledrock.com/2010/05/html5-localstorage-part-one/

/*
OnOffApp makes use of local storage to save form input locally when a user is offline and allow them to synchronise it when they are back online again.
Dependencies:	json.js http://www.json.org/
				jQuery http://www.jquery.com/
Config:			when calling init, there are 5 items that can be optionally configured
				id
					unique identifier for the form to be used in local storage as the key
				field_id
					jQuery object of the field that supplies the id, used to find the parent form, otherwise form defaults to all forms on page
				synchMsg
					HTML to display to inform the user they have items to be synchronised to the server
				synchBtn
					HTML for synchronising button
				warnMsg
					HTML for the message to show the user when local storage is full and data cannot be saved
*/

OnOffApp = (function(){
	
	//variables available throughout the function
	var UID;
	var postForm = $("form");
	var holder = $("<div id=\"synchMsg\"></div>");
	var config = {};
	
	//initialiser function
	//@argument usrconfig: an object of config options
	var init = function(usrconfig){
		setup_config(usrconfig);
		var submit_button = postForm.delegate("input[type=submit]", "click", submit_click);
		if(retrieveLocalData() === true){
			synchMessage();
		}
		$(window).bind("online", synchMessage);
		$(window).bind("offline", synchMessage_remove);
	};
	
	//set-up defaults for user configurable messages and overwrite where specified
	//@arguments usrconfig: object of user-set options
	//@returns the config object
	var setup_config = function(usrconfig){
		var id = location.href;
		config.synchMsg = "<p class=\"synch\">Locally saved data can be synchronised now</p>";
		config.synchBtn = "<input type=\"submit\" value=\"Synch\" class=\"synch\" />";
		config.warnMsg = "<p class=\"warn\">Local storage is full.</p>";
		 for(var i in usrconfig){
			if(i === "id"){
				id = usrconfig[i].val();
				continue;
			}
			else if(i === "field_id"){
				postForm = usrconfig[i].closest("form");
				continue;
			}
			config[i] = usrconfig[i];
		 }
		 UID = "uID-" + id;
		 return config;
	};
	
	//submit button clicked
	//detect if we are online.  If so, grab any saved data as well as existing data and save via AJAX, if not save to local storage
	var submit_click = function(e){
		e.preventDefault();
		var data = getFormInput();
		var savedData = $.parseJSON(getLocalData());
		if(navigator.onLine){
			saveToServer($.extend({},savedData,data));
		}
		else{
			setLocalData(JSON.stringify(data));
		}
	};
	
	//get the form inputs and put into object notation
	//@returns an object
	var getFormInput = function(){
		var formArray = postForm.serializeArray(),
			o = {};
			$.each(formArray, function(){
				o[this.name] = this.value;
			});
		return o;
	};
	
	//get localStorage data
	//@returns string of locally stored data or an empty string
	var getLocalData = function(){
		return localStorage.getItem(UID) || "";
	};
	
	//set localStorage data, if out of space add a warning instead
	var setLocalData = function(data){
		try {
			localStorage.setItem(UID, data);
		}
		catch (e) {
			if (e == QUOTA_EXCEEDED_ERR) {
				postForm.prepend(config.warnMsg);
			}
		}
	};
	
	//get the data from localStorage and add saved values into the relevant fields
	//@returns true or false depending on whether there was locally stored data
	var retrieveLocalData = function(){
		var oldData = getLocalData();
		if(oldData !== ""){
			var fields = $.parseJSON(oldData),
				field;
			$.each(fields, function(key, val){
				field = $("[name=" + key + "]");
				if(field.length > 0){
					if(field.is(":checkbox") || field.is(":radio")){
						field.attr("checked", "checked");
					}
					else{
						field.val(val);
					}
				}
			});
			return true;
		}
		return false;
	};
	
	//if you have localStorage data and you are online, prompt the user to synchronise their data (i.e. save it to the server)
	var synchMessage = function(){
		if(navigator.onLine && getLocalData() !== ""){
			if($("#synchMsg").length === 0){
				holder.append(config.synchMsg).append(config.synchBtn);
				postForm.prepend(holder);
			}
			else{
				holder.show();
			}
		}
	};
	
	//remove the synch message
	var synchMessage_remove = function(){
		holder.hide();
	};
	
	//save form data to the server via AJAX
	var saveToServer = function(data){
		var url = postForm.attr("action");
		var params = $.param(data);
		var me = this;
		$.ajax({
			method: "post",
			url: url,
			data: params,
			success: savedSuccess(data)
		});
	};
	
	//after data saved to server, remove the saved data from localStorage and remove the synchronise message
	var savedSuccess = function(){
		localStorage.removeItem(UID);
		synchMessage_remove();
	};
	
	//interfacing methods and properties
	return {
		init: init
	};
}());


//For the purposes of the demo, there is a hidden input with id "post_id" with the unique identifier for the post (like WordPress)
$(document).ready(function(){
	try {
		if('localStorage' in window && window['localStorage'] !== null){
			OnOffApp.init({
				"id_field" : $("#post_id"),
				"id" : $("#post_id").val(),
				"warnMsg" : "<p class=\"warn\">Sorry, your local storage is full up.  Please copy and save your latest work to a text file and go online to synchronise your work as soon as you can.</p>",
				"synchMsg" : "<p class=\"synch\">You have locally saved data that you can now synchronise with the live server</p>"
			});
		}
	}
	catch(e) {
		return false;
	}
});

The following sources got me started with offline caching in the first place.  If you need more background to what application cache is, you should read these first.

• http://jonathanstark.com/blog/2009/09/27/debugging-html-5-offline-application-cache/
• http://diveintohtml5.org/offline.html
• http://www.slideshare.net/jonathanstark/offline-application-cache

My main problem with it is that every time I make a change to my files, I have to go into my cache.manifest file and update a comment somewhere.  Why? Because the application cache is checked for updates first.  If there are no updates, it just stops.  It doesn’t check any of the underlying files for updates.

That’s efficient in terms of client-server communication by reducing the amount of calls to check whether cached versions can be used or need updated, but its also really dumb, and a nuisance to work with.  You start relying on people to remember on these little jobs, and that introduces a risk of human error.  It’s not an acceptable risk because it is an avoidable risk.

Luckily we can use server-side technology to generate our cache manifests and grab the file update timestamp.  Here’s what I’ve learned thus far:

1. the manifest attribute on the html element doesn’t have to point to a *.manifest file.  It can point to a manifest.php file (for example).
2. in the dynamic page, set your header to serve up the right mime type.  In PHP, this is
   <? php header("Content-Type: text/cache-manifest;charset=utf-8"); ?>
3. find the most recently updated file date and echo it out in a comment. If there’s not been a change, the comment will remain the same in the generated code as it is in the cached version.   In my example below I’m statically setting which files I want to be in the cache. Jonathan Stark shows a way of going through the file system to cache all files if you’d rather.  You’d just add the timestamp bits in where required.

<?php
	header("Content-Type: text/cache-manifest;charset=utf-8");
	$cache_files = array(
					"testhtml5.htm",
					"testinvisdyn.php",
					"testhtml5.css",
					"testhtml5.js",
					"jquery.js",
					"json.js"
					);
	$fallback_files = array(
						"/" => "fallback/testhtml5fall.htm"
					   );
?>
CACHE MANIFEST
NETWORK:
*
CACHE:
<?php
	$cache_mod = 0;
	foreach($cache_files as $f){
		echo "$f \n";
		$last_mod = filemtime($f);
		if($last_mod > $cache_mod){
			$cache_mod = $last_mod;
		}
	}
	unset($f);
	
	echo "# $cache_mod \n";
?>

FALLBACK:
<?php
	$cache_mod = 0;
	foreach($fallback_files as $d => $f){
		echo "$d $f \n";
		$last_mod = filemtime($f);
		if($last_mod > $cache_mod){
			$cache_mod = $last_mod;
		}
	}
	unset($f);
	unset($d);
	
	echo "# $cache_mod \n";
?>

Disclaimer: I’m not a PHP developer, its not one of my professional competencies.  If the above code sucks, please respond in the comments and I’ll fix it up.

This checklist should help you check you’ve got your main bases covered.

Tools you’ll need

• Firefox
  • Web developer toolbar
  • Firebug
  • YSlow
• IE
  • IE developer toolbar
  • AIS web accessibility toolbar
  • Virtual PC for various IE versions.   There’s no permanent URL for this, so search microsoft.com for the latest version.

Checklist

1. Having stable, valid code will save you a lot of debugging pain.  If you know your code is sound, then it is most likely a browser fault that is the cause of any further bugs from here onwards
   1. Run the W3C HTML validator on all pages and correct
   2. Run the W3C CSS validator on all pages and correct
   3. Run the WAI tool on all pages.
   4. Run your JavaScript code through JSLint
   5. If you are hoping to have good coverage on mobiles, run mobileOK on your pages
2. Check the static text content for spelling and grammar.  Mistakes here will just make you look stupid and unprofessional.
3. Check you’ve done a full run-through of the site in each supported browser.  You do have an agreed browser matrix don’t you?
4. View your site without CSS, can you still read everything?
5. Open up each template in a new tab and run through them using CTRL+Tab to check your layouts are all the same – do the edges of the main layout boxes sit at the same position on each page or do they jump a few pixels? Is the main heading at the same position (presuming your design intends that)?
6. Run through all pages at 1024×768 resolution (or 800×600 if you are required to support it), do you have to scroll horizontally?
7. Try using your site without JavaScript.   If you can’t then non-JS users will not be able to use your site and search bots will not be able to index all your content
8. Have you remembered your print stylesheet? Print preview your pages and actually print the most likely to be printed (e.g. an article template).  Sometimes the preview lies.
9. If you are using flash, check your non-flash fall-back works.  You do have a fall-back right?
10. If you are using embedded media, check there is a fall-back for those without it and a link to the vendor site to download the plugin.
11. If you have static links in the site, run a linkchecker.  I’ve used Xenu in the past which is fairly good, and free.
12. Run your pages through YSlow to find any major issues
13. If you are using XMLHttpRequest (often referred to as AJAX), test what happens when the server returns a failure (e.g. a 404 or 500 rather than 200 OK)
14. Accessibility checklist (this isn’t a definitive list, if for example your navigation is inconsistent between pages then you’ve a problem that requires the team going back to the drawing board to solve)
    1. Your content is in a sensible order in the HTML.  If you are not sure, looking at the page with CSS off will help you decide.
       • e.g. you do not break up your main content paragraphs to line up your right hand promo boxes
    2. Go through a few pages with a screenreader and keyboard.
       • Can you get to all your links and form fields without the mouse?
       • Can you hear all your content?
       • Is hidden content still ‘perceivable’?  If you are hiding with display none or visibility hidden, screenreaders will ignore that content, but if you use position absolute with left being a large negative number, it will still get read out to the user.
    3. Test all your interactive features (e.g. accordions or sliders) with a keyboard, also is the screenreader able to read the information in them? (see my previous post about focus)
    4. Page sections are marked out with headings
    5. Headings do not skip levels.  This should be picked up in the HTML validation.
    6. Have a ‘skip to content’ link at the top of your page
    7. You can pause any animation or movement that is on by default
    8. All forms have a submit button
       • that especially includes select field (dropdown) navigation, it should never be executed from the onchange or onselect events
    9. Text can be resized in all browsers, IE6 does it differently so be sure to test if you support it
    10. All form fields have explicit labels (i.e. you use the for attribute to refer to the field’s ID rather than wrapping the field inside the label element)
    11. Missing alt attributes is a common mistake, but will be picked up in your HTML validation
    12. Foreground and background colours have sufficient contrast
    13. Testing for seizure-causing animation is difficult, but the safest course of action is not to flash anything more than 3 times in 1 second.
    14. Image maps have their links duplicated underneath as a list
    15. Any static links have sensible link text that indicates where the link will go on its own without the rest of the paragraph text around it.
    16. Any linked images have sensible alt text that indicates on its own where the link will go
    17. Specify what language the page is in.  The HTML validator will pick it up if it is missing.
    18. Tables of data have a summary and scope for each column and each row is defined

First, Phil Archer from the W3C presented Mobile Best Practice at London Web Standards Group

It’s an excellent presentation and worth a full read, but the gist of it is:

• think about mobile users not mobile devices.  if nothing else, mobile devices are developing and improving their user experience as a fast rate which will probably get faster
• you don’t have to give mobile users the exact same page only tiny, if you stick to the theme of your content you’ll be helping them (compare http://news.bbc.co.uk/ on PC and mobile, or try http://news.bbc.co.uk/mobile which BBC news redirects to) BUT don’t make them remember a special mobile URL.  Detect and redirect your user.
• w3c have a very cool validator called mobileOK that estimates how well your page will perform on mobiles
• secondary windows including popups, frames, tables and image maps will cause mobile users inconvenience
• Progressive enhancement will pay off hugely
• That said, various mobile browser vendors don’t play well with @media=”handheld”.  See http://www.bushidodesigns.net/blog/?p=72 for the best way to serve up CSS for all devices

Then Firefox announced accelerometer detection (the thing in your iphone/nokia/laptop/wii that detects motion and direction) for 3.6.  Firefox has yet to crack the mobile devices platform, so this is a signal of intent.

Serendipity then took me to PPK’s Great Webkit Comparison table whose family now includes the browsers for android, iphone, bolt, palm pre and possibly blackberry in the near future.