Feature: How Nationwide tackled Accessibility - The Whole Story

Ian Lloyd describes how the Nationwide Building Society's web design team embraced the notion of web accessibility, the lessons learnt along the way and how these can be put to use in any organisation aiming to manage it into the project lifecycle...

If you are a web designer or developer, you can probably recall many times when, having completed a piece of work and handed it over to your client (or perhaps another person/department where you work), all your good work is undone by sloppy maintenance. It's a common problem – many refer to this phenomenon as 'HTML smudging'.

Smudging has always been an issue with building web sites. In the days of 'best viewed in IE4 or Netscape 4' coding was generally sloppier (we were all still learning), and smudging of sloppy code often went unnoticed. These days, however, more people are coding (or trying to) to agreed standards for HTML, CSS and web accessibility. This means that there's more for individuals to learn, and an even greater chance for it all to come apart when one or more elements get smudged later in the process.

In this article I'm going to concentrate on web accessibility and how to get from the perfect page template to the perfect complete site, making sure to avoid smudging of your carefully crafted work along the way.

Some six months ago, I was involved in a re-design of Nationwide Building Society's main website - this covers general product information, but not our internet banking service or subsidiary sites. It is a large chunk of work, though, with roughly 600 pages in total.

The redesign was not merely cosmetic – it also had to satisfy a number of accessibility criteria. This was something that very few people among our team of web developers were familiar with, and so presented a challenge in delivering an entirely consistent accessible package. However, if I were to look at any of these live pages six months after the redesign started it would look and behave almost exactly as originally designed/prototyped. Somehow we avoided the smudge effect. So, what was it that we did to avoid this?

Please note that I am not a trained project manager and, as such, may not be using the terms you might normally like to hear about project life cycles and such like. I am a web designer/developer/accessibility evangelist and everything in this article is expressed from that viewpoint. I am also going to fly through some stages in the process which, I feel, do not need to be covered in any detail as it would merely be teaching people to suck eggs.

Our focus was very much on getting the website accessible for blind users. Although no other disabilities are mentioned, you can take it as read that we avoided anything that would affect people with colour-blindness, epilepsy or motor deficiencies. (There is an argument that the World Wide Web Consortium's focus has been too much on the blind).

Long before any actual building of pages could take place, we obviously had to have a vision – what were we aiming for? In our small design team of four we have a range of different skills and approaches. We all came up with our individual ideas, collectively producing 30 designs in 5 days, then picked the best bits of each design and attempted to glue them together in one coherent design. A few iterations later and we had a mock-up design that everyone was happy with, looked achievable and also scalable. Next stop, usability.

Testing prototypes for usability

Nationwide has a dedicated usability centre through which a large cross-section of work is passed. This might be anything from printed leaflets or mortgage information packs to electronic media (internet, intranet or bespoke software for internal use). Although there is not a rigid User-Centred Design approach adopted company-wide, the design team does try to use such an approach, gathering requirements early on, putting together scenarios covering who we think the user is and what they would expect to see, and so on. This is combined with years of tried-and-tested experience of designing for the medium. Ultimately, this does mean that the output from our small design team is well prepared for usability testing.

The redesigned product information webpages scored very well in a number of satisfaction indices that are compiled at the usability centre. It was quite a surprise to find that so little needed attention – at least according to the group that we had run the test pages past. The challenge now was to get this handful of pages – that were still largely running through the power of smoke and mirrors – to work in the real world and both satisfy our web accessibility and cosmetic design aims while also satisfying business needs.

Tip: If you do not have a usability resource such as this to hand, then try setting a few simple scenarios (eg "You need to get some information about the widget product and compare that with the doohicky product to see which is more economical – how would you do that?"). Next, grab the nearest person who happens to be walking down the corridor outside your office and ask them to carry out one of these scenarios. This 'corridor' approach is not an idea of mine, but I have heard that it works – it can hardly hurt. You cannot assume that everyone thinks the same way that you do, and a stranger's reaction to your webpage may reveal flaws that you didn't know existed.

Setting clear accessibility aims up-front

Once you have a design agreed and usability tests appear to show that the design will work in practice, you need to think about your stance on web accessibility.

* Just how accessible does it need to be?
* What is your audience likely to be?
* What is the purpose of your site?

If your site is a non-commercial source of information, then you can probably aim for Priority 1, 2 and 3 compliance (of the W3C Web Content Accessibility Guideline). However, if your site is a commercial venture, you will probably not be able to compromise on the design aspects quite so much and will therefore need to set the accessibility aims slightly lower (unfortunately many of the guidelines for priority 2 and 3 can fly in the face of visual design requirements).

When defining accessibility compliance of Nationwide's site we aimed for Priority 1 minimum (or Bobby A approved). It would have been great to aim higher, but ultimately the website does need to sell Nationwide products (hey, let's not beat around the bush on this). Level 1 compliance still offered a highly accessible webpage though.

