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…)

Databases offer a lot of flexibility when dealing with data. By spending some time upfront on the database design, it will save you plenty of headaches later on. Since the object of this to tutorial is not to elaborate on the advantages of using a database, I will skip to its limits.

The operations you can run on a database are always based on logic and numbers. So for example, when you run a store and sell T-Shirts, and you sort by size, “M” will always be sorted before “S”, even though it is not correct from a humanistic point of view.

Assuming we have a table called “Products” in the database, here is a set of data that you would typically deal with and a solution for sorting the data in a more useful way using the MySQL database.

Name    | Size

T-Shirt | L

T-Shirt | M

T-Shirt | S

T-Shirt | XL

T-Shirt | XS

And here is how you typically retrieve records:

SELECT Name, Size FROM Products ORDER BY Size

This query returns all products, however, not sorted “XS, S, M, L, XL” but in “L, M, S, XL, XS”.

The solution to this problem is a simple CASE (see: Control Flow Functions):

SELECT Name, Size,

CASE Size

WHEN XS THEN 1

WHEN S THEN 2

WHEN M THEN 3

WHEN L THEN 4

WHEN XL THEN 5

END

AS Sort_Order

FROM Products

ORDER BY Sort_Order ASC

This returns the products in order of their sizes. Use ASC (ascending) or DESC (descening) to change the order from smallest size to largest size or vice-versa.

That’s it, enjoy.

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.

More and more web developers are ditching tables and coming round to the idea of using CSS to control the layout of their site. With the many benefits of using CSS, such as quicker download time, improved accessibility and easier site management, why not?

The problem with CSS

Historically the main problem with using CSS has been lack of browser support. This is no longer the case as version 5 browsers, which all have good support for CSS, now account for over 99% of browsers in use.

Instead, the problem is that browsers can sometimes interpret CSS commands in different ways, causing developers to throw their arms up in the air and switch back to pixel-perfect table layouts. Fear not though, as you learn more about CSS you’ll gradually start to understand the different browser interpretations and realise that there aren’t really that many.

How browser detection using CSS hacks works

The way browser detection using CSS hacks works is to send one CSS rule to the browser(s) you’re trying to trick, and then send a second CSS rule to the other browsers, overriding this first command. If you have two CSS rules with identical selectors then the second CSS rule will always take precedence.

Say for example you wanted the space between your header area and the content to have a gap of 25px in Internet Explorer, or IE as it’s affectionately known. This gap looks good in IE but in Firefox, Opera and Safari the gap is huge and a 10px gap looks far better. To achieve this perfect look in all these browsers you would need the following two CSS rules:

#header {margin-bottom:25px}#header {margin-bottom:10px}

By inserting a CSS hack we can perform our browser detection by hiding the second CSS rule from IE. This means that IE won’t even know it exists and will therefore use the first CSS rule. How do we do this? Read on and find out!

Browser detection for Internet Explorer

To send different CSS rules to IE, we can use the child selector command which IE can’t understand. The child selector command involves two elements, one of which is the child of the other. So, html>body refers to the child, body, contained within the parent, html.

Using the example of the header margin, our CSS command would be:

#header {margin-bottom:25px}html>body #header {margin-bottom:10px}

Browser detection for Internet Explorer 5

It may seem strange at first to send different CSS rules to different versions of a browser, but in the case of IE5 it’s very necessary. This is due to IE5’s misinterpretation of the box model. When specifying the width of an element in CSS, padding and borders aren’t included in this value. IE5 however, incoporates these values into the width value causing element widths to become smaller in this browser.

The following CSS rule would result in a width of 10em for all browsers, except IE5 which would give it a width of just 5em (IE5 would incorporate two sets of padding and border, on both the left and right, when calculating the width):

#header {padding: 2em; border: 0.5em; width: 10em}

The solution to this problem? The box model hack, invented by Tantek Çelik who has become quite famous in the CSS world as a result of this CSS hack. And rightly so when you see what he came up with. To perform browser detection and send a different CSS rule to IE5 you would use:

