Making Strathclyde accessible to all


One of the key principles of our web transformation strategy is that the content we put online should be accessible to as large an audience as possible.

This is an easy statement to make, but much harder to implement. In this post we want to explain just something of what is involved.

Supporting the disabled

When you think of accessibility most people think of the disabled. Although this isn’t all that web accessibility is about, it is a key consideration especially considering the legislation surrounding it and the university’s reputation as an inclusive institution.

Unfortunately it is impossible to design a site that meets everybody’s needs because different disabilities can have conflicting requirements. However, there is solid best practice we can follow in the form of the WAI guidelines.

In addition to these guidelines, we are also working with an assistive technology advisor who is helping us run usability test sessions and providing quality assurance on the work we are doing.

Supporting different browsers

As well as thinking about the needs of the disabled, we also need to consider that people will be accessing the new website using a range of different browsers.

At the moment our beta site only supports a small number of modern browsers, but we are in the process of changing this. The site will not look identical on all browsers, but users will still be able to access content on most browsers available.

Because of the huge number of browsers out there, we will only test on a subset, but the site should be accessible to even the oldest browser.

But providing browser support is not just about supporting older browsers. It is also about supporting the next generation of browser. This is why we do not endeavor to make the site look the same across all browsers. If we took that approach, our website would never make use of the emerging technologies that creates a better experience for those with modern browsers.

The approach of providing access to information on all browsers, but optimising for more modern ones, is called progressive enhancement. This means that no matter how old your browser you will be able to navigate the site, but the newer the browser the better it should look.

Supporting multiple devices

Not only do we need to consider multiple browsers, we need to think about multiple devices. We are not even just talking about a mobile or tablet. There are literally hundreds of devices with different sized screens and different input methods.

We also have no idea what the future will hold. For example the majority of users might be using the iPhone or iPad right now, but that might not be the case in another year. Even if it is there is no guarantee Apple won’t release a new device with a new screen size.

The way we solve this problem is by making the website “responsive”. That means it adapts based on the screen real estate available to it. The advantage of this approach is that no matter how devices change over the years, as long as they still have screens the website should adapt accordingly.

Building a site that works this way is no easy challenge and that is what we are working on right now. Each module that makes up the website has to be flexible enough to adapt to a range of available space and this can prove a time consuming business.

International students

The final audience to consider when thinking about accessibility are international students. It goes without saying that these are a massively important audience for any university, and so it is important to ensure the website is as accessible as possible for them.

There are two accessibility concerns that need particular consideration when thinking about international students – bandwidth and language.

While broadband is widespread here in the UK it isn’t always abroad, and so it’s important to consider download times. Furthermore, some countries make much heavier use of mobile than we do here in the uk. This means we need to make sure the site downloads fast over a cellular connection.

The other issue is the language we use on the website. Although we expect a certain standard of English from international students, university websites are often full with verbose copy, complex sentences and a lot of jargon. If we are keen to attract overseas students we need to work hard at keeping our language simple.

Using simple language also helps users with cognitive disabilities such as dyslexia, and speeds up comprehension for all users.

We will need your help

By now I hope you have realized that ensuring an accessible website is more than the web team can achieve alone. Yes, we can build accessible templates but as soon as content providers add video without captions or images without descriptions things fall apart.

We cannot hope to maintain an accessible website without everybody writing plain English and considering how the images they choose will look on a mobile device.

Accessibility is something we all need to be committed to. That is why a programme of accessibility training will be made available for anybody involved in adding content to the website.

The lego approach to building a website


As you will have seen if you have visited our development site, we have already made substantial progress on the new University of Strathclyde website. We have established the beginnings of a new look and feel, a proposed site structure and given considerable attention to research related content.

However, no doubt you are wondering when we will get around to the parts of the site most applicable to your areas of interest. Well, believe it or not we already have!

A modular approach

One of the reasons we decided to start the project by looking at research was the range of content types it involved. We had to consider how to present everything from featured research projects and news to search functionality and key members of staff. In fact, in all we identified 27 different ‘modules’ that needed building.

Just some of these modules included:

  • Tags
  • Navigation
  • Search
  • Site footer
  • Feature boxes
  • Related links
  • Calls to action
  • Video

Each module had to be specified, wireframed, designed, coded and integrated into the content management system. However, once this was done, it could be reused wherever we wanted.

That is why we are already working on your part of the site. We have been building modules that are not just going to be used within research, but across the whole of the site. These core building blocks are like lego bricks. Once they have been made we can use them to build almost any type of page across the entire site.

Customisable modules

