Why Usability?
This tutorial brought to you by Webnauts Net

The Usability Expert Jakob Nielsen says: “On the Web, usability is a necessary condition for survival. If a web site is difficult to use, people leave. If the homepage fails to clearly state what a company offers and what users can do on the site, people leave. If users get lost on a web site, they leave. If a web site’s information is hard to read or doesn’t answer users’ key questions, they leave. Note a pattern here? There’s no such thing as a user reading a web site manual or otherwise spending much time trying to figure out an interface. There are plenty of other web sites available; leaving is the first line of defense when users encounter a difficulty.” -

Full Story: http://www.useit.com/alertbox/20030825.html

Is your web site usable?

There are several definitions for usability, but basically products which have the following 6 characteristics, can be considered as usable.

  • Quick and easy to learn

  • Efficient to use
  • Allows rapid recovery from errors
  • Easy to remember
  • Using is enjoyable
  • Aesthetically pleasing

Does your product have the above characteristics?

User and Provider benefits:

Usability increases benefits for both parties: the User and the web site Provider.

Users benefits:

  • Users are satisfied, instead of being frustrated when interacting over the web site.

  • They achieve their goals effectively and efficiently.
  • They cultivate confidence and trust in the product.

In other words, satisfied users, become loyal, going on using the web site, and also recommend to others.

Providers benefits:

  • Reduced development time and costs.

  • Reduced support costs.
  • Reduced user errors.
  • Reduced training time and costs.
  • Return on Investment.

Usability Can Save Your Company!

John S. Rhodes, Editor and Webmaster at WebWorldPro says: “Data indicate that usability offers a better return on investment than almost any other business action. When times get rough, usability shines. The benefits are huge. Usability is a weapon that can save you money, improve your competitive position, and improve customer loyalty. Now is the time to invest in the research.” -

Full Story: http://webword.com/moving/savecompany.html

After all, making your web site usable, you will make your visitors and your wallet more comfortable and happier!

Read More
Web Credibility
Web usability: It’s old news

If you’ve been developing websites on Mars for the past few years then you’ll be forgiven for not knowing about web usability. You’ll still be creating splash intro pages, having pages with massive download times and using more images than you can shake a stick at. Well, back in Earth these days have long gone and today web usability rules the web development world. For those of you who have been on Mars please read some of the things that Jakob Nielson has to say and try to catch up.

As for the rest of us Earth-based developers, well we’ve learnt a whole bunch about usability and we’re all using it as best we can in our websites. Right, guys? After all, web usability does have huge benefits.

Now that usable websites have become so commonplace, especially among the major web players, it’s time to start looking to the future. Suddenly, a usable website isn’t going to be enough to separate us from our competitors (apart from those using the developers who’ve been based on Mars). There is a solution. It’s two words long. Enter our new best friend…

Web credibility.

What is web credibility & why is it important?

According to BJ Fogg, the world’s leading researcher on web credibility, web credibility is about making your website in such a way that it comes across as trustworthy and knowledgeable. Don’t just take my word for it – read his book if you like. This book is so good that even Jakob Nielson himself (he’s the self-appointed web usability guru for all you Mars-based developers), dedicated a whole alertbox to it.

Fogg will tell you, as can I, and numerous other organisations, that a credible website can reap huge benefits on to your website and your business. So, here’s a few statistics to prove this point:

  • Just 52.8% of web users believe online information to be credible (source: UCLA)
  • Four in five users say that being able to trust the information on a site is very important to them in deciding to visit a website (source: Princeton Survey Research Associates)

So, web credibility’s pretty important then. But how do you implement it on to your website? Fear not, all the answers lie within the realms of this article. Now, before I go further, I must stress that most of this stuff falls under the category of ‘it’s obvious once you know it’. You know, like if someone sets you a puzzle and you can’t do it but when they tell you the answer it’s really obvious. Web credibility is all common sense – you just don’t tend to think about this stuff. So without further ado, here are five guidelines for making a credible website.

1. You must prove there’s a real organisation behind your website

Anyone can put up a website promising to deliver the ‘best service at the lowest prices’. Web users must be able to believe there’s a real organisation behind your website. A few things you can do are:

  • Make it very easy to contact you
  • Link to external websites that reference your organisation
  • Provide staff bios
  • Show photos of the office, staff, products etc.

This basically says that you should have a really good contact us and about us section. Don’t bury your contact us link in some obscure place in the website or on the page. Make out like you really want your site visitors to get in contact with you. In fact, I won’t talk anymore about your contact us page because Miles Burke’s has already written an excellent article about it, The Lost Art of Conversation – Encouraging Contact Online.

As for the about us section, don’t underestimate its importance. Don’t be afraid to show who you are (stand tall and be proud!), what you stand for, what your goals are, and a bit about your history (of the organisation, not you). People will read this stuff – it certainly won’t be the first thing they’ll read on your website but it could be the last thing they read before deciding whether or not to do business with you.

Can you think of other ways you can prove your organisation’s real? Have a look at a website you visit quite often – what is it about this website that you trust?

2. Your website needs to provide ‘sensitive’ information

A website is akin to a one-way conversation between you and your site visitors where you have 100% control over the dialogue. If site users perceive you to be lacking in credibility then you’ll be unable to defend yourself. As such, you must ensure that you answer any questions your site visitors may have, for example:

  • What is the purpose of your organisation?
  • How much does your product cost?
  • What happens if I’m not happy with your service
  • What will you do with my email address once I give it to you?

There are about 35 million websites on the Internet – by 2014 there’ll be an estimated 150 million, not including personal websites. With so many people online and so many websites competing with yours, if you can’t persuade Internet users to be loyal to your website then someone else will.

3. All statements should be backed up by third-party evidence

"We helped our clients achieve an average of 70% growth last year." Really? Well prove it! Every single point you make on your website must, without fail, be backed up with hard evidence – preferably from a third-party website. How else can a reader know for sure that you’re telling the truth?