Contrary to popular belief, web accessibility is not a difficult thing to get right: as long as you do this from the outset. Many website managers find themselves in the position of having to retro-fit accessibility features into page designs that simply do not lend themselves to such hacks.

If a content management system (CMS) is used, this makes the job of updating hundreds of pages based on a template easier, but in all likelihood the better approach would be to start with a fresh design.

If you are in a situation where an existing site needs to be made accessible, you will no doubt uncover all sorts of problems – you and web accessibility will not hit it off as best of friends. Believe me, a clean start is the only way to get it right.

As mentioned, accessibility is far easier if you get it right from the outset – and by this I mean the template/dummy page. While developing the page, keep a list of checkpoints next to you to constantly remind yourself what's required and read/act upon them at VERY regular intervals. Building a typical page with typical content, I would be asking myself questions such as:

* How well does the page resize?
* Does it fit in 800 by 600?
* How does it behave when style sheets are disabled?
* How does it look when JavaScript is disabled?
* What happens when you look at the page on x number of browsers?
* Does it work on Macintosh as well as PC platform?
* What is a search engine likely to make of this page?
* How does the page actually sound in a screen reader?
* Can the text be re-sized OK?

This is not an exhaustive list (and the list depends on your own design guidelines and business requirements) but these cover most of what is needed to do to achieve Level 1 compliance for web accessibility. And as I've already mentioned, it's far easier to throw these tests at just one template page and only to fix one page when something does not work.

One key thing to mention is that this stage should absolutely not be rushed. Project deadlines may dictate that you have a certain amount of time to complete this template work, and after that time a team of eager web developers will start to build from this template. My advice would be – buy yourself time. Tell the project manager it will take you twice as long as you think it might.

There really can be no compromise at this stage. While re-testing your page and tweaking this, that or the other, it is so easy to introduce a new cosmetic feature (aka, a bug) in a browser that you don't test upon all that frequently. The last thing you want is for that bug to become part of your final template which then gets replicated hundreds of times over.

The hand-over

This is the scary part – the part where the smudging normally comes into play! You may have spent a great deal of effort getting the perfect template/dummy page together, but now you have to hand it over to a team of people, all of whom will have their own ways of thinking/coding, will have varying levels of knowledge and possibly differing dedication to the web accessibility ethic. It simply won't do to hand your example page over and expect people to act like little clones of your good self in building further pages. Some of the things that you might consider (and which Nationwide did with this redesign) are:

