Imagine you’re driving along and due to a road closure you have to follow those conspicuous yellow detour signs. You’re now on an unfamiliar road, but because of the signs you confidently proceed, comfortable in trusting the arrows to tell you where you need to go.

Then there’s a roundabout and no sign. Do you turn left? Right? You’re lost and have two choices; turn back and find an alternate road you know well or blindly drive around and hope for the best.

Websites are very similar, no matter what their ultimate goal is, your site visitors need to intuitively find their way around. Too often, general website navigation and orientation disappears or changes on internal pages.

In fact, with websites this point is even more pertinent as users can just ‘evaporate’ and leave your site, instead of being forced to drive around aimlessly!

(more…)

Web developers attempting to build accessible websites often make the same mistakes time and time again. Although they’re trying their hardest sometimes their overzealousness gets in the way and actually hinders the accessibility of their websites.

The below 10 guidelines tell you what not to do, so you too don’t fall foul to these same common accessibility errors…

(more…)

As many of you are aware, it is rather difficult to create an accessible “quick link” menu (sometimes also called “jump menus”) because most of them require javascript.

For those of you that don’t know what a quick link menu is, it’s generally a dropdown menu, made from a typical form “select” element. Then, when a user chooses one of the options within that select element, the page automatically redirects to the location associated with that option.

For instance, in the top corner of all HTMLCenter pages, there is a quick link menu called “Top Links”.

For a lot of users, these types of menus are extremely useful. Designers generally use quick link menus for one of two purposes: a) to provide a quick, easily locatable list of the top content on their Web site or b) to provide a list of the headers on a long page, allowing the users to quickly “jump” to the appropriate section of the page.

The problem, though, as I mentioned at the beginning of this post, is that they all require javascript in order to work properly. That’s great for the users that have javascript enabled, but it really can cause problems for those that don’t have javascript.

I have come up with a solution to that problem, though. With the solution described below, the “quick link” menu is initially written as an unordered list. Then, I use javascript to convert it to a standard “jump menu”. That way, if the user doesn’t have javascript within his/her browser, they get a nicely formatted unordered list of the links instead.

(more…)

My supervisor at work e-mailed a nice accessibility resource a few weeks ago. The “Division of Instructional Technology” at the University of Wisconsin has put together a good collection of videos and podcasts related to Web accessibility. The in-house videos are narrated and led by a blind man named Neal Ewers, who works for the Trace Research and Development Center at the University of Wisconsin, Madison.

The videos are extremely interesting to watch, and very informative. If you have considered improving your Web site’s accessibility, I highly recommend visiting the site and watching each of the videos.

What is Accessibility?

Accessibility is a term that is more associated with architectural thought, rather than web site design. There is legislation which determines the minimum standards for new buildings. As a result, new buildings today have wheelchair ramps, accessible lifts and disability parking spaces, allowing anyone with disabilities to gain access to a building, use the provided services, buy the products, and chat with the people inside.

With web sites, the term traditionally refers to the development of sites that are accessible to “all” users who may want to access them — in other words, “Universal Web Sites.”

Even though the World Wide Web is continuously growing, many users:

• use speech browsers, e.g. visually-impaired or blind people, as well as businessmen in cars;

• don’t have the latest graphical browsers and plug-ins;
• can’t see the wonderful graphics, hear the real-time audio, or navigate an interactive site;
• surf with slow modems, or reside in rural or remote areas with limited access to the Internet;
• browse without graphics, using text-only browsers or subscribe to non-graphic services;
• access in noisy, high- or low-light environments

Accessibility increases benefits for both parties: the User and the Web site Provider.

Users’ benefits:

Every user, regardless of physical, sensory and cognitive disabilities, constraints and/or technological barriers can:

• access the information

• use the services
• buy the products
• talk to the people associated with each Web site.

In other words, satisfied users may become loyal users, continue using the web site, and even recommend to others.

Providers’ benefits:

• Increase audience