Client testimonials, for example, are great – they’re even better if the testimonial links to the client’s website. You can improve them even more if the name of the person making the testimonial is linked to their bio on their website. You could notch up even more credibility points if the testimonial itself is on the client’s website and you link to it!

If you’ve won any awards or belong to any industry bodies, then proudly display these emblems too. Even better, have them link to the external website. Better still, would be a direct link to the section of the website showing your membership details or a list of the award winners.

4. There has to be proof that the organisation is growing and has clients

An organisation that can prove it has clients and is experiencing growth instantly achieves credibility. By showing you’ve offered your services plenty of times before, and expect to do so in the future, your organisation comes across as being firmly established within your industry. You can prove this by providing:

  • A client list
  • Testimonials
  • Case studies of your work
  • A latest news section
  • A jobs page
  • Free newsletter
5. Your website needs to have an air of professionalism and confidence

Your website is your organisation’s online representation – it’s essential that it matches up in quality to the rest of your marketing materials. Even if you don’t think your website’s important to the success of your organization, (potential) clients will make judgments about your organisation based on your website.

So, what is the number one most important aspect of Web credibility? The about us section? No. Quality of outbound links? No-siree. Studies have consistently proven that the most important criteria of Web credibility is… the way the website looks. That’s it.

It’s been suggested that this is due to the short amount of time we spend on websites so we tend to rely on initial judgements. Make sure that you create a great first impression by having a crisp, professional layout with sharp graphics. Other good things to do are:

  • Provide some free information to prove your expertise
  • Ensure there are no dead links
  • Send out an automated confirmation e-mail when someone contacts you

There are many more! Just visit any website you perceive to be professional and confident and see what they do.

What next?

Have a look at your website and check to see if it does all this stuff. A handy program to check that there are no broken links is Xenu’s link sleuth. You can also check out Stanford University’s 10 guidelines for credibility and the best online resource to keep up to date with web credibility, the Consumer WebWatch.

This article was written by Trenton Moss. He’s crazy about web accessibility and usability – so crazy that he went and started his own web accessibility and usability consultancy, Webcredible, to help make the Internet a better place for everyone.

Read More
Web Accessibility and Learning Difficulties

Accessibility is about making it as easy as possible for all members of society to fully take part in that society. It is about removing barriers. It is about inclusion and empowerment. It is about creating the sort of world that we all want to live in – a message that should resonate with us all.

Where the UK government stands

This year, the UK government gave “a clear commitment to ensuring that all government websites and online services present no barriers to use for those with disabilities” (source: Connecting the UK). It has also promised “a renewed focus on the use of e-inclusion as a route to social inclusion” (source: Office of the Deputy Prime Minister).

Where are we now?

Accessibility’s profile within the Internet industry has never been higher, which is a good thing for all those people who have benefited from the improvements that have been made to a large number of websites.

Unfortunately, most people’s understanding of accessibility relates exclusively to visually-impaired users – to the point, in fact, where these two terms are often used interchangeably.

Well, it’s time that we all realised that there are other groups of users out there who need – and deserve – support.

Where should we be?

The Code of Practice for part III of the Disability discrimination Act defines a disabled person as:

“Someone who has a physical or mental impairment which has an effect on his or her ability to carry out normal day-to-day activities.”

People with learning difficulties have received a particularly raw deal (it’s estimated that some 2 million people in the UK have learning difficulties). This audience group is even mentioned specifically in the Code of Practice:

  • “5.22 – In many cases, a service provider will need to consider providing auxiliary aids or services to improve communication with people with learning disabilities.”
  • “5.28 – For example, a customer with a learning disability may be able to access a service by the provision of documents in large, clear print and plain language or by the use of colour coding and illustrations.”

Some advice

Webcredible’s analysis of usability testing sessions involving participants with learning difficulties has led to our suggesting these guidelines when designing for these users:

  • Your website should behave as consistently as possible, and have a consistent appearance/look-and-feel (e.g. all links and buttons should look and behave in the same way)
  • Avoid using words in their non-literal sense (e.g. “it’s raining cats and dogs”)
  • Avoid using abstractions (e.g. provide a link to a telephone number rather than to ‘Contact us’ )
  • Provide clearly signposted, simplified summaries of pages’ content at the top of the page
  • Provide an audio version of a site’s content
  • Break information into small, simple chunks and illustrate them visually wherever possible
  • Always provide an obvious way for users to get back to simpler content if they find themselves on a page above their reading level
  • Increase the spacing between lines of text
  • Increase the spacing between paragraphs
  • Increase the distance between the text and the underline in links (you can use the CSS border-bottom property to underline links and achieve this)
  • Increase the target area of navigation links (again, you can do this with CSS)

This article was written by Tim Fidgeon, Head of Usability at Webcredible. He’s crazy about usability and runs Webcredible’s web usability training and is passionate about user centered design.

Read More
WCAG 2.0: W3C accessibility guidelines evaluated

The second version of the Web Content Accessibility Guidelines (WCAG) is in final working draft and will soon be officially released. Version 1 of the guidelines came under much criticism for being vague, full of jargon and extremely difficult to use. The W3C has been working on version 2.0 of the guidelines for over 5 years now, but has it been worth the wait?

What’s good about WCAG 2.0?

There have certainly been a number of improvements made to the new guidelines. This is of course to be expected – after 5 years you would expect some improvement! Some of these improvements include:

Outdated guidelines removed

A number of guidelines from WCAG 1.0 are well out-of-date. Unfortunately, web developers still implement these out-dated guidelines because they don’t know otherwise. Rather than go on an accessibility training course and learn ‘real-world’ accessibility, many web developers and manager tick boxes against guidelines.

Some of the out-of-date WCAG 1.0 guidelines, which have been removed from WCAG 2.0 include:

  • 1.5 – Provide equivalent text links for links within client-side image maps
  • 5.6 – Provide abbreviations for table header labels, if you use these
  • 9.5 – Use accesskeys (keyboard shortcuts) for important links
  • 10.3 – Don’t use tables with more than one column for layout
  • 10.4 – Make sure form fields aren’t empty by default
  • 10.5 – Ensure different links have non-link text between them