You might be concerned that this means your content is going to look exactly like every page of the site, and that the characteristics of your work will be lost. Fortunately, that is not the case.

Not only can modules be organised in a huge variety of different ways, it will also be possible to customise the visual appearance of modules.

We are still discussing what level of customisation will be available, but as a minimum you will be able to hide and show elements of a module and probably colour code them too. However, there is the option to go significantly further if appropriate.

For example, the BBC use a modular approach with their Global Experience Language. This is used across all of their sites despite those sites looking totally different.

What now and what next?

Right now we are in the process of refining the modules. These modules are going to be used across the whole site and so need to be perfect. That means making improvements in…

  • Their visual appearance.
  • How they work at different sizes and in different layouts.
  • Their accessibility.
  • Their support across different browsers.
  • How they can be customised.
  • How they work alongside other modules.

As you can see this is not an easy or quick job. The web is not like print where you can control every pixel. In some cases there can be literally hundreds of different ways the same module might appear. Variations of layout positioning, device, colour, components and browser, can all impact the appearance.

In short, this will take a bit of time. However, once it is done, assembling further pages will be considerably easier. As I said before, it will be like assembling pages from lego bricks.

No doubt we will discover new modules that need building as we move on to other parts of the site, but we should have the vast majority of them already in place. This means you can expect to see an acceleration of rollout as time goes on.

This whole approach can be summed up in a single phrase – build once, use everywhere. The last thing we want to do is continually reinvent the wheel from either a design or technical perspective.

Avoiding the curse of large projects


One thing has become clear over the last decade – large I.T. projects inevitably run over budget, move slowly and often fail to deliver. Fortunately new approaches are emerging that buck this trend.

Fruugo spent €40 Million on their site and generated only €100k. Birmingham City Council spent an unprecedented £2.5 million on its website, running more than £2 million over budget. The UK Trade and Industry website cost a staggering £11.78 per visit, while spent $135 million of venture capital in just 18 months.

There are no shortage of failures like these, from Myspace to the UK Business Link website. However, lessons have been learnt and large web projects are now handled in a different way. It is this new approach that is being adopted by Headscape and the University of Strathclyde in the work we are doing together. An approach given new prominence by GOV.UK and now being emulated around the world.

A page from the website
The approach used to create the website has set a new standard for delivering large scale web projects.

In this post I want to explore how this approach works within Strathclyde and the benefits it brings.

Let’s start with the concept of work packages.

Work packages

One of the major reasons large web projects fail is because they become too unwieldy to define in detail. The normal specification process fails when faced with such complexity and so many stakeholders.

The way we have avoided this problem is not looking at the University of Strathclyde as a single project. Instead it consists of a number of work packages that seek to meet different business objectives. For example one business objective for the University is to highlight its research expertise. This objective has become the basis for our first work package.

Instead of trying to consult with every stakeholder about every aspect of the Strathclyde website, and specify how the entire website will work, we focus on defining just one package. We talk to just those stakeholders interested in research and focus just on meeting the needs of users interested in research. Only once that is done will we move on to the next work package.

We define these packages not by writing long specifications, but with user cards.

User cards

A user card is a statement of what a user wants to do on a site. They consist of three parts:

  • Who the user is.
  • What they want to do.
  • Why they want to do it.

For example a user card might be:

  • I am a prospective postgraduate student interested in nanotechnology.
  • I am interested in viewing what postgraduate courses Strathclyde teach in this area.
  • So that I can compare Strathclyde to other universities before making a decision about where I wish to attend.

Each work package is made up of a prioritised list of user cards that the development team systematically work through.

Of course, these user cards do not include enough detail to define the work to be done. That is why the development team and key stakeholders work together to define acceptance criteria for each card. In other words, we define the criteria by which the card can be judged complete.

In the example above the acceptance criteria would define the exact information our postgraduate student is interested in, and how that information needs to be accessed.

Only when all of the information is available and it can be easily found will the card be considered complete.

With our lightweight specification in hand, defining everything that needs building for the first work package, we can now begin work. This is done in a series of sprints.


A sprint is a small package of well defined work that will be completed over a short time period. In our case most sprints last a week.

Large projects with deadlines in the far future tend to slip, because the amount of work is too large and the deadline too far away for people to have any sense of perspective. By breaking the work into small chunks it helps focus the team as they push towards a single short-term aim.

For example, one of our first sprints was to complete half a dozen user cards relating to research. This involved building key pages scattered across the site as well as the core of a research section.

