Tag Archives: speed

Higher education & web accessibility

Posted in User experience on by Paul Boag

By now anybody involved in managing a higher education web site will be aware of the need to make it accessible. However, not all are clear as to why this is important or indeed how to go about it. This article is designed to give you a quick overview of the subject and direct you to some useful resources. What is web accessibility?

Web Accessibility is about making your web site accessible to the widest possible audience. Because of the lobbying of organisations such as the RNIB most people associate web accessibility with the visually impaired. However, web accessibility is much broader than that. It is also about providing access for those with motor impairments, learning difficulties and other forms of disability. It is also about making your web site accessible to all, irrespective of what browser technology they are using to access your site or the connection speed.

How web accessibility is measured

In practice, web accessibility is primarily (although not exclusively) defined by a checklist set out by the World Wide Web Consortium (W3C). The W3C is a governing body for the web that sets standards for technical development. One set of standards is the Web Content Accessibility Guidelines (WAI) which defines three levels of accessibility each progressively more demanding. The most basic level of accessibility is Priority 1 (level A compliance) followed by Priority 2 and 3 (levels AA and AAA).

Why your web site should be accessible

There are three broad arguments for making your web site accessible to all:

Legal

Although the Disability Discrimination Act does not refer directly to web sites, the associated code of practice does. The Act makes it unlawful for a service provider to discriminate against a disabled person by refusing to provide any service which it provides to members of the public. The code of practice then goes on to give an example of an Airline company that provides ticket reservations via its web site. The required level of web site accessibility is as yet untested in a British court. However, in Australia a blind person successfully sued the Sydney Olympics Committee for providing an inaccessible web site. It is widely believed that this ruling will influence any future ruling in the UK.

The UK government is taking web accessibility very seriously and says the following on the e-government web site.

"All UK government websites are expected to achieve, as a minimum, and adhere to the single ‘A’ (Priority 1 items) level"

Higher Educational web sites are also affected by The Special Educational Needs and Disability Act 2001 which makes it unlawful to discriminate against a disabled person in relation to the services provided to students, and admission to the university.

These two Acts effectively mean that it is vital that Higher Educational web sites comply with the W3C WAI Guidelines at least to Level A.

For more on web accessibility and the law click here

Practical

Those involved in making a higher education web site more accessible should not perceive it as an obligation but rather as an opportunity. An accessible web site provides a huge range of benefits including:

  • Accessible web sites receive significantly better placement on search engines
  • Ensuring your site is accessible opens it up to audiences previously excluded from your site, including not just the disabled but those using older technology.
  • Having an accessible web site demonstrates your commitment to the disabled and will attract higher levels of applicants from this group.
  • Making your web site accessible also improves usability which in turn has numerous benefits in its own right.

Moral

Probably the hardest argument to articulate for web accessibility is the moral one. However, it cannot be ignored. At the end of the day making your web site accessible to all is simply the right thing to do.

The way forward

By now you should have a clear understanding of what web accessibility is and why it is important. It can seem like an overwhelming task to make your web site accessible to all but it does not need to be.

The key is to ensure that the stake holders in your site have a clear understanding of why web accessibility is important and that you provide them with the training and skills to implement it. This, in conjunction with a clear plan of attack, should be enough to ensure your site is accessible to as many as possible.

For more help on the practical implementation of an accessible web site read this excellent web site accessibility plan developed specifically for the Higher Education sector.

How we are relaunching our own website

Posted in Web strategy on by Paul Boag

Its a bit embarrassing really. One of the primary things Headscape sells itself on is our experience with accessibility and the fact that we build using web standards. However our current site has a totally separate accessible version and is built with standard HTML. Looks like it is about time we redesigned our website!

I thought it would be good to take a slightly different tactic to most website redesigns where the company keeps the design under wraps until it goes live. Instead I thought I would share some of my experiences as we redesign the site and let you see some of the thought process we have gone through.

Establishing our aims

The first step in any redesign is to be clear about your objectives. Why do you want to redesign your site in the first place. After all in Headscape’s case we have received some very positive feedback about our current site.

Our goals are three fold:

  • Create one site to meet every bodies needs instead of having a separate accessible version. This will be inline with the position we now take on accessibility.
  • Create the new site using web standards is order to speed download, improve printability, and make the site easier to update.
  • Give the site a new look and feel so we can relaunch it and generate some renewed interest in the Headscape brand.

What we didn’t want to do is make huge changes to the content as we don’t have the time internally to do that. We intended to make some minor updates to the case studies section but that was about it.

The design approach

Once we had a clear idea of our goals and knew exactly what our content would be it was time to move on to the design stage. I also knew that the colour scheme should be similar to the existing site and where possible the existing brand should be reflected. I also knew from feedback we have received that the site needed to be lighter in colour. With all of this in mind I produced the following:

Click here to see the new homepage design

Getting some feedback

Before we proceeded too much further we wanted to get some feedback on the site and see if we were heading in the right direction. We weren’t at the stage of full usability testing yet but some initial impressions would be nice. So far I have asked for a web site review from members of a forum I regularly contribute too and this has been very useful. My next step will be to ask some of our clients to take a look at the design and let me know what they think.

A final little twist

A final little idea I wanted to share with you before I close is the banner at the top of the new design. You will notice that it refers to accessibility. The idea of this block is that we are going to detect what people have entered into the search engine and change the banner accordingly. In other words if they have searched on accessibility they will see an accessibility banner while if they typed in usability they will see a usability banner. This not only allows the user to quickly find the content they are after but also makes us appear to specialise in exactly the area they are interested in.

Conclusions

So that is as far as we have got so far. Please feel free to post your comments on the design below. Any feedback is much appreciated. I will keep you updated on how things progress.

Usability guidelines

Posted in User experience on by Paul Boag

Read Jakob Nielsen’s top ten tips to creating a usable website or application.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place.

Recognition rather than recall

Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.