(Please note, the above isn’t the exact wording of the guidelines – each of the original guidelines has been translated from the official W3C guideline into more easy-to-understand language.)

The above guidelines have all been removed from WCAG 2.0, so shouldn’t be adhered to.

Good real world techniques provided

The document, Techniques for WCAG 2.0 replaces the previous techniques document, and is actually much better. It provides a list of common failures, which the previous version didn’t, and actually offers some excellent examples of common errors.

The other major improvement in this techniques document is that the examples provided are far more real-world. The WCAG 1.0 techniques document used text such as PortMaster 3 with ComOS 3.7.1 in their examples, but who has any idea what this means? The new document is far better in this respect, using examples such as phone numbers and calendars, for example.

The techniques document also provides some clever recommendations, which accessibility guideline box-ticking developers wouldn’t perhaps have thought have. For example:

  • How to open a link in a new window using unobtrusive JavaScript
  • Displaying decorative images through CSS
  • Combining text and its adjacent image in the same link
  • Providing a heading at the beginning of each section on the page

…And many more! Do have a good look at the WCAG 2.0 techniques document as there’s lots of useful guidance here using quite easy-to-understand examples.

New guidelines included

A number of new guidelines have been brought into WCAG 2.0. Some of these guidelines are totally new whereas others were hinted at, but not specifically stated, in WCAG 1.0. Some examples include:

  • Providing text-based error messages for forms
  • Ensure all pages have a descriptive title
  • Background noise can be turned off

For a full list of brand new guidelines that don’t map to any version 1 guidelines, have a look at the W3C‘s Comparison of WCAG 1.0 checkpoints to WCAG 2.0.

What’s not good about WCAG 2.0?

So there certainly have been some improvements made to the W3C accessibility guidelines. But is it all good news? Have the problems associated with WCAG 1.0 been eliminated for this version 2 of the guidelines? Well not quite, as there are still a number of problems…

Verbose and jargon-filled language

One of the main criticisms aimed at WCAG 1.0 was the complexity of the language used. Have things improved? Hardly! Pretty much every paragraph is littered with jargon that the average web developer or web manager would be left with no clue as to the meaning.

Clearly aware of the level of jargon, the W3C have made complex terms green underlined links, linking to definitions. This is all well and good in theory, but when most sentences are broken up with one or two links it makes reading these sentences quite difficult.

Even worse though, is that the definitions are just as jargon-filled and difficult to understand as the term being defined! For example:

  • Authored unit – Set of material created as a single body by an author
  • Programmatically determined – Determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities
  • Specific sensory experience – A sensory experience that is not purely decorative and does not primarily convey important information or perform a function
  • Web unit – A collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Ironically, there’s even a definition provided for the word ‘jargon’!

Furthermore, it seems that some jargon used in WCAG 1.0, which webmasters have gotten used to, has been replaced with equally incomprehensible words. For example, we no longer have Priority 1, 2 and 3 to aim for – instead we now have success criteria level 1, 2 and 3.

Awful usability

Another major criticism of the WCAG 1.0 guidelines was how difficult it is to find specific guidance and answers. It doesn’t take too long to discover that the WCAG 2.0 guidelines quite clearly offer the same low level of usability.

Reasons for this poor usability include:

  • The level of jargon and complexity of language is truly phenomenal (as outlined above)
  • The text is littered with links making it very difficult to read
  • The two main documents, Understanding WCAG 2.0 and Techniques for WCAG 2.0 are 164 and 363 pages long in total (when doing a print preview)

If only the W3C carried out basic usability testing of how people actually use (or are unable to use) these guidelines! What they’d undoubtedly find is that users won’t understand most guidelines and will end up blindly clicking links to find out how to meet these guidelines.

As with WCAG 1.0, clicking on most links from the WCAG 2.0 guidelines simply takes users into the middle of massive pages full of difficult-to-understand text. The text, of course, is densely littered with links. Users will probably click on a link again in the desperate hope that they’ll somehow find some text that clearly and succinctly explains what they need to do. They’ll usually be disappointed.

Organising the massive amount of content available is certainly not an easy task – but why not, as a start, split up these massive documents into more manageable and less intimidating sets of smaller documents? Then, carry out some usability testing, refine, and test again.

Useful guidelines gone

Although there are a number of useful, new guidelines in WCAG 2.0, a number of important guidelines from WCAG 1.0 have been removed or are only vaguely referred to. These include, but aren’t limited to:

  • 3.1 – Avoid embedding text within images.
  • 3.2 – Create documents that validate.
  • 3.3 – Use CSS and not tables for layout.
  • 3.4 – Ensure text is resizable.
  • 12.3 – Divide large blocks of information into more manageable groups where natural and appropriate.
  • 13.8 – Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
  • 14.1 – Use clear and simple language.

(Please note, the above isn’t the exact wording of the guidelines – each of the original guidelines has been translated from the official W3C guideline into more easy-to-understand language.)

Particularly worrying is the removal of the final three guidelines, all of which relate to the accessibility of content. A major part of any website’s accessibility, and one that’s often overlooked, is the site’s usability and how the content is written and structured.

Accessible content is crucial for all special needs users, particularly those with learning difficulties and dyslexia. Perhaps the reason these guidelines have been removed is because content guidelines are fluffier and harder to measure than technical accessibility guidelines. Whatever the reason, this is not a good step for accessibility.

Technology neutral and the concept of the baseline

WCAG 1.0 states quite clearly that alternatives to JavaScript, PDFs and Flash must all be provided, as assistive technologies such as screen readers can’t access these. Although this was generally true in 1999, it’s not the case now, and nowadays JavaScript, PDFs and Flash can all be made accessible to most assistive technologies. (Remember, ‘can be’ is not the same as ‘are’.)

Version 1 of the accessibility guidelines became quite outdated rather quickly. To prevent this from happening to version 2 of the accessibility guidelines, the W3C have attempted to make WCAG 2.0 technology-neutral. Sounds sensible as now the guidelines won’t become outdated so quickly, right?