• Improve maintainability and efficiency
• Improve and regain reputation
• Satisfy existing and future legal requirements

Accessibility is critical for a web site’s success. This narrow focus is at the expense of a much larger segment of society with milder impairments, such as partial sight, poor hearing, and poor language skills. The needs of this larger group can be more easily accommodated with simple and inexpensive design tips such as resizable text, large tactile buttons, and clear, easy-to-follow instructions.

Further reading:

• Why Accessible Web Design is important for Business

• Auxiliary Benefits of Accessible Web Design

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.

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.

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.

The secret benefit of accessibility part 1: Increased usability

Web accessibility has so many benefits that I really do wonder why such a large number of websites have such diabolically bad accessibility. One of the main benefits is increased usability, which according to usability guru, Jakob Nielson, can increase the sales/conversion rate of a website by 100% and traffic by 150%.

At which point you must surely be asking, ?So if I make my website accessible its usability will increase and I’ll make more money out of it??. Well, not quite. An accessible website is not automatically more usable but there are many areas of overlap:

1. Descriptive link text

Visually impaired web users can scan web pages by tabbing from link to link and listening to the content of the link text. As such, the link text in an accessible website must always be descriptive of its destination.

Equally, regularly sighted web users don’t read web pages word-for-word, but scan them looking for the information they’re after.

Link text such as ‘Click here’ has poor accessibility and usability as both regularly sighted and visually impaired web users scanning the paragraph will take no meaning from this link text by itself. Link text that effectively describes its destination is far easier to scan and the destination of the link can be understood without having to read its surrounding words.

2. Prompt text assigned to form input

In order to make forms accessible we need to assign the prompt text to its form item. This is especially useful when done with checkboxes and radioboxes, as the text becomes clickable too. Checkboxes and radioboxes are small and pernickety for even the steadiest of hands so by increasing the clickable region everyone benefits.

3. Large chunks of information divided up

There are a number of techniques that can be taken to increase the usability for visually impaired users, who have to listen to the information on each page and try to remember it. By structuring information into small, manageable groups, enhanced usability for these users can be achieved.

Methods to accomplish this can include using sub-headings to break up body content, grouping form items with the fieldset command and using lists. Breaking down groups of information is obviously highly useful for sighted web users too, as it greatly enhances our ability to scan the screen quickly.

4. Site map provided

Site maps can be a useful accessibility tool for visually impaired users as they provide a straightforward list of links to the main pages on the site, without any of the fluff in between. Site maps are of course useful for everyone as they provide us with a way of finding pages quickly and help us visualise the structure of the website.

5. Simple and easy language

From an accessibility point of view, this one’s important for people with reading and/or cognitive disabilities and site visitors who’s first language isn’t the one you’re writing in. From a usability point of view, well, it helps everyone. Reading from computer screens is tiring for the eyes and about 25% slower than reading from paper. As such, the easier the style of writing the easier it is for site visitors to absorb your words of wisdom. Wherever possible shorten your sentences. Use, ‘apply’ instead of ‘make an application’ or ‘use’ instead of ‘make use of’.

6. Consistent navigation

Having consistent navigation across pages is also important for maximising accessibility to people with reading and/or cognitive disabilities, but again everyone benefits. Each time you visit a new website it takes you a few seconds to adjust to the unique layout and user interface of that page. Well imagine if you had to do that every time you follow a link to a new page!

By having a consistent interface across a website we can instantly locate the navigation and page content without having to look around for it. In reality, most sites do have consistent navigation across most pages. The main culprit for falling foul of this guideline is the homepage, which some websites structure quite differently to the rest of the site. By having a consistent interface across the entire website we can instantly locate the page content without having to look around for it.

7. No unannounced pop-ups

For web users utilising screen readers pop-ups can be a real accessibility nuisance. Screen readers read out the content of whichever window is on top of the others. Pop-ups display over the top of the main website so will always be read out first. For visually impaired users this can be frustrating as they may not realise that what they’re hearing isn’t the ?real? website.

