The University of the Arts London (UAL) has about 19,000 FTE students and is made up of six colleges: Camberwell College of Arts, Central Saint Martins, Chelsea College of Arts, London College of Communication, London College of Fashion and Wimbledon College of Arts. UAL offers pre-degree, undergraduate and postgraduate courses in art, design, fashion, media, communication and the performing arts.

In September 2015 the UAL went live with Library Search.2 Along with other gateways to our resources, Library Search brings together two separate products into what presents as a single interface for the user, where they can search across our print and e-resources. These products are:

  • Koha, an open source web-based library management system hosted and supported by PTFS Europe
  • Explorit Everywhere (which we have rebranded as ‘Articles Plus’), a discovery tool hosted and supported by Deep Web Technologies.

Koha (which is a Maori word that can be translated as ‘gift’) is an open source library system and still relatively unusual in UK higher education (HE) with only two major customers – Staffordshire University and the University of Hertfordshire (who went live just a month before we did) – apart from UAL, although it does have a presence in some special, public and further education (FE) libraries. However, we did not necessarily set out to procure an open source solution to our needs, and participating suppliers included a number of traditional library management system (LMS) providers. Our primary principle during the whole project to replace our LMS was to put the user experience as far as possible at the heart of the process. This article is about what we did throughout the discovery, procurement, implementation and post-implementation phases to prioritize just one crucial element of this experience – accessibility for all customers – in our thinking about library systems and the way customers interface with them, especially the catalogue and their user accounts.

It is also important to note what we were actually procuring. Following LMS stakeholder workshops, reviewing of our then current discovery solution, Summon, trialling of a different product alongside Summon in 2013/14 and a lot of discussion internally, the decision was taken to tender for an LMS only – without an integrated discovery layer. This is because we wanted to retain our next-generation federated search tool, Explorit Everywhere, and it consequently became an essential requirement in our tender that any new system would be able to work with it.

Our focus on accessibility

As an art and design institution, the visual impact of any service is very important to our users. Student feedback had highlighted the need for our new system to take a more visual approach, with clear language and layout. In addition, UAL consists of six colleges, each with its own identity and subject specialisms. Each college has a library and it is important for students to be able to search just for items at their home library as well as across our entire collection. Print books are also still very important to our students.

Procuring an accessible system was part of our wider aim to improve the accessibility of all our library services. We have spent time planning and implementing improvements to our physical spaces (using access audits for example) as well as improving the clarity of our print and online communications.

UAL has a high proportion of students who declare dyslexia or another specific learning difficulty, at almost 20% compared to an average of 5% across all UK HE.3 We therefore wanted our new system to have a dyslexia-friendly design in particular.

In order to ensure we could compare the accessibility features of different systems, we chose a requirement for the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA. However, we felt this was an absolute minimum standard and we wanted to go further than that. Our requirements for dyslexia-friendly design included options for pastels rather than white as the default background colour and allowing users to choose their own font size and colours. We also wanted to use icons wherever possible to aid visual navigation. In addition, we were keen to include a ‘Did you mean…?’ function to provide suggestions if a word was misspelled.

Of course, accessible design benefits all students, including those who do not have English as their first language. This was an important consideration for us as UAL has a high proportion of students from other EU countries (12%) and of international students from outside the EU (33%). (See Figure 1.)

Figure 1 

Library Search landing page, showing screen options

Making procurement work for accessibility

The last time we changed our LMS, prior to our move to Koha, was back in 2003. Our requirements then were predominantly technical. User focus was limited to asking for a system that was ‘user friendly’, and offered ‘greater flexibility for users’. The requirement for the supplier to ‘co-operate with bona fide user groups in order to develop the application in line with users’ needs’ was in relation to institutional library user groups, not end users. Accessibility was limited to the ability to choose different colour backgrounds and fonts within interfaces and compliance with the provisions of the Disability Discrimination Act 1995.

This time around our users were at the heart of our process and our accessibility requirements were more detailed, more than basic compliance with the Equality Act 2010 and broader in scope.

During 2014 we scoped the then supplier landscape for LMS. We also ran and evaluated feedback from user engagement, including a user survey of our existing catalogue, comments from the National Student Survey relating to the library service and the results (in particular the free-text comments) of the international LibQUAL+® Lite survey, which we ran for the first time in November 2014. All this activity informed the procurement approach to our new system.

Procurement of a new LMS is a significant and complex process, and one way we were able to keep accessibility as a focus was by involving our dedicated Assistant Librarian (Access and Inclusion), whose role is to embed accessible and inclusive services to all library users alongside other support services in the University such as the Disability Team.