In practice, what this means is that the WCAG 2.0 guidelines are extremely vague. So vague, in fact, that they’re almost unusable as they talk in such generic terms.

Additionally, the concept of the baseline has now been introduced, where by webmasters can claim which technologies they assume are supported by site visitors’ browsers. So, if you build a website entirely in Flash and say that Flash is part of your baseline, your website can conform with all the guidelines despite the fact that some people won’t be able to access your site at all!

Discussion

So, was the wait worth it? We’ve waited over 5 years for WCAG 2.0 and certainly a number of improvements have been made. Worryingly though, the guidelines continue to be very difficult to actually use, further discouraging webmasters from reading them. The extra vagueness of these new guidelines certainly doesn’t help either.

The W3C just doesn’t seem to get it: People don’t generally want to read through hundreds of pages of text to find out how to implement accessible solutions – they just want answers and specific guidance. For most people, accessibility is just one small part of their job and they don’t have time for all this.

Webmasters are also now being asked to choose a baseline for their website but how do they even begin to go about doing this!? How would you as a web developer explain the concept of a baseline to senior management? How do you decide what you should do so as to comply with any legal requirements? Unfortunately there’s no correct answer to either of these questions.

Solution?

A solution could be that the W3C simply provides specific guidelines for what web developers and managers actually have to do. Much of this information is already there on their website, but it’s hidden away in the enormous and intimidating Techniques for WCAG 2.0 document. This document could be broken down into manageable chunks, added to and refined, and focus on providing specific, real world guidelines.

Guidelines should be relevant and specific to today’s technology, but would be updated on an on-going basis so as to make sure they don’t become too dated. Why did we have to wait over five years for version 2.0? Why couldn’t we have received versions 1.1, 1.2, 1.3 and so on during this time? This would surely have prevented WCAG 1.0 becoming out-dated as quickly as it did?

Most importantly though, the whole WCAG 2.0 section on the W3C website needs to have usability testing carried out on it. The benefits of usability testing are pretty well known by now, and it’s quite clear that the W3C has very little idea how real users are interacting with the website. By carrying out ongoing usability testing, the W3C can learn about its users and ultimately aim for an easy-to-understand and intuitive website.

This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone. He’s extremely good at accessibility consulting and spends much of his time doing DOM scripting & accessible JavaScript.

Read More
Usability Testing with Children

Usability testing with children is similar in many respects to usability testing with adults. In order to get the most out of the sessions, and ensure the child is comfortable and happy, there are a few differences that you need to be aware of.

Stress of new people and surroundings

Children are far more likely than adults to find encountering new places and people stressful. You should always remember this, so try to find as many ways as possible to relax the child. Some things you could do are:

  • Allow a significant period of time – at least 10 minutes – to meet the child. This is critical in putting them at ease before beginning the session. Some easy things to talk about might be computer games, cartoons, sports or school. Trying to make all the equipment used during the session match that which the child uses at home/school (phone up their parents/teachers beforehand to check).
  • Try to be as comforting and reassuring as possible. It’s especially important to make it clear to the child that you want their views on the site and that you’re not testing them.
  • Plan for the fact that younger children may prefer their parents to remain in the testing room with them. Make sure that parents know that they should stay out of the child’s line-of-sight and not help or distract them.

Asking for help

Children are far more used to asking for – and receiving – help than adults, so it’s very important for the moderator to:

  • Clearly explain at the beginning of the test that you want the child to use the site on their own
  • Make a sustained effort to deflect any such questioning during the session itself

Good ways of deflecting questions can include:

  • Answering a question with a question (e.g. What do you think [you should do now]?)
  • Re-stating that you want the child to use the site ‘on their own’
  • Asking the child to have ‘one last go’ before you move on to something else

Children get tired, bored and discouraged more easily

Children (especially of younger ages) are less inclined – and/or able – to apply themselves to a single task for a prolonged period. Some ways to work around this are:

  • Limiting sessions to 1 hour or less.
  • Taking short breaks during sessions if the child becomes tired or irritable.
  • Ensuring that sessions cover the intended tasks/scenarios in a different order – this will make sure that the same scenarios are not always tested by tired children, who are less likely to succeed/persevere.
  • Asking the child for help so as to provide them with motivation (e.g. asking ‘Could you please find out for me how to…’, or by actually pretending to not be able find/do something on the site).
  • Keeping up a steady stream of encouragement and positive feedback (“You’re doing really well and telling us lots of useful things – it will really help make the site better. Keep it up!”).

The importance of non-verbal cues

Children can’t always be relied upon to verbally articulate their thoughts/feelings, either due to their:

  • Not being articulate enough
  • Being too shy
  • Not wanting to say the wrong thing and displease an adult
  • Saying things they don’t believe just to please the adult

This makes it particularly important that the usability expert be sensitive to children’s non-verbal cues, such as:

  • Sighs
  • Smiles
  • Frowns
  • Yawns
  • Fidgeting
  • Laughing
  • Swaying
  • Body angle and posture

Physical differences

A couple of very obvious – but easily forgotten – differences which need to be taken into account are:

  • Chair and table settings – Make sure you have a chair/table setting that allows the child to comfortably use the equipment during the session.
  • Microphone positioning – Children tend to have quieter voices than adults, so microphones should be placed slightly nearer to the participant than normal.

Levels of literacy and understanding

It is critical to ensure that a session’s participant has an accurate understanding of the scenario being presented to them. Some ways to do this include:

  • Asking participants to re-phrase scenarios/goals in their own words.
  • Asking participants to repeat a scenario (i.e. what they are trying to achieve) if the task has gone on for some time and you suspect they may have forgotten it.

This article was written by Tim Fidgeon, Head of Usability at Webcredible. He’s crazy about usability and runs Webcredible’s writing for the web training and is passionate about user centered design.

Read More
Usability Page Breakdown

You know exactly what your organisation does and what your website offers its users. This information has probably become second nature to you, but first-time visitors to your site won’t know this. As such, make sure you don’t forget to tell them what you do.