Where possible the entire team sits together in a room working on the sprint. The group constantly collaborate and feedback to one another, so preventing delays as one team member finds themselves waiting for a response from another. At the end of each day the team meets for 15 minutes to report back on what they did that day, what they intend to do tomorrow and any barriers they have encountered. This ensures the entire team is working unimpeded.

This team is not just made up of those building the site. It also includes stakeholders and business specialists who have knowledge for the current work package. Of course getting these people into a room for a week can be tricky so some forward planning is required.

Planning ahead

While the majority of the development team is working on the same sprint, one or two individuals are looking ahead at upcoming ones.

Somebody needs to schedule in the stakeholder participation we need, and that means looking beyond the current sprint. It is their job to research into what will be coming up on the horizon and make sure we have all the people we need.

There is also a need to identify any dependancies we may encounter further down the line. These typically constitute content that needs collecting or access to systems with which we will need to integrate.

Finally, we have found it useful to have somebody considering the upcoming UX challenges. By doing at least some user interface thinking up front, it means that we can move much quicker when a sprint begins. Otherwise developers can be left waiting for the designer to finish.

Encouraging results

Although no approach is ever perfect, the results have been encouraging and the experience inline with that of the Government Digital Service.

We have found the team works more efficiently, momentum is maintained and rapid progress is achieved.

What is more we have achieved a feedback loop that ensures the quality of what we are outputting remains high, but more on that in my next post.

Working in partnership


The secret to a successful website is close collaboration between the development team and the site owners. But, how does that work when the development team is an outside contractor?

The challenge

The University of Strathclyde and Headscape (the web design agency I co-founded) are looking to completely revamp the University website and put in place robust processes, policies and procedures for its long term management. Not only does the University of Strathclyde want a world class website, they also want to draw upon Headscape’s knowledge of best practice to ensure they are equipped to continually develop and improve the site. Unfortunately this presents a problem when looked at within the context of the normal client / supplier relationship.

University of Strathclyde Homepage
The University of Strathclyde are keen to revamp their website and put in place processes for its long term management.

Traditionally a client will produce a specification of what they want built, hand it to a web design agency, who goes away and deliver it. This works fine for smaller brochureware sites that rarely change, but it just wasn’t going to work when the aim is as much to establish working practices as it was to build a website.

Our solution to this challenge was to create a joint development team (made up of staff from Strathclyde and Headscape).

Forming a joint development team

The University of Strathclyde already have a strong web team, with server side developers, content specialists and front end coders. However like any team, it has more strength in some areas than others. We therefore started looking for gaps that could be plugged with Headscape staff.

The one obvious area of weakness is in design and UX skills. The Strathclyde team doesn’t have anybody that can fulfil this role, while it is a primary strength at Headscape.

Strathclyde also lack a lead with a strong background in digital. They have the best project lead I have ever worked with, but there was a weakness in digital experience where we could help.

Finally, although Strathclyde has excellent skills in front end development (HTML,CSS, Javascript) it was felt that adding in some experience from Headscape would encourage new thinking and introduce some knowledge in specific niches.

Our final core team looks something like this…

  • Project Lead (Strathclyde)
  • Digital Lead (Headscape)
  • Front End coders (2 Strathclyde, 1 Headscape)
  • UX Designer (Headscape)
  • Content specialists (Strathclyde)
  • Project manager (Strathclyde)
  • Server side developers (Strathclyde)

But this isn’t the entire team. We also have a number of specialists.

Bring in the specialists

Although our new core team is much stronger, it still does not have all of the skills and knowledge we need. This is an important realisation. Too many web teams resent outside ‘interference’ but the truth is that we need outside expertise.

For us these outside experts fall into two main categories; Skill specialists and Business specialists.

Skill specialist

A skill specialist is somebody who has a specific skill that we require, but do not need everyday. For example in our team we currently have three specialists working with us.

  • An analytics specialist (from Headscape)
  • A specialist in a system called Pegasus (from Strathclyde)
  • An accessibility specialist (from Strathclyde)

These and many others will be brought into the project as need arises. For example our analytics specialist is currently helping us decide which browsers we should support and to what level, while our accessibility specialist is putting together some accessibility guidelines.

Business specialist

A business specialist is somebody who has specific knowledge in the area of the site we are working with. For example, at the moment we are working on delivering content and functionality relating to research. This means we need somebody who has an intimate knowledge of that area.

Unlike skill specialists who act as consultants, we are embedding the business specialist in the core team. They remain apart of the team until we finish with use cases relating to their expertise. They become both client and team member, and are crucial to the success of delivery.

The combination of Headscape staff, the Strathclyde web team and additional experts works well for the immediate project. However, there is also a need to think further ahead.