The method of procurement we adopted was an additional enabler for accessibility. After discussion with our Procurement Team at UAL we chose to follow the full Official Journal of the European Union (OJEU) Competitive Dialogue procedure, suited to an intricate and multi-faceted product like an LMS. Although a significantly more complex and time-consuming process for all stakeholders than the more common restricted procedure, competitive dialogue has the enormous advantage of allowing an institution to refine its requirements throughout a process of dialogue with, and stepped elimination of, software providers.

In competitive dialogue, evaluation is conducted in stages, firstly on paper and then through demonstrations of functionality against a detailed brief. In our case these demonstrations in the dialogue stage were two days long for each supplier, which illustrates how resource-intensive the process is for both parties. However, this multi-stage evaluation helps to produce a final specification or invitation to tender (ITT) for the shortlisted providers to respond to. Our ITT looked somewhat different from our initial scoped requirements, and, importantly, we were able to include additional requirements at that final specifying stage, informed by the shortlisting and dialogue process. This helped us to reach a decision against a variety of system areas, but in particular accessible design.

At the end of the tender process, Koha was chosen, supported by PTFS Europe.

Designing accessible search

As one part of the overall project, an Interfaces Team was established, led by staff in our Central Resources Team with staff from each college library. We scoped our interface requirements, looking at other online catalogues, incorporating previous feedback, and committing to WCAG 2.0 Level AA accessibility standards. We also included clear navigation and clear and accessible language in our definition of an accessible catalogue.

It is important to remember that an online catalogue is not just the front page. PTFS Europe engaged a dedicated designer to support our project, and estimated that we had 85 pages which needed styling. We sent examples alongside our requirements and requested changes to the initial design, based on previous feedback.

Items specifically you designed for us included ‘Did you mean…?’ which is based on Ispell4 and the addition of icons for options in advanced search (Figure 2).

Figure 2 

Material types icons in advanced search

When we were happy with this initial design, we sought user views (by means of spot voting and comments) through a series of posters. We chose three screens to show our users:

  • catalogue home page
  • search results page
  • user account page.

We asked users to put dots on any area they especially liked, and invited them to add comments around the screenshots. We used social media to promote our call for feedback. This method allowed library users to respond quickly and easily and generated a huge amount of really useful data across our six libraries – this despite the only incentive being a few sweets and the opportunity to have their say. (See Figure 3.)

Figure 3 

Library Search results page: user spot voting 2015

We took all comments on board and fed this into the final design. This was largely possible because a key benefit of an open source system such as Koha is the opportunity to respond flexibly to user input.

We were encouraged by the very many positive comments from all stakeholders, which included colleagues from our Web, Communications, Disability & IT Teams, as well as students.

All elements of the new LMS were checked against our ITT requirements. We used AChecker,5 a free web accessibility checker, to test WCAG 2.0 Level AA compliance.

Our system officially went live in September 2015, in time for our new intake. Existing and new students alike have adapted well to the change.

As part of our ongoing evaluation process, we scheduled a second round of user feedback for March 2016. We repeated the spot voting exercise, and also ran two focus groups. Responses were really positive, with ease of search and the layout of the Your Account area receiving praise. Students at UAL still predominantly wanted access to hard copy resources, and in particular wanted a link to reading lists. Some issues related to design were flagged, such as wanting the search to default to the user’s home library, and screen options not always flowing through to each page. Focus groups also highlighted lack of awareness around our e-resource collections.

Further development in these areas is planned, as well as revisiting navigation and terminology. We aim to hold annual focus groups, and our next goal is some elements of WCAG 2.0 Level AAA compliance.

Conclusions and future plans

It is still early days for us with Library Search, but so far we feel it is the closest fit for our needs, given our requirements. We have learned a great deal from the process of working together on the project, from involving our own staff and working with a different sort of supplier.

The cost model for open source is something that people are always interested in as nominally it is free from the point of view of software. Unless you have all the skills in house to implement and – in our case – redesign a system, then open source is not free. Implementation and design were handled for us by the company supporting and hosting our system and in collaboration with UAL staff, and the cost of implementation and ongoing support is comparable to some traditional library management systems.

We feel that design is absolutely integral to accessibility and discovery and is much more than simple look and feel. A really interesting point is that it can be difficult to agree between ourselves what good design actually is, and then there is a whole new problem articulating that for a supplier and translating the design into functionality. This is complex and time consuming. We have also learned that good design is an iterative process and we have to keep on developing. Open source is flexible in this way, as others in the community may be thinking along the same lines and we may be able to partner with them. Not everything is as we wanted it to be quite yet. But we are working on it.

We need to think about the staff side of the system and how accessible this is for our own people, in the same way that we have looked at the customer side. The student engagement we have undertaken recently – along with previous feedback – has thrown up some issues, including the need to work harder on customer information literacy (in particular in relation to our e-resources). But that engagement has also increased our understanding of their needs, and we will continue this for the future.