In an age where user feedback and interaction has become so popular, accessible forms have become that much more important. Many sites have already embraced making their forms accessible, and done a pretty good job of it, but inevitably some will still lack that little extra something – as small as an inappropriately named label through to no accessible features at all.

1. Using label tags

Labels should always be used and include the for attribute (e.g. <label for="name">). The value used should match the id of the input field that the label is being used for:

<label for="name">Name</label> <input type="text" id="name">

Labels for inputs, select dropdowns and textareas should precede the input, though labels for radio buttons and checkboxes should follow the input, as follows:

<input type="checkbox" id="terms"> <label for="terms">Accept our terms & conditions</label>


As many of you already know, the Web Content Accessibility Guidelines (WCAG) recommend a specific amount of contrast between backgrounds and text on your websites. Unfortunately, very few people probably actually test their websites to ensure that they meet those guidelines. As a color-blind person, I find a lot of websites that are extremely difficult to read because of poor contrast between backgrounds and text.

I’m honestly not sure why many of us (including myself, on many occasions) don’t check the color contrast on our websites. While it’s difficult to measure and quantify the contrast through conventional means, there are quite a few really nice tools that make it a snap.

When designing a website, there are key user behaviours that should be taken into account. But in order to take them into account, it helps to know them. Below are 10 of the more interesting and less well-known user behaviours that regularly occur in user testing:

People have banner blindness

People don’t notice banners. It’s been found in eye tracking studies their gaze literally avoids settling on any area that looks like an advert instead it seems people actively try to avoid looking at them. This effect is called banner blindness.

Banner blindness affects most people, and has a startling side effect. Useful areas of the site that are overly graphically designed (and end up looking like an advert) are ignored by users as though they were adverts.

I was listening to episode #194 of the BoagWorld podcast the other day. Part of the podcast included an interview with Gerry McGovern on the concept of focusing on user tasks. One of the main points made in the interview was that you need to focus on major tasks that your visitors want to accomplish when visiting your Web site and hide or even remove the extremely minor tasks. Following is an excerpt from the transcript of that interview:

everything affects everything else and people think if I add a piece of content, if I add a web page, if I you know… It’s just another page… its not… it’s going to do something positive and it’s not going to do anything negative

You at least added one link and you added one more search result that comes true and each one of those links and each one of those search results is like another sign post that can send somebody in the wrong direction.

…everything you do has three impacts. It impacts the navigation, it impacts the search, and it impacts the manageability of the website, but also that small task and small content has every bit of chance to impact the efficiency of a top task

This got me thinking. In large institutions, it’s often difficult to effectively preach the importance of reorganizing the site structure to eliminate or downplay the minor tasks, but there is something you can do to at least help your visitors a little bit.

For this session, Chisnell began by asking the audience for some of the main points we would like her to cover in the much shorter timespan she has today. To begin, someone asked the generic question about how we should be performing usability testing. I then asked, as advanced or “power” users, how do we, with limited resources, attempt to understand how the standard user will attempt to use our Web site. One other person asked if there were ways to increase or encourage participation in usability studies.

Online communities (facilitated by Web 2.0) have become very important over the past few years – not only to niche communities, but now to mainstream brands. Social networking is about human connection and links between people. The reasons why people join groups and social networks are typically that groups can:

• Provide encouragement and support
• Establish identity with others and fulfil the need to feel included
• Provide the outlet for some people to establish their need for recognition, social status, control and/or leadership
• Alternatively, provide the necessary control over aspects of lives for those who don’t want to be leaders (e.g. Weight Watchers)
• Help establish friends, relationships and the opportunity to interact with others

Historically group membership has served an evolutionary survival function – put simply, there’s safety in numbers

There’s been much research into group psychology but not so much about how this applies to a marketer trying to monetise an online community or introduce one to their brand. Here are some interesting phenomena about groups designed to help a brand owner capitalise on networks and the social phenomena:

If you are as much of an analytics nut as I am, then the video below is for you. It features Dr Matthew Hindman, Assistant Professor of Political Science at Arizona State University discussing online analytics. Dr. Hindman uses a variety of data from Hitwise to go very deep into the true analytics and much further than a basic web report.

From the overview, "Using three years of daily Web traffic data, and new models adapted from financial mathematics, this talk examines large-scale variation in Web traffic. These data show that Web traffic is highly heteroskedastic, with smaller sites having orders of magnitude more variation in the relative number of visitors they receive. These consistent patterns allow us to provide reasonable estimates of how likely it is Google will still be the most visited US site a year from now".

As I surf the Web, I come across countless Web sites that use one of the following methods to invoke a javascript function when someone clicks a link:

<a href="javascript:somefunction()">Click to invoke somefunction</a>

or

<a href="#" onclick="somefunction()">Click to invoke somefunction</a>

Unfortunately, these types of links are completely unusable for anyone with javascript disabled (and, for that matter, the second example is completely useless to people that can’t “click” the links, such as people using older handheld devices). Even worse, the second example can be extremely annoying, as it focuses the screen back to the top of the Web page when you click it.

As I process more and more business cards over at my new startup, one thing I’ve noticed on (unfortunately) a regular basis are companies who haven’t setup their domain names properly. The company domain name works when you type the full “www.companyname.com” but if you only type “companyname.com” you get nothing. The errors range from a server error to a dns error.

For most hosts it takes only a minute to get the non-www domain working. Check out the search results on Google for information on how to set it up for your particular host. Even domain name providers like GoDaddy have instructions on setting up the non-www version.

Don’t lose traffic and more importantly potential customers because of something so simple!

I stumbled across a neat tool to be used during Web site development the other day. The tool uses javascript to examine the page and presents you with an overlay report of the accessibility issues in the page. The tool was developed by and is available from Accessify. It’s called the “Quick Page Accessibility Test.” Installing the app is as simple as dragging it to your Favorites/Bookmarks bar. Then, whenever you visit a page, you can click on the bookmark and the accessibility tester will pop over the page you’re viewing (complete with context overlays).

Anyway, after I installed the application and tested one of my pages, I came across an accessibility warning I had never encountered before. The warning message looked something like “This appears to be a list of links. Perhaps this should be marked up with ARIA landmark role ‘Navigation’.” I had never heard of ARIA landmark roles, so I ran off to try to do some research on the subject. About all I was able to find in my first attempt were some abstracts from the W3C.