As soon as new site visitors arrive at your website the first thing they need to know, before anything else, is what you do. You can talk all you like about how great you are, but unless you spell out what you actually do, they won’t even know what you’re so great at! This oh-so-overlooked yet such basic of information can be communicated to your site visitors in a number of different ways:

Page title

Don’t just use the page title to tell me who you are; tell me what you do too. If your company is called Bloggs Ltd don’t only place the words, ‘Bloggs Ltd’ in the page title as there’s plenty of room for more information. If Bloggs Ltd sells widgets, a good page title might be: ‘Bloggs Ltd – Buy widgets online‘.

Note in this example, ‘Buy widgets online‘ was used to describe what Bloggs Ltd does, and not ‘Widget seller’. When describing what it is you do be sure to speak the language of your users, and don’t talk from your point of view. From your point of view you sell widgets, but from their point of view they want to buy widgets online, so do bear this in mind when authoring the page title.

The page title is the first thing that appears on screen, and especially on dial-up modems can be the only thing that displays for the first 10 seconds or so. For many web users this is the first piece of content they’ll read on your site.

The page title is also very important for search engines, which place more importance on the page title than any other on-page element. Descriptive page titles are also essential for blind web users utilising screen readers, as it’s the first thing that gets read aloud to them upon arriving at the page.

Tagline

A good tagline is one of the most important usability features on any website. A good tagline should be explanatory and not vague, clear and informative and about four to eight words in length. A tagline is different to a company slogan, in that the former describes what the organisation/website does whereas the latter is designed to evoke certain feeling or create a brand.

‘Priceless’ and ‘I’m loving it’ are slogans by Mastercard and McDonald’s respectively – they differ from taglines because they don’t describe what the organisation does.

Taglines are so important because no matter on what page site visitors enter your website, they’ll always be able to quickly gain an understanding of what your organisation and website offers. This can be especially true for site visitors coming into internal pages from search engines – by telling these site visitors what you do through the tagline, they may be more likely to explore your site beyond the initial page on which they enter.

Taglines are also good for search engine optimisation, as they appear on every page right at the top of the page, an area on to which search engines place importance.

Main heading

The main heading on the homepage is one of the first pieces of text web users notice, especially on clean well laid out websites. Sticking a ‘Welcome to our website’ may seem to be friendly and welcoming to you, but to task-driven site visitors it doesn’t help in any way shape or form. A quick summary of what you do and/or what the website offers, in just four or five words can be highly effective (and very search engine friendly too!).

Opening paragraph

Perhaps the most important place on the homepage to tell your site visitors what you do, the opening paragraph must be short, succinct and straight-to-the-point. Just one sentence is enough to put across this most basic yet fundamental of information.

When writing this opening paragraph, remember to front-load the content (this rule actually applies to every paragraph on the website). Front-loading means putting the conclusion first, followed by the when, what, where and how.

Don’t write a story with a start, middle and conclusion – generally speaking on the web, we scan looking for the information that we’re after so put the conclusion first. This way, site visitors can read the conclusion first, which in this case is what your organisation actually does. If they want to know any more, they can then continue reading or jump to another section of the page. (To see front-loading in action, read any newspaper article.)

Exceptions

So, does every website need to tell users what the organisation does in these four different places? Well, not necessarily. We all know what Mastercard and McDonalds do, so it could definitely be argued that websites for household names need not explicitly say what they do. What these sites should do instead is tell us what the website offers, and this message can (and should) be put across in any of the above four ways – how else will site visitors quickly be able to find this out?

Conclusion

People are going to visit your site who don’t know what you do. Before you can even begin selling to them you must tell them what your organisation and website does. In addition to fulfilling site visitors’ immediate need (finding out what you do) you’ll also be boosting your search engine rankings. If your organisation is a household name, then instead of explaining what you do, it may be wise to tell site visitors what they can do on your website.

This article was written by Trenton Moss, founder of Webcredible, a web usability and accessibility consultancy. He’s extremely good at usability testing and running CSS training courses.

Read More
The Web Accessibility Toolbar

Testing a website for accessibility can be a time-consuming and laborious process. The free Web Accessibility Toolbar can do most of the hard work for you though and is an indispensable tool for anyone interested in accessibility.

The toolbar is not an automated testing tool so does require manual work from you. It’s therefore able to avoid the many problems with automated accessibility testing tools. It doesn’t require any technical knowledge so even the biggest technophobe can check their website for accessibility!

Installing the Web Accessibility Toolbar


You can download the toolbar for free from http://www.nils.org.au/ais/web/resources/toolbar, and after you install it, it will sit in the toolbar area of Internet Explorer. The total file size is just 550kb so the download won’t take too long. The toolbar only works on Internet Explorer on Windows, so if Internet Explorer isn’t your first-choice browser you’ll have to switch browsers when using it. (Alternatively, you can download the Web Developer Toolbar for Firefox which offers similar, but not identical, functionality.)

Using the Web Accessibility Toolbar


Now you’ve downloaded and installed the Web Accessibility Toolbar you can start using it! There are 12 buttons in total on the toolbar, each with a down arrow to the right of the text. If you click on the down arrow for any of these buttons then a dropdown menu appears with all the available options (alternatively you can use the keyboard shortcut keys assigned to each button).

Checking for document structure


One of the most useful buttons is the seventh, Structure. It’s essential that the structure within the HTML code accurately reflects the visual structure of the page. This is so that visually impaired web users using screen readers can gain an understanding of the page structure.Some of the most useful items in the Structure dropdown menu include:

  • Headings – Shows which items on the page are labelled as headings within the HTML code. The main page heading should be an <h1> (heading level one) and other headings should be <h2>s (heading level twos). Any sub-heading of an <h2> should be an <h3>, then <h4> and so on. Heading numbers should always be sequential – an <h4> shouldn’t follow an <h2> if there’s no <h3>. Headings are especially useful for screen reader users as they can call up a list of headings and jump straight to the section in which they’re most interested.
  • List items – Shows which items on the page are labelled as lists within the HTML code, by displaying
  • next to any list item. Lists can be horizontal or vertical, and all navigation should be marked up as a list item. Lists are very useful for screen reader users as the screen reader will announce the number of items in the list before reading the list items.
  • Fieldset / Label – Shows which items on the page are called labels within the title=”Hypertext Markup Language”>HTML code. After selecting Fieldset / Label, the text next to each form should say the word label next to it – if not, that text hasn’t been called a label in the code.
  • Table border – Places a border around each table. Nested tables within tables can cause huge difficulties for screen reader users. After selecting this item, the first table will have a black border the second blue, then green, yellow, orange, red and purple. If you see any of these last four colours it’s time to take a good look at the code behind the page.
  • Table cell order – Shows the order in which the page is read out to screen reader users (if a table is used for layout). Hopefully, the order should be reasonably logical.