Long term planning

Ultimately the University of Strathclyde needs to be in a position of running their own website, without the need for Headscape or any other outside contractor. This means that the roles fulfilled by Headscape people needs to be ultimately replaced with Strathclyde staff.

In some cases this is relatively easy. For example, Strathclyde already has front end coders and so Headscape’s involvement is only to introduce new practices. Once that is done, Headscape can take a back seat and allow Strathclyde staff to lead.

In other areas Headscape is only fulfilling a temporary role. For example, although we are providing analytics support, this won’t become a full time permanent position. Either Strathclyde can take on somebody part time to do this work, or continue to outsource (as needed) to Headscape.

However, there are some roles that Headscape fulfil, which will need to be filled by Strathclyde staff. Strathclyde will have to recruit in these areas. This is most notably a digital lead and UX designer.

Once these roles are filled, Headscape will begin to take a step back. However, this will not happen overnight. The transition will have to be gradual in order to hand control over in an orderly manner.

So far this collaborative process has gone extremely well, and the new joint team is working well together and learning from each other. However, collaboration is not limited to the team itself, but also to how the project is run. That I will cover in my next post.

Why does the new website look so messed up?


The chances are that if you are reading this you have already seen our new beta website and been left singularly disappointed.

If you are viewing it using Internet Explorer on a University machine it currently looks pretty shocking. But there are good reasons for this.

Internet Explorer 9 showing the new beta website in IE7 mode

If this is what you see when you visit the new Beta website do not panic!

Although computers within the University of Strathclyde are running Internet Explorer 9, they have been set to behave like Internet Explorer 7 and that is what is making the website look terrible.

Internet Explorer 9 showing the new beta website

This is what the beta website should look like on Internet Explorer 9

Internet Explorer 7 was released in 2006 and replaced by 2009. In internet terms that makes it horribly out of date and incapable of supporting the latest innovations in the web.

For us to support Internet Explorer 7 would mean not providing quality support for more modern devices especially the new mobile devices being released.

All the big names such as Google, Yahoo and Facebook no longer support Internet Explorer 7 and even Microsoft have long since stopped supporting it.

Fixing the problem

IT HelpDesk are currently looking at a fix for the problem on Standard Strathclyde Desktop (big thanks to them for their help with this), but in the meantime this might be something you can fix yourself (depending on the permissions you have on your machine.)

To view the new site in all its glory follow these steps…

Step One: When Internet Explorer 9 is open and active, press F12. Alternatively click the cog in the top right and select developers tools.

How to select developer tools.

Step Two: If you have permissions the following window should now be displayed. Make sure that both Browser mode and Document Mode are set to IE9.

Setting the browser and document mode

If pressing F12 doesn’t open the box above it means you do not have the necessary permissions to make this change. In that case we can only suggest that you download a more modern browser.

Of course, that said, we would love to have you visit and we can show you the new site personally. Just get in touch and we will happily give you the guided tour.

A benefit of Agile


Learning a new language around this project management approach, takes time. I have been learning about this way of working for some time, but it only all fell into place when the team met for the first time and started work.

I had a “this is what it is all about” moment during that first day. Rather than splitting the team into specialist units – technical/creative/management etc – all elements were in the room. During a discussion about servers and drawdown loads and other things of which I have no specialist knowledge, I found myself listening and understanding. It allowed everyone to see how the network of specialisms link together and move the project forward.

It was a bit like lifting the lid of a piano and seeing the inner workings – you got a sense of the hammers hitting the strings and generating the sound. Don’t ask me to build the piano – just let me enjoy the music. But at least I now understand much more of the technical principles which so often remain a mystery to those from the creative side of the team.

This also works the other way, with technical team members grappling with how images and words hang together to build key messages and respond to user needs.

This collective understanding builds a situation where we have a feel for all elements of the project and where the interdependencies lie.

The amount of work which an agile team can get through in a day is quite incredible – huge strides can be made in short order. But for it all to work you need a ringmaster to organise, control, motivate, summarise and prioritise. Paul Boag from Headscape is performing that role and bringing a refreshing sense of focus and community.

It feels like a bold, innovative and imaginative approach which fits the university.

Making Strathclyde responsive


One of the biggest challenges when building the new Strathclyde website is ensuring that it works on the huge range of devices that users have today. From desktop computers to mobile phones and tablets, people access the web on a bewildering number of devices.

This means that building a website cannot be like print, where you have pixel perfect control. On the web, your site needs to adapt and respond to changing screen sizes as you can see from the video below.