#header {padding: 2em; border: 0.5em; width: 15em; voice-family: “\”}\”"; voice-family:inherit; width: 10em}

How he worked out how to do this is anyone’s guess! The important thing is that it works: IE5 will use the first width value of 15em, 5em of which will be taken up by the two sets of padding and border (one each for the left and for the right). This would ultimately give the element a width of 10em in IE5.

The 15em value will then be overridden by the second width value of 10em by all browsers except IE5, which for some reason can’t understand the CSS command that comes immediately after all of those squiggles. It doesn’t look pretty but it does work!

Browser detection for Internet Explorer on the Mac

Quite simply, IE on the Mac does strange things with CSS. The browser’s become somewhat obsolete as Microsoft aren’t going to be bringing out an updated version. As such, many web developers code their CSS-driven sites so that the site works in IE/Mac, although it may not offer the same level of advanced functionality or design. Provided IE/Mac users can access all areas of the site this is seen as a suitable way of doing things.

To hide a command using the IE/Mac CSS hack is simple, and involves wrapping a set of dashes and stars around as many CSS rules as you like:

/* Hide from IE-Mac \*/

#header {margin-bottom:3em}#footer {margin-top:1.5em}


#noiemac {display: none}
/* Hide from IE-Mac \*/

/* End hide */