Checking the site works under all circumstances


It’s important that your website doesn’t depend on any one type of technology, or users whose browsers don’t support that technology may be unable to access your site. You can check to see if your site depends on any one technology:

  • Images > Toggle Image/Alt – One of the most useful functions on the toolbar, replaces images with their ALT, or alternative, text. Alt text is read out to screen reader users or displayed to web users with images turned off, instead of the image itself (e.g. users on dial-up modems may turn off images to speed up the download time of pages). It’s essential that the ALT text provides an adequate description of the image.
  • IE Options > Toggle JavaScript – Turns off JavaScript. After selecting this option, work through the pages on your website – is the whole site still accessible to you?
  • IE Options > Toggle ActiveX – Turns off ActiveX controls. Again, after selecting this, work through your website to see if the whole site is still accessible to you.
  • IE Options > Toggle CSS – Turns off CSS. Are pages still legible? If CSS is used for layout then you will see the page content in the order that it’s read out to screen reader users. (If you toggle image/alt after this, you’ll have a complete visual representation of what screen reader users will hear.)

Other useful accessibility checks


There’s a huge amount of functionality available on the Web Accessibility Toolbar, but some of the other most important accessibility checks you can carry out with the toolbar include:

  • Validate > W3C HTML validator > Validate HTML – Checks whether the page is based on valid HTML or not. If the page is not valid, you’ll be told why.
  • CSS > Deprecated HTML > Deprecated elements & attributes – Checks for code that shouldn’t be used and is being phased out. A new window will open containing the HTML code – anything in red is deprecated and should be removed.
  • Doc info > Page speed report - Examines all the files used to display the web page and prepares a report on the average download speed for that page for different Internet connections.
  • Doc info > List links - Displays a list of all on-page links. Screen reader users can call up a list of links and jump straight to the page in which they’re most interested, so it’s essential that link text makes sense out of context. Link text such as ?click here? should be avoided at all costs!
  • Colour > Greyscale – Shows the page in greyscale. Great for checking colour contrast.


Other functionality


The Web Accessibility Toolbar offers some other interesting functionality:
  • Resize – See how your website looks for users on 640 x 480px, 800 x 600px and 1024 x 768px screen resolutions.
  • Tools > Simulations – Put yourself in the shoes of a special needs users with these fascinating simulations.


Conclusion


The Web Accessibility Toolbar offers an enormous amount of functionality. Download it for free from href=”http://www.nils.org.au/ais/web/resources/toolbar/”>http://www.nils.org.au/ais/web/resources/toolbar and start using it. Without any technical expertise, you can perform a mini-accessibility audit on any site in just a couple of minutes.

This article was written by Trenton Moss, founder of Webcredible, a web usability and accessibility consultancy. He’s extremely good at usability training and writing for the web training.

Read More
Ten Quick Accessibility Tests

The Disability Discrimination Act says that websites must be made accessible to disabled people. So how can you check that your website is up to par? There are a number of basic tests you can make to address some of the m2328ain issues. The following list includes guidelines that provide a good start in increasing accessibility to disabled people:

1. Check informational images for alternative text

Place the cursor over an informational image, for example, the organisation logo. Does a yellow box appear with a brief, accurate description of the image? For users whose browsers don’t support images, this alternative text is what they’ll see (or hear) in place of the image.

2. Check decorational images for alternative text

Place the cursor over a decorative image that doesn’t have any function other than to look nice. Does a yellow box appear with a description of the image? It shouldn’t. This image serves no purpose so there’s no reason for users whose browsers don’t support images to know that it’s here.

Be careful though as this isn’t a foolproof test. If a yellow box doesn’t appear, this could mean one of two things:

• The alternative text of the image is assigned a null value (alt=”"), which means that it will be ignored by browsers that don’t support images. This is the ideal scenario.

• The alternative text of the image is simply not set at all, which means that users whose browsers do not support images will be alerted to its existence but will be unable to find out what purpose it carries – something which is very frustrating! This is certainly not the desired outcome.

3. “Listen” to video or audio content with the volume turned off

If you turn your speakers off, you’re clearly unable to listen to, or follow, any audio content. This situation is faced by a deaf person on a daily basis. Ensure your website supplies written transcripts, so that deaf people can understand the message that your website’s conveying.

4. Check that forms are accessible

Usually there’s prompt text next to each item in a form. For example, a contact form might have the prompt text name, e-mail, and comments, each one next to a box where site users will enter their details. When you click on the prompt text, does a flashing cursor appear in the box next to that text? If not, your forms are inaccessible.

5. Check that text can be resized

Does the text on your website increase in size? If not, then your website is inaccessible to web users with poor visibility. To check:

• Internet Explorer: View ? Text size

• Netscape: Edit ? Preferences ? Appearance ? Fonts

• Opera: File ? Preferences ? Fonts ? Minimum font size (pixels)

6. Check your website in the Lynx browser

The Lynx browser is a text-only browser and doesn’t support many of the features that other browsers such as Internet Explorer have. You can check how your site looks in this browser with the Lynx Viewer. If your website makes sense and can be navigated through the Lynx browser, then it’ll be fulfilling many of the web accessibility guidelines.

7. Check that you can access all areas of your website without the use of a mouse

Can you navigate through your website using just tab, shift-tab and return? If not, then neither can keyboard- and voice-only users.

8. Check that there’s a site map

Can you find a site map? If not, then neither can people who are lost on your website.

9. Check your web pages with an automated program

Two programs available for free on the Internet are Bobby and Wave. They’re unable to provide you with all the information that you need, as some checks must be done by humans, but they can tell you some of the areas where your site might be going wrong.

10. Teach yourself

This isn’t really a quick test, but it’s definitely possible to do if you have the time. The best place to start learning is to read Web accessibility: The basics. After this, browse through the web accessibility resources area and then follow some of these web accessibility links – some of these links really do have an enormous amount of information on web accessibility.

This article was written by Trenton Moss. He’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone.

Read More
Speed Up with CSS and Usability

Why is download speed so important?

Do you like to wait for pages to download? Neither do your site users. Read on…

1. Lay out your pages with CSS, not tables

CSS downloads faster than tables because:

  • Browsers read through tables twice before displaying their contents, once to work out their structure and once to determine their content
  • Tables appear on the screen all in one go – no part of the table will appear until the entire table is downloaded and rendered
  • Tables encourage the use of spacer images to aid with positioning
  • CSS generally requires less code than cumbersome tables
  • All code to do with the layout can be placed in an external CSS document, which will be called up just once and then cached (stored) on the user’s computer; table layout, stored in each HTML document, must be loaded up each time a new page downloads
  • With CSS you can control the order items download on to the screen – make the content appear before slow-loading images and your site users will definitely appreciate it

2. Don’t use images to display text

It’s our old friend CSS to the rescue again. There’s no need to use images to display text as so much can be accomplished through CSS. For example:

check out the example here

Put your mouse over the above link, created entirely through CSS. This is just a very simple example – the tabs at the top of this page are made with CSS too. Have a look at how else you can use CSS to make navigation buttons.

To learn more about CSS and the amazing things it can do for your website, please visit our CSS resources area.

3. Call up decorative images through CSS

It’s possible to present images as part of the background, called up through CSS. If you’ve got an image that’s 200px by 100px you can use the following HTML code:

<div class=”pretty-image”></div>

And this CSS:

.pretty-image { background: url(filename.gif); width: 200px; height: 100px }

This may at first seem a little pointless but this technique could really increase the download time of your pages. Browsers basically download background images after everything else. By using this technique, your text will load instantaneously and your site users can freely roam about the page while your 50kb fancy image downloads.

This technique disables the ALT attribute though so if you really want to have one then replace the above HTML code with this:

<image src=”spacer.gif” class=”pretty-image” alt=”description” />

Spacer.gif is a 1px x 1px transparent image. Now you have a 50 byte transparent image and the main content loading first, and your great big decorative image, complete with ALT text, loading second. Perfect.

Please note that this technique is only good for decorative images and not informational ones. Any user who has CSS disabled will not be able to see your CSS-embedded images (or their alternative text).

4. Use contextual selectors

This is inefficient:

<p class=”text”>This is a sentence</p>

<p class=”text”>This is another sentence</p>

<p class=”text”>This is yet another sentence</p>

<p class=”text”>This is one more sentence</p>.text { color: #03c; font-size: 2em }
Instead of assigning a value to each individual paragraph, we can nest them within a <div> tag and assign a value to this tag:

<div class=”text”>

<p>This is a sentence</p>

<p>This is another sentence</p>

<p>This is yet another sentence</p>

<p>This is one more sentence</p>

</div>.text p { color: #03c; font-size:2em }
This second CSS example basically says that every paragraph within class=”text” should be assigned a colour value of #03c and a font size of 2em.

At first glance this doesn’t look too important, but if you can apply this properly throughout your document you can easily knock off 20% of the file size.

You may have noticed the colour values are shorter than normal. #03c is a shortened version of #0033cc – you can assign this abbreviated value to any colour value like this.

5. Use shorthand CSS properties

Font

Use:

font: 1em/1.5em bold italic serif

…instead of

font-size: 1em; line-height: 1.5em; font-weight: bold; font-style: italic; font-family: serif

Border

Use:

border: 1px black solid

…instead of

border-width: 1px; border-color: black; border-style: solid

Background

Use:

background: #fff url(image.gif) no-repeat top left

…instead of

background-color: #fff; background-image: url(image.gif); background-repeat: no-repeat; background-position: top left;

Margin, padding, border

Use:

margin: 2px 1px 3px 4px (top, right, bottom, left)
…instead of

margin-top: 2px; margin-right: 1px; margin-bottom: 3px; margin-right: 4px

Use:

margin: 5em 1em 3em (top, left and right, bottom)
…instead of

margin-top: 5em; margin-bottom: 1em; margin-right: 1em; margin-right: 4em

Use:

margin: 5% 1% (top and bottom, left and right)
…instead of

margin-top: 5%; margin-bottom: 5%; margin-right: 1%; margin-right: 1%

These rules can be applied to margin, border and padding.

6. Minimise white space, line returns and comment tags

Every single letter or space in your HTML code takes up one byte. It doesn’t sound like much but it all adds up. We’ve found that by working through your page source and eliminating unnecessary white space and comments, you can shave off up to, or even over (if your HTML is really inefficient) 10% of its file size.

7. Use relative call-ups

Try to avoid absolute call ups as they take up more space. An example of an absolute call up is: <a href=”http://www.URL.com/filename.htm”>. Much better would be <a href=”filename.htm”>. But what if some files are in different folders to other ones? Use these shorthand properties:

  • <a href=”/”> – Calls up http://www.URL.com
  • <a href=”/filename.html”> – Calls up http://www.URL.com/filename.html
  • <a href=”/directory/filename.html”> – Calls up http://www.URL.com/directory/filename.html
  • <a href=”./”> – Calls up index.html within that directory
  • <a href=”../”> – Calls up index.html one directory above
  • <a href=”../filename.html”> – Calls up filename.html one directory above
  • <a href=”../../”> – Calls up index.html two directories above

8. Remove unnecessary META tags and META content

Most META tags are pretty much unnecessary and don’t achieve very much. If you’re interested, you can see a list of META tags that are available. The most important tags for search engine optimisation are the keywords and description tags, although due to mass abuse they’ve lost a lot of importance in recent times. When using these META tags try to keep the content for each under 200 characters – anything more increases the size of your pages. Lengthy META tags are not good for search engines anyway because they dilute your keywords.

9. Put CSS and JavaScript into external documents

To place CSS in an external document use:

<link type=”text/css” rel=”stylesheet” href=”filename.css” />

To place JavaScript in an external document use:

<script language=”JavaScript” src=”filename.js” type=”text/javascript”></script>

Any external file is called up just once and then cached (stored) on the user’s computer. Instead of repeating JavaScript or CSS over and over again in HTML files, just write it out once in an external document.

And don’t forget, there’s no limit to the number of these external documents that you can use! For example, instead of making one huge CSS document, have one main one and some others that are specific to certain areas of your site.

10. Use / at the end of directory links

Don’t do this: <a href=”http://www.URL.com/directoryname”>
Do this instead: <a href=”http://www.URL.com/directoryname/“>

Why? If there’s no slash at the end of the URL the server doesn’t know if the link is pointing to a file or to a directory. By including the slash the server instantly knows that the URL is pointing to a directory and doesn’t need to spend any time trying to work it out.

This article was written by Trenton Moss. He’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone.

Read More
Six UCS Design Methods

User-centered design (UCD) is a project approach that puts the intended users of a site at the centre of its design and development. It does this by talking directly to the user at key points in the project to make sure the site will deliver upon their requirements.

The stages are carried out in an iterative fashion, with the cycle being repeated until the project’s usability objectives have been attained. This makes it critical that the participants in these methods accurately reflect the profile of your actual users.

Focus groups

What are they?

A focus group involves encouraging an invited group of intended/actual users of a site (i.e. participants) to share their thoughts, feelings, attitudes and ideas on a certain subject.

Organising focus groups within an organisation can also be very useful in getting buy-in to a project from within that company.

When to use

Focus groups are most often used as an input to design. They generally produce non-statistical data and are a good means of getting information about a domain (e.g. what peoples’ tasks involve).

Issues

It’s necessary to have an experienced moderator and analyst for a focus group to be effective.

Usability testing

What is it?

Usability testing sessions evaluate a site by collecting data from people as they use it. A person is invited to attend a session in which they’ll be asked to perform a series of tasks while a moderator takes note of any difficulties they encounter.

Users can be asked to follow the think-aloud protocol which asks them to verbalise what they’re doing and why they’re doing it.

You can also time users to see how long it takes them to complete tasks, which is a good measure of efficiency (although you should bear in mind that using the ‘think aloud’ protocol will slow users down considerably).

Two specialists’ time is normally required per session – one to moderate, one to note problems.

When to use

Usability testing can be used as an input to design or at the end of a project. It represents an excellent way finding out what the most likely usability problems with a site are likely to be.

Usability testing can be used generate non-statistical or statistical data.

Issues

Usability testing requires some form of design to be available to test – even if it’s only on paper. Testing works best if it focuses either on gathering non-statistical feedback on a design through ‘talk aloud’ or statistical measures.

Card sorting

What is it?

Card sorting is a method for suggesting intuitive structures/categories. A participant is presented with an unsorted pack of index cards. Each card has a statement written on it that relates to a page of the site.

The participant is asked to sort these cards into groups and then to name these groups. The results of multiple individual sorts are then combined and analysed statistically.

When to use

Card sorting is usually used as an input to design. It’s an excellent way of suggesting good categories for a site’s content and deriving its information architecture.

Card sorting can be used generate statistical data.

Issues

Providing participants with a trial run on some easy cards (e.g. sports, animals, etc.) can reassure about what they are expected to do and result in a more productive session.

Participatory design

What is it?

Participatory design does not just ask users opinions on design issues, but actively involves them in the design and decision-making processes.

When to use

Participatory design is usually used within a mini-project to generate prototypes that feed into an overall project’s design process.

An example would be a participatory design workshop in which developers, designers and users work together to design an initial prototype. This initial prototype would then feed into a more traditional design process.

Projects which only utilise participatory design are very rare.

Issues

Participatory design sessions can be very fluid and require an experienced moderator with thorough knowledge of the domain to guide them.

Questionnaires

What are they?

Questionnaires are a means of asking users for their responses to a pre-defined set of questions and are a good way of generating statistical data.

When to use

Questionnaires are usually employed when a design team:

  • Can only gain remote access to users of a site

  • Is seeking a larger sample size than can be realistically achieved through direct contact

It is for this reason that questionnaires are usually administered through post or electronic means.

Issues

Questionnaires allow statistical analysis of results, which can increase a study’s credibility through its scientific appearance. This makes it all the more important that the questionnaire is well-designed and asks non-biased questions.

Interviews

What are they?

An interview usually involves one interviewer speaking to one participant at a time.

The advantages of an interview are that a participant’s unique point of view can be explored in detail. It is also the case that any misunderstandings between the interviewer and the participant are likely to be quickly identified and addressed.

The output of an interview is almost exclusively non-statistical – it’s critical that reports of interviews are carefully analysed by experienced practitioners.

When to use

Interviews are usually employed early in the design process in order to gain a more detailed understanding of a domain/area of activity or specific requirements.

Issues

Interviewing places a high premium on the experience and skill of the interviewer and analyst.

Conclusion

This has been an introduction to the major user-centered design methods. It’s vital to remember that although each can be extremely valuable, using them in the right way, for the right reasons and at the right time is critical.

Exactly which method to use, and when and how to use it will differ from project to project.

This article was written by Tim Fidgeon, Head of Usability at Webcredible. He’s crazy about usability and runs Webcredible’s web usability training and writing for the web training.

Read More

Join our team

Do you enjoy technical writing? Care about cross platform mobile apps, HTML5, Javascript and Ninja's? Write for us! We would like to hear from you, get in touch!

Worth your attention