So, pop-ups are bad for accessibility. As for usability, well I’m sure you hate pop-ups as much as I do. Many toolbars, such as the Google toolbar, now come packaged with a pop-up blocker so allow you to surf the web without the irritation of new windows popping up.

8. CSS used for layout

CSS-based sites are generally have a greater ratio of content to HTML code so are more accessible to screen readers and search engines. Websites using CSS for layout can also be made accessible to in-car browsers, WebTV and PDAs. Don’t underestimate the importance of this - in 2008 alone there’ll be an estimated 58 million PDAs sold worldwide (source: eTForecast).

As well as improved accessibility, CSS-based websites have one large usability benefit: increased download speed. Broadband isn’t as widespread as you may think. In the UK for example, just one in four web users are hooked up to broadband (source: Office of National Statistics) so improving the download speed of your web pages could provide a great usability advantage over your competitors.

9. Transcripts available for audio

One group of web users with special accessibility needs that doesn’t get much press is hearing impaired users, who need written equivalents for audio content. Providing transcripts is in fact highly beneficial to all users. Many of your site visitors probably can’t be bothered to wait for your 3Mb audio file to download and start playing. They may prefer just a quick outline of what’s contained in the audio content.

By providing a transcript, broken up by sub-headings and with the key terms highlighted, non-disabled site visitors can skim through it and get a general idea of the content. They can then make a more informed decision about if they want to wait for the 3Mb audio file to download.

10. Screen flickering and movement avoided

Some epileptic web users must be careful to avoid screen flicker of between 2 and 55 Hz. Web users with reading and/or cognitive disabilities and those using screen magnifiers will struggle to keep up with scrolling text (if you do have scrolling text be sure to provide a mechanism to stop it).

In addition to being a bad idea for accessibility, neither flickering nor scrolling text are good for usability either. The former can be distracting when you’re trying to read something and you see flashing out the corner of your eye; the latter isn’t good either as you have to wait for the content to slowly appear. When you see scrolling text do you usually bother to stop what you’re doing so you can read it as it gradually materialises? Or do you ignore it?

The other disadvantage of scrolling or changing text is that you might see something you want to click on, but before you know it it’s gone. And now you have to wait 30 seconds for it to re-appear again!

Conclusion

With all this overlap between web usability and web accessibility there’s no excuses for not implementing basic accessibility on to your website. Outside of the ethical argument there are many reasons to make your website accessible, one of the main one being that its usability will be improved. No one can argue with that.

This article was written by Trenton Moss, founder of Webcredible, a web usability and accessibility consultancy. He’s extremely good at web accessibility training and knows an awful lot about the Disability Discrimination Act.

According to the 2001 UK census , the UK now has more people aged over 60 than under 16. It also revealed that there are now 1.1 million people aged over 85.

Webcredible recently analysed and compared the results of 16 usability testing sessions - 8 of these sessions were conducted with elderly users (i.e. over the age of 65), and 8 with younger users (i.e. under the age of 40).

The 40-minute ‘talk-aloud’ sessions involved asking participants to find information on a range of government websites.

Assigning blame

The main finding of our study was that elderly users were more likely to assign blame when using the Internet.

Of the 8 elderly participants, 3 appeared to blame themselves for any difficulties which they encountered (sample quotes: “I don’t really know what I’m doing”; “It’s probably my fault”; “This always happens to me”). 4 of the elderly users, however, seemed to blame the site(s) for any difficulties which they encountered (sample quotes: “I hate it when websites do this”; “Well, that’s stupid”; “That doesn’t make any sense”).

We found that the younger group of users were far less likely to assign explicit blame for any difficulties encountered - with only 1 user from this group assigning blame (to themselves).

Emotional reaction

We also found that elderly users used far more emotive words and phrases when referring to websites than younger users.

All of the elderly users employed strongly positive or negative words in their remarks, such as “love”, “hate”, “stupid”, “helpful” and “friendly”. Indeed, one participant even talked to the website as if it were a pet (“That’s a good boy”)!

In contrast, only 2 of the younger participants expressed themselves in comparably strong terms (both when talking negatively about aspects of a site).

Weaker mental models

A very interesting finding was that 6 of the elderly participants regularly failed to scroll down a page (i.e. did not do so six or more times in a session). This failure led these participants to often miss information that was directly relevant to their task.

In comparison, none of the younger participants failed to scroll down a page six or more times in a session.

In our opinion, this is likely to be attributable to elderly users not having fully internalised the concept of browser-windows often requiring scrolling - a concept novel to computer-technology.

Technical language

We also found that elderly users were less likely to understand technical language. For instance, a moderator’s request to “bring up the minimised window” was not understood by 5 elderly users (in comparison to not being understood by only 2 of the younger users).

We found that elderly users were at least twice as likely as younger users to not understand the following phrases: ‘Homepage’, ‘URL’ and ‘Browser’.

Link identification

Our sessions showed that elderly participants were - as a group - more likely to click on elements of a page which weren’t links (an average of 14 times per session, in comparison to the younger participants’ average of 5 times per session).

It was also the case that all elderly users reported preferring websites that changed the colour of their visited links, whereas only 5 of the younger participants considered the matter significant.

Aversion to downloading

Of the 8 elderly participants, 5 expressed a strong aversion to downloading documents from the internet because they were “worried about bugs [i.e. viruses] and things”. None of the younger participants expressed such views.

Higher incidence of ‘search’ usage

Of the younger participant group in our study, only 2 individuals used the available search functionality, whereas 6 of the elderly participant group chose to make use of it.

It is possible that this may have developed as a means of compensating for their apparent difficulties/discomfort with traditional browsing.

It should be noted that all users expected a site to have a single ‘Search’ function that searched all of the site’s content.

Slow task-completion and reading

Our elderly participants required over double the average time of our younger participants to complete a task.

3 of our elderly participants also displayed a tendency to read all of the text on a page before being willing to decide on their next course of action. None of our younger participants did this.

Preference for ‘big and simple’ design

7 of our elderly participants reported anything less than 12-point type as being too small to read comfortably - and even though all users agreed that being able to re-size the text on the screen would be a good idea, only one of them knew how to do so through the browser.

It was also the case that all elderly participants preferred 800×600 over 1024×768 resolution.

Our recommendations

Although more research into the internet behaviours and preferences of elderly users is obviously required, we would like to suggest the following:

• Designers should investigate innovative ways to communicate the fact that a page is not finished and requires scrolling
• Technical terms should be avoided if possible - and where they have to be used, a clear explanation must be easily accessible (including examples wherever appropriate)
• Links should be identified in a consistent and obvious way (e.g. blue, bold, underline, red on mouse-over)
• The attention-grabbing features on a page (e.g. headings, pictures, icons, instructions and bullets) should be links
• Visited links should change colour
• Provide an HTML-version of as much content as possible and do not require users to install software (even Adobe Acrobat) in order to be able to access information
• Make content as concise and clear as possible - consider providing two versions of the same content (’simple’ and ‘detailed’) and allow users to decide which they want to access
• Sites should provide a ‘Make the writing bigger’ link with accompanying illustrations/icons and always use high contrast to display text e.g. black text on an off-white background (N.B. using an off-white background is preferable to white because it reduces the chances of eyestrain for people who are slow readers)
• Provide explicit instructions by using the imperative forms of verbs (e.g. ‘Go to more details on…’, ‘Find a…’, etc.)

Conclusions

Elderly users are an audience group that will grow in size and importance over the next few years. Our studies indicate that there are lots of simple things we can do to support their use of the internet.

We believe that these recommendations should be taken into account by all sites, and efforts should be made to further expand our knowledge of how to design for these users.

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.