The first CSS rule hides the entire section assigned the noiemac id (i.e.


Forms are an essential part of interaction on the Internet but they can look rather drab. With CSS we can position form items so they all line up nicely and add a bit of colour to jazz them up.

The original form

That form looks horrible! Here’s the code behind it:

<form action="destination.htm">

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

<label for="e-mail">E-mail</label> <input type="text" id="e-mail" /><br />

<input type="submit" value="submit" />

</form>

Positioning the form with CSS

The first thing we need to do to the form is make it line up nicely. In the old days this could only be achieved with tables - not anymore, courtesy of our old friend, CSS. First, we’ll assign a class to each form item:

<form action="destination.htm"><label for="name">Name</label> <input type="text" id="name" class=”input-box” /><br />

<label for=”e-mail”>E-mail</label> <input type=”text” id=”e-mail” class=”input-box” /><br />

<input type=”submit” value=”submit” class=”submit-button” />

</form>

The two input boxes have been assigned the class, input-box, and the submit button, submit-button - hmm… how did we think up those names?

Now they’ve got their classes we’ll need to assign some rules to them:

label{

width: 4em;

float: left;

text-align: right;

margin: 0 1em 10px 0

clear: both

}

.input-box{

margin-bottom: 10px

}

.submit-button{

margin-left: 5em;

clear: both

}

Right, let’s go through that CSS bit-by-bit. We gave the label a fixed width of 4em, although this should obviously be increased if the prompt text in the form is anything longer than what we’ve got now (‘name’ and ‘e-mail’). We also specified the width in terms of em and not px so that if users increase the text size the width will increase with the larger letters.

The margin: 0 1em 10px 0 CSS command means the labels will have a margin above them of 0, to the right of 1em (so that the text isn’t up against the input box), a bottom margin of 10px (to create some space between each line) and a left margin of zero. The clear:both CSS command is necessary to ensure the text (‘name’ and ‘e-mail’) starts on a new line.

The submit button has a left margin of 5em so that it aligns with the input boxes, which are 5em from the left. This includes the 4em width and the 1em right margin of the prompt text.

So, putting that altogether gives us this form:

Looks much better, but it’s still rather plain. Let’s use some more CSS to jazz up the form so it’s more inline with the colour scheme on the page.

Applying colours to the form

The three CSS commands we’ll use to make those forms look good are border, background and color (you can also use any other CSS command, such as font, text size, bold etc.).

So, let’s say we want the input boxes in this form to have a dark blue text colour and border and a pale orange background, and the submit button to have black text, an orange background and a dark blue border. In addition to the above CSS, we would add in the following commands:

.input-box{

color: #26a;

background: #feb;

border: #26a solid 1px

}

.submit-button{

color: #000;

background: #fb0

border: 2px #9cf outset

}

(#26a is an abbreviation of #2266aa - you can apply this shorthand version with any colour value with repetitive numbers like this.)

We use ‘outset’ for the button’s border so that it looks like a button. If we used ‘solid’ it would look flat. Here’s how the form comes together:

One word of warning, be careful about using a light text colour for text with input boxes. More and more Internet users are using the Google Toolbar which fills in online forms for you. Whenever a form appears it automatically turns the background colour of input boxes to yellow - if you’ve specified white text it would be virtually impossible for your site visitors with this toolbar installed to see what they’re writing when completing the form.

Formatting the whole form

We may want to give this form its own title and border. To do this we add the <fieldset> and <legend> commands to the HTML code:

<fieldset><legend>This is my form</legend>

<form action=”destination.htm”>

<label for=”name”>Name</label> <input type=”text” id=”name” class=”input-box” /><br />

<label for=”e-mail”>E-mail</label> <input type=”text” id=”e-mail” class=”input-box” /><br />

<input type=”submit” value=”submit” class=”submit-button” />

</form>

</fieldset>

We’ll apply some CSS commands to the fieldset and legend to give the form a blue border and a title with an orange background:

fieldset{

border: #26a solid 1px;

width: 20em

}

legend{

background: #fb0;

border: #26a solid 1px;

padding: 1px 10px

}

The final form

Drum roll… Here it is:

Here’s the CSS we used to make this, all in one place:

label

{width: 4em;

float: left;

text-align: right;

margin: 0 1em 10px 0

clear: both

}

.input-box

{

float: left;

margin-bottom: 10px

color: #26a;

background: #feb;

border: #26a solid 1px

}

.submit-button

{

margin-left: 5em;

clear: both

color: #000;

background: #fb0;

border: 2px #9cf outset

}

fieldset

{

border: #26a solid 1px;

width: 20em

}

legend

{

background: #fb0;

border: #26a solid 1px;

padding: 1px 10px

}

Take this further

This article only touches on what you can achieve with CSS and forms. You can pretty much apply any CSS command to a form item, so the only limit is your imagination. Play around with a form and see what you can come up with!

This article was written by Trenton Moss. He knows an awful lot about accessibility and the Disability Discrimination Act.

Writing effective ALT text for images

Anyone who knows anything about web accessibility knows that images need alternative, or ALT, text assigned to them. This is because screen readers can’t understand images, but rather read aloud the alternative text assigned to them. In Internet Explorer we can see this ALT text, simply by mousing over the image and looking at the yellow tooltip that appears. Other browsers (correctly) don’t do this. The HTML for inserting ALT text is:

img src="filename.gif" mce_src="filename.gif" alt=”Alternative description goes here”

But surely there can’t be a skill to writing ALT text for images? You just pop a description in there and you’re good to go, right? Well, kind of. Sure, it’s not rocket science, but there are a few guidelines you need to follow…

Spacer images and missing ALT text

Spacer images should always be assigned null ALT text, or alt="" . This way most screen readers will completely ignore the image and won’t even announce its presence. Spacer images are invisible images that pretty most websites use. The purpose of them is, as the name suggests, to create space on the page. Sometimes it’s not possible to create the visual display you need, so you can stick an image in (specifying its height and width) and volià, you have the extra space you need.

Not everyone uses this null ALT text for spacer images. Some websites stick in alt="spacer image". Imagine how annoying this can be for a screen reader user, especially when you have ten of them in a row. A screen reader would say, “Image, spacer image” ten times in a row (screen readers usually say the word, “Image”, before reading out its ALT text) - now that isn’t helpful!

Other web developers simply leave out the ALT attribute for spacer images (and perhaps other images). In this case, most screen readers will read out the filename, which could be ‘newsite/images/onepixelspacer.gif’. A screen reader would announce this image as “Image, newsite slash images slash one pixel spacer dot gif”. Imagine what this would sound like if there were ten of these in a row!

Bullets and icons

Bullets and icons should be treated in much the same way as spacer images, so should be assigned null alternative text, or alt="". Think about a list of items with a fancy bullet proceeding each item. If the ALT text, ‘Bullet’ is assigned to each image then, “Image, bullet” will be read aloud by screen readers before each list item, making it take that bit longer to work through the list.

Icons, usually used to complement links, should also be assigned alt="". Many websites, which place the icon next to the link text, use the link text as the ALT text of the icon. Screen readers would first announce this ALT text, and then the link text, so would then say the link twice, which obviously isn’t necessary.

(Ideally, bullets and icons should be called up as background images through the CSS document - this would remove them from the HTML document completely and therefore remove the need for any ALT description.)

Decorative images

Decorative images too should be assigned null alternative text, or alt="". If an image is pure eye candy then there’s no need for a screen reader user to even know it’s there and being informed of its presence simply adds to the noise pollution.

Conversely, you could argue that the images on your site create a brand identity and by hiding them from screen reader users you’re denying this group of users the same experience. Accessibility experts tend to favour the former argument, but there certainly is a valid case for the latter too.

Navigation & text embedded within images

Navigation menus that require fancy text have no choice but to embed the text within an image. In this situation, the ALT text shouldn’t be used to expand on the image. Under no circumstances should the ALT text say, ‘Read all about our fantastic services, designed to help you in everything you do’. If the menu item says, ‘Services’ then the ALT text should also say ‘Services’. ALT text should always describe the content of the image and should repeat the text word-for-word. If you want to expand on the navigation, such as in this example, you can use the title attribute.

The same applies for any other text embedded within an image. The ALT text should simply repeat, word-for-word, the text contained within that image.

(Unless the font being used is especially unique it’s often unnecessary to embed text within images - advanced navigation and background effects can now be achieved with CSS.)

Company logo

Websites tend to vary in how they apply ALT text to logos. Some say, ‘Company name’, others ‘Company name logo’, and other describe the function of the image (usually a link back to the homepage), ‘Back to home’. Remember, ALT text should always describe the content of the image so the first example, alt="Company name", is probably the best. If the logo is a link back to the homepage then this can be effectively communicated through the title tag.

Conclusion

Writing effective ALT text isn’t too difficult. If it’s a decorative image then null alternative text, or alt="" should usually be used - never, ever omit the ALT attribute. If the image contains text then the ALT text should simply repeat this text, word-for-word. Remember, ALT text should describe the content of the image and nothing more.

Do also be sure also to keep ALT text as short and succinct as possible. Listening to a web page with a screen reader takes a lot longer than traditional methods, so don’t make the surfing experience painful for screen reader users with bloated and unnecessary ALT text.

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

When creating accessible websites, most web developers and web managers tend to follow the W3C accessibility guidelines. And rightly so - they are the most comprehensive accessibility resource on the Internet after all.

The W3C accessibility guidelines, or Web Content Accessibility Guidelines as they’re officially known, could go slightly further however. Fulfilling the guidelines will give you a very accessible website (remember though, they are just guidelines so shouldn’t always be taken literally). For ultimate accessibility though, try implementing some of these techniques too:

Hidden text

Hidden text can be very useful for screen reader users. If there isn’t sufficient text for these users to gain an understanding of a particular section, then you can simply create this extra information and hide it from sighted users.

The most common and useful page items to insert invisible text for screen reader users include:

• Headings - Every single section on each page should have a heading placed immediately before it. This way, screen reader users always know that the preceding section has finished and a new section has begun. So, before the main navigation begins, you should insert a heading labelled, ‘Site navigation’. Although this heading is extremely useful for screen reader users, it may look rather unsightly visually, so you can just make the text invisible.
• Form labels - Every form item must have a label immediately preceding it - otherwise, screen reader users won’t know what the form item is about. Date of birth fields, with three separate fields for date, month and year, are common culprits of not providing form labels for each form field. So, place the date of birth label before the three form fields, and then insert an invisible label before each of the other two form fields, ‘Month of birth’ and ‘Year of birth’.
• Skip links - A skip link is an invisible link that’s placed at the very top of the HTML file. It’s a relative link within the page, allowing users to jump straight to a section on the page, usually the main content. Skip links are really useful for both screen reader and keyboard-only users who can jump straight to the content, without having to work through the navigation.

Succinct, front-loaded and conventional link text

As a method of browsing through a page, screen reader users can call up a list of links on a page and jump to the link in which they’re most interested. It’s common knowledge that link text should make sense out of context, and this is indeed a W3C guideline. Link text such as ‘Click here’ would obviously make no sense in a list like this. It’s also crucial that link text is:

• Succinct - so that it’s quick and easy for screen reader users to work through this list
• Front-loaded - so that screen users can understand the meaning of the link straightaway and jump down to the next one if they’re not interested
• Conventional - so screen reader users can alphabetise the list and jump to the link they’re looking for (e.g. if the ‘Contact us’ link was labelled as ‘Enquiries’ it would be harder to find the website’s phone number)

Link text is additionally important for users that finds it difficult to read online, such as screen magnifier users and those with learning difficulties and dyslexia. For these users when they scan through web pages, they’ll often be unable to make out specific words - instead, they’ll see shapes and colours. Anything that’s in a high contrast colour is obviously a link, so they can stop and read it.

By making link text succinct and front-loaded, and using conventional link text, it’s far easier for users that finds it difficult to read online to immediately comprehend links and what their destination is.

Visible font resizer

It’s crucial that text is resizable for web users with poor or limited vision - or so the theory goes. In actual fact, user testing has shown time and time again that few web users actually know how to resize text, or that this functionality even exists.

By providing a visible font resizer all users are of course made aware that they can resize the text should they need to. To find out how to put a font resizer on to your website, read this article about stylesheet switching.

(Incidentally, if you don’t know how to resize text simply select ‘View > Text size’ in either Internet Explorer or Firefox; alternatively, scroll with the wheel of your mouse whilst holding down the control key.)

Place instructions first

If you provide instructions for any kind of functionality on your site, make sure that the instructions are placed before the functionality. This of course sounds obvious, but it’s amazing how many times this rule isn’t adhered to.

Screen reader users listen to pages in the order that they’re written in, so if any instructions come after what they’re relating to then that’s obviously going to be too late.

Placing instructions first is also crucial for screen magnifier users. Screen magnifier users can only see a small section of the screen at any one time, so if instructions are placed in an out-of-the-way place they’ll likely be overlooked.

Web forms are perhaps the most common type of functionality to contain instructions. Do be sure that any instructions are placed above the form and not below it. Mis-placed instructions usually include explaining which fields are required and error messages.

Large headings

Headings are crucial for all users to find what they’re looking for quickly and efficiently. They are however particularly useful for any user that finds it difficult to read online, such as screen magnifier users and those with learning difficulties and dyslexia.

When these users scan through web pages, they’ll often be unable to pick up words and instead will see shapes and colours. By using a large font size for headings, these users will easily be able to spot these important headings.

Focus state for links

Keyboard-only web users can navigate through web pages by tabbing from link to link (and form item to form item). It can however sometimes be difficult to know exactly where you are on the page when relying on the tabbing method. By assigning a background colour to the focus state of each link, it becomes much easier for these users to orientate themselves on the page.

Large link target

Many web users with dexterity problems will use only the keyboard to browse through a website. Some will still continue to use a mouse but with rather limited control, so wherever possible do try increase the area of the link target. This is of course not possible for regular links, but for vertical based navigation lists it’s easy to extend the clickable area to the full width of the column by assigning the style, display: block to each link.

Conclusion

The W3C accessibility guidelines are of course important, but if you want your website to be truly accessible then there’s more that you can do. Following the advice in this article is of course a great start!

This article was written by Trenton Moss. He’s crazy crazy about web usability and accessibility - so crazy that he went and started his own usability and accessibility consultancy (Webcredible) to help make the Internet a better place for everyone. He’s extremely good at running focus groups and likes to conduct a website evaluation as often as he can.