1. The Open University Library: Testing accessibility of eResources
Work at the Open University Library. I’m a Learning and Teaching Library, role to support distance learners via a helpdesk and support academics in integrating library resources within courses. Also have special responsibility for disabilities. Quick over view of testing eResources.
Geraldine Smith 4th July 2008

2. Why? Concern about accessibility of databases/full text material
Promoting use of resources, need to know if any accessibility problems
Can’t support students face to face as all at a distance
Pre-warn students of any problems
Like others here we were concerned about accessibility of databases and the full text material they provide.
Promoting the integration of library resources within courses and needed to know of possible accessibility issues in advance
Unlike a ‘conventional’ university, OU students aren’t on campus and could be studying anywhere in the UK or indeed the world.
Whilst very few databases now completely inaccessible, many have little ‘quirks’ that might confuse someone using a screen reader and mean it takes them longer to navigate their way round a database.
Idea was to be pre-warn students of possible problems and be aware ourselves of issues.

3. When? During trial of a resource
Retrospectively working through list of databases. Giving priority to:
Most important/frequently used
Those providing full text
If course teams want to integrate resource into a course
When are resources tested?
I’m notified of any trials of resources, so that I can test the accessibility of the database. (This will then inform out decision to buy a database. No in a position to always say no if there are accessibility problems, but can affect decision if it is a choice between two resources and one is more accessible than the other)

4. How?
Check keyboard accessibility, ability to change font size, type and colour (background colour)
Accessibility using JAWS
Concentrate on ability to search
Access full text
Browse
As well as testing with a screen reader check accessibility of resource for non mouse users, by seeing if it can be navigated by only using keyboard strokes.
Also check if text and colours can be altered to help people with dyslexia and those who are visually impaired.
Use JAWS to test accessibility of resource for a screen reader user. Don’t have time to test every feature, but concentrate on ability to search and navigate results, accessibility of full text and the browse facility.

5. Results/problems Generally, accessibility of databases is improving.
Examples of problems
Unlabelled or incorrectly labelled search forms
Results listed, so that access to full text is available a link that says PDF, rather than the title of the article, book etc
Confusing, incorrectly labelled frames
Inaccessible image file
If tabbing unable to see where you are on a page
Generally accessibility of databases, including full text is improving.
Examples of the some of the problems I’ve encountered.
Search boxes may not be easy to find
Screen reader users faced with a list of links just saying PDF
Making it hard to move between full text and navigation options
Unable to access full text

6. How is information used?
Brief guidance given to students on the Database Accessibility Issues page
Links from Databases page via an icon
More detailed information written for suppliers
Information stored and discussed with suppliers at next meeting
Helps to inform integration of resources
Will show you the first couple of points via the Library website
Last point - Helps to inform integration of library resources within OU courses
Go to and ‘Databases’ page. Click on link to 19th century newspaper info and show Database Accessibility page – accessible to everyone (Art full text – keyboard users too).