* Running a workshop about web accessibility for the web development team
* Asking a blind web user to come in and demonstrate how they really use screen readers (not how we think they use them), and for them to try some of your existing web pages. Often seeing how difficult a site is to navigate for a blind user is all that's required to get people to try harder in getting their web pages accessible
* Providing an A4 checklist that lists the key things to be aware of (such that Level 1 compliance is satisfied)
* Installing demo screen reader software on the developers' machines and providing a simple guide on how to use the software. Don't expect people to do it for themselves (otherwise you'll hear this "Sorry, I couldn’t check that page, I don't have Connect Outloud installed" or something similar)
* Providing a micro-site about the different aspects of web accessibility, in terms that are truly relevant to your team of developers – ie relate examples to the company's intranet home page or similar. Most likely this would go on your company's intranet or on a CD distributed to all involved
* Making yourself constantly available during the early periods of intense development.

Under no circumstances can you:
* Simply tell people: "We have to do this – there's information about it at the W3C site; read that..."
* Expect everyone to understand accessibility straight away.

Of all the points above, I believe that making yourself readily available is the most important. Clear the decks and if an accessibility question comes your way, treat that as highest priority. If you do not take time to help people at this stage – the nurturing stage – then the developer will go and find his or her own solution (and it probably won't be compatible with yours).

Testing the site

Shortly before the work is due to go live, you will naturally have a testing phase (you do, don't you?). This will, of course, include a series of accessibility tests (it will, won't it?).

You need to ensure that the people carrying out the testing are up to speed with web accessibility too. They will need to:

* Be aware of the guidelines given to developers
* Be able to compile test scripts based on these guidelines
* Be confident in using a screen reader with the monitor switched off
* Be able to filter out false errors (for example, a screen reader bug – yes, they too are not perfect, much like browsers!)

But this is all standard testing/sign-off procedural stuff - what would be really interesting at this stage would be to call back your blind user and ask this person to try the re-worked site out. It's one thing to use a screen reader in testing, but it's just so easy for you to switch the screen back on when you get stuck. By doing this real world test one of two things will happen:

* You will get very positive feedback from your guest tester, and the whole development team will realise what a difference they have made to that person's browsing experience or
* Your guest tester will spot something that you were not aware of. But you'll still have time to fix it.

Obviously, you're hoping for the former, but if it's the latter then you fix whatever needs fixing and go back through this final real-world test until you get it right.

Tip: Don't look at a failure in the testing phase as a problem. Treat it as a learning experience. This may sound schmaltzy but for many web accessibility is a very new discipline – you are bound to get errors along the way. The thing is to learn from them (and you will).

Keeping an ear to the ground

Once a site has gone live, you'll have moved on to other pieces of work, and other people will have the job of maintaining the live site. This is traditionally where problems begin to creep (or barge) their way in, and for many different reasons:

* New staff or contractors not on the original project take on maintenance of the site
* There is a reduced focus on accessibility as it is not promoted as part of a project life cycle
* New designs are introduced for sections of the site that were not envisaged at the prototype stage
* An external agency is commissioned for a new section of the site and off-site workers do not have access to your internal guidelines.

It's imperative that the accessibility and design standards set up are maintained, and as such you should:

* Train new starters in the accessibility ethic to the best of your ability – this will not be as easy as it was to a group of developers working on one specific project, but you must try!
* Review any existing in-house HTML training. Perhaps your personnel department offers something like this (depending on the size of the company)? The chances are, the advice given will be correct – but only for people still living in the year 1998. Here is an opportunity to change the materials being used.
* Check the departmental reference library – how old are your books? Get some new accessibility books, throw out the HTML 3 books and hide the DHTML books. You might want to destroy any Microsoft FrontPage books while you're at it.
* Ensure that internal guidelines are provided to all external suppliers (on CD or through an extranet) – and that these standards are agreed upon before any contracts are signed.

Above all, you need to make yourself available whenever needed and to ensure that the accessibility ethic is not forgotten – use every opportunity to remind people that it's still important. But just try not to bore everyone in the process!

Postscript

Shortly after I wrote this article, Nationwide received a report on its site's accessibility. Interestingly, the recently redesigned product information pages came in for very little criticism; where issues were raised they were often in areas that were outside the control of the web development team.

Third party-hosted sites came in for greater criticism, proving the value of agreeing to certain standards up-front. Nationwide now has to go through the messier approach of fixing these other sites as best it can, once again reinforcing the point that accessibility is easy when you build from the ground up.

But like I said before, finding out that sections of your site are not totally accessible is not a bad thing – it lets you know where to look to put things right. And we will …

Ian Lloyd
Senior Web designer, Nationwide Building Society

Associated Link: Nationwide Building Society

'Internet addiction' linked to Depression
Source: BBC, 9 February 2010
 
There is a strong link between heavy internet use and depression, UK psychologists have said.

Could *You* be more Usable?
Source: UN, 8 February 2010
 
Bet you could.

Stowe Boyd on 'Steampunk' thinking about the Future of Computing
Source: Stowe Boyd's blog via Experientia, 6 February 2010
 
Are established metaphors of user experience holding us back from new ways of structuring our interaction through computers?

Nokia's User Experience Programme
Source: UN, 5 February 2010
 
Nokia has put together a rich and informative website covering the key elements of user experience.

Interfaces magazine: latest issue available now
Source: HCI News Service, 4 February 2010
 
The latest issue of Interfaces is now available in pdf format, free from the Interaction Website.

A Lighter Brigade of Chargers
Source: UN, 3 February 2010
 
Lots of gadgets, one charger. At last.

Mobile Touch Screens could soon Feel the Pressure
Source: MIT Technology Review, 2 February 2010
 
A quantum switch could add pressure sensing to mobile screens.

Usability, Usability, Usability: why the iPad will Succeed
Source: Econsultancy, 1 February 2010
 
The tech critics love it, hate it, love it again, shrug it off. What do usability experts say?

British Airways - at last some good news
Source: Loop11, 30 January 2010
 
In a recent website usability study for the world's leading airlines, the British Airways website proved to be the most user friendly, with Malaysia Airlines and Virgin Atlantic having the lowest user experience rating.

Computation of Emotions in Man and Machine
Source: Royal Society, 29 January 2010
 
Advances in computer technology now allow machines to recognise and express emotions, paving the way for improved human-computer and human-human communications.