Web Accessibility, Institutional Repositories and BS 8878

Review of Work on Accessibility and Institutional Repositories

Back in December 2006 I wrote a post on Accessibility and Institutional Repositories in which I suggested that it might be “unreasonable to expect hundreds in not thousands of legacy [PDF] resources to have accessibility metadata and document structures applied to them, if this could be demonstrated to be an expensive exercise of only very limited potential benefit“. I went on to suggest that there is a need to “explore what may be regarded as ‘unreasonable’ we then need to define ‘reasonable’ actions which institutions providing institutional repositories would be expected to take“.

A discussion on the costs and complexities of implementing various best practices for depositing resources in repositories continued in September 2008 as I described in a post on Institutional Repositories and the Costs Of Doing It Right, with Les Carr suggesting that “If accessibility is currently out of reach for journal articles, then it is another potential hindrance for OA“. Les was arguing that the costs of providing accessibility resources in institutional repositories is too great and can act as a barrier to maximising open access to institutional research activities.

I agree – but that doesn’t mean that we should abandon any thoughts of exploring ways of enhancing accessibility. A paper on “From Web Accessibility to Web Adaptability” (available in PDF and HTML formats) described an approach called “Web Adaptability” which has the flexibility to account for a variety of contextual factors which is not possible with an approach based purely on conformance with WCAG guidelines. An accompanying blog post which summarised the paper described how the adaptability approach could be applied to institutional repositories”:

Adaptability and institutional repositories: Increasing numbers of universities are providing institutional repositories in order to enhance access to research publications and to preserve such resources for future generations. However many of the publications will be deposited as a PDF resource, which will often fail to conform with accessibility guidelines (e.g. images not being tagged for use with screen readers; text not necessarily being ‘linearised’ correctly for use with such devices, etc.). Rather than rejecting research publications which fail to conform with accessibility guidelines the Web adaptability approach would support the continued use and growth of institutional repositories, alongside an approach based on advocacy and education on ways of enhancing the accessibility of research publications, together with research into innovative ways of enhancing the accessibility of the resources.

The stakeholder approach to Web accessibility, originally developed by Jane Seale for use in an elearning context and described in a joint paper on Accessibility 2.0: People, Policies and Processes (available in PDF, MS Word and HTML formats) has been extended for use in a repository context. The approaches to engagement with some of the key stakeholders is given below:

Education: Training provided (a) for researchers to ensure they are made aware of importance of accessibility practices (including SEO benefits) and of techniques for implementing best practices and (b) for repository managers and policy makers to ensure that accessibility enhancements can be procured in new systems.

Feedback to developers: Ensure that suppliers and developers are aware of importance of accessibility issues  and enhancements featured in development plans.

Feedback to publishers: Ensure that publishers who provide templates are aware of importance of provision of accessible templates.

Auditing: Systematic auditing of papers in repositories to monitor extent of accessibility concerns and trends.

But is this approach valid?  Surely SENDA accessibility legislation requires conformance with WCAG guidelines? And if it is difficult to conform with such guidelines, surely the best approach is to keep a low profile?

BS 8878 Web Accessibility Code of Practice

The BS 8878 Web accessibility Code of practice was launched in December 2010.  A summary of an accompanying Webinar about the Code of Practice was described in a post on BS 8878: “Accessibility has been stuck in a rut of technical guidelines” – and it was interesting to hear how the code of practice has been written in the context of the Equal Act which has replaced the DDA.  I was also very pleased to hear of the user-focus which is at the heart of the code of practice, and how mainstream approaches on best practices have moved away from what was described as a “rut of technical guidelines“.

Although the Code of Practice is not available online and costs £100 to purchase an accompanying set of guidelines was produced by Abilitynet which I have used in the following summary. Note I had to request a copy of these guidelines and I can no longer find the link to contact details to request copies. However AbilityNet’s complete set of guidelines can be purchased for £4,740!

It seems that there is a clear financial barrier to the implementation of new accessibility guidelines. In order to minimise the costs to higher education (which would approach a quarter of a million pounds if all UK Universities were to purchase a copy at the list price!)  I’ll give my interpretation of how the code of practice could be applied in the context of institutional repositories. But please note that this is very much an initial set of suggestions and should not be considered to be legal advice!

The heart of the BS 8878 document is a 16 step plan:

1. Define the purpose.
2. Define the target audience.
3. Analyse the needs of the target audience.
4. Note any platform or technology preferences.
5. Define the relationship the product will have with its target audience.
6. Define the user goals and tasks.
7. Consider the degree of user experience the web product will aim to provide.
8. Consider inclusive design & user-personalised approaches to accessibility.
9. Choose the delivery platform to support.
10. Choose the target browsers, operating systems & assistive technologies to support.
11. Choose whether to create or procure the Web product.
12. Define the Web technologies to be used in the Web product.
13. Use Web guidelines to direct accessibility Web production
14. Assure the Web products accessibility through production (i.e. at all stages).
15. Communicate the Web product’s accessibility decisions at launch.
16. Plan to assure accessibility in all post-launch updates to the product.

Note that Step 13, which covers use of WCAG guidelines, may previously have been regarded as the only or the most significant policy item. BS 8878 places these guidelines in a more appropriate context.

Using BS 8878 for Institutional Repositories

A summary of how I feel each of these steps might be applied to institutional repositories is given below.

1. Define the purpose:
   The purposes of the repository service will be to enhance access to research papers and to support the long term preservation of the papers.
2. Define the target audience:
   The main target audience will be a global research community.
3. Analyse the needs of the target audience:
   Researchers may need to use assistive technologies to read PDFs.
4. Note any platform or technology preferences:
   PDFs may not include accessibility support.
5. Define the relationship the product will have with its target audience:
   The paper will be provided at a stable URI.
6. Define the user goals and tasks:
   Users will use various search tools to find resource. Paper with then be read on screen or printed.
7. Consider the degree of user experience the web product will aim to provide:
   Usability of the PDF document will be constrained by publisher’s template. Technical accessibility will be constrained by workflow processes.
8. Consider inclusive design & user-personalised approaches to accessibility:
   Usability of the PDF document will be constrained by publisher’s template. Technical accessibility will be constrained by workflow processes.
9. Choose the delivery platform to support:
   Aims to be available on devices with PDF support including mobile devices
10. Choose the target browsers, operating systems & assistive technologies to support:
    All?
11. Choose whether to create or procure the Web product:
    The service is provided by repository team.
12. Define the Web technologies to be used in the Web product:
    HTML interface to PDF resources.
13. Use Web guidelines to direct accessibility web production:
    HTML pages will seek to conform with WCAG 2.0 AA. PDF resources may not conform with PDF accessibility guidelines.
14. Assure the Web products accessibility through production (i.e. at all stages):
    Periodic audits of PDF accessibility planned.
15. Communicate the Web product’s accessibility decisions at launch:
    Accessibility statement to be published.
16. Plan to assure accessibility in all post-launch updates to the product:
    Periodic reviews of technical developments.

Step 15 requires the publication of an accessibility statement, which “states in an easy to understand and non-technical way the accessibility features of the site and any known limitations“. This will be the aspect of the accessibility work which will be visible to users of the service. But what might such an accessibility statement cover?

Current Approaches to Accessibility Statements for Repositories

The first step to answering this question was to see what accessibility statements are currently provided for institutional repositories.  An analysis of the first page of results for a Google search for “repository accessibility statement” provided only a single example of an accessibility statement for an institutional repository. This was provided by UBIR, the University of Bolton Institutional Repository and appears to be a description of WCAG conformance for the repository Web pages rather than the contents of the Web site :

Standards Compliance

1. All static pages follow U.S. Federal Government Section 508 Guidelines.
2. All static pages follow priorities 1 & 2 guidelines of the W3C Web Content Accessibility Guidelines.
3. All static pages validate as HTML 4.01 Transitional.
4. All static pages on this site use structured semantic markup. H2 tags are used for main titles, H3 and H4 tags for subtitles.

The Google results for other institutional repositories, including UEA and the University of Salford Informatics Research Institute Repository (USIR) were based on links to standard accessibility statements for the institutional Web site, with the statement for the University of Salford, for example, stating that:

The University of Salford strives to ensure that this website is accessible to everyone. If you have any questions or suggestions regarding the accessibility of this site, or if you come across a page or resource that does not meet your access needs, please contact the webmaster@salford.ac.uk, as we are continually striving to improve the experience for all of our visitors.

It seems that the contents of an institutional repository, the core purpose, after all,  of a repository, do not appear to have statements regarding the accessibility of such contents.  I will admit that I have only had a cursory exploration for such statements and would love to be proved wrong.  But for now let’s assume that the accessibility statement required for step 15 of BS 8878 will have to be produced from scratch.

A Possible Accessibility Statement For An Institutional Repository

Might the following be an appropriate statement for inclusion on an institutional repository?  Please note that I am not a repository manager so I don’t know if such a statement is realistic.  However I should also add that I have deposited 46 of my papers and related articles in the University of Bath repository and am aware of some of the difficulties in ensuring such items will conform with accessibility guidelines for PDFs, MS Word and HTML, the main formats used for depositing items.   Since it is likely to be difficult for the motivated individual author to address accessibility concerns for their own items, we cannot expect best practices to be applied for the 1,568 items deposited in 2010, never mind items deposited before then.

It is therefore not realistic to suggest that authors or repository managers should simply implement the advice on producing accessible PDFs provided by organisations such as JISC TechDis.  Rather the accessibility statement needs to be honest about the limitations of the service and difficulties which people with disabilities may have in accessing items hosted in institutional repositories.

The following draft accessibility statement is therefore suggested as providing a realistic summary regarding the accessibility of a typical repository service.

Statement	Comments
The University’s repository service is an open-access information storage & retrieval system containing the university’s research findings and papers, openly and freely accessible to the research community and public.  A full description of each item is provided, and where copyright regulations permit, the full-text of the research output is stored in the repository and fully accessible. Items are deposited in the repository via a number of resources, including author self-deposit, deposit by authorised staff in departments and deposits by repository staff.	Note this has taken this definition of the purpose of the service from the UEA Digital Repository
Items are normally provided in PDF format although other formats such as MS Word or HTML may also be used.	An audit of file formats may inform this statement.
Items are normally deposited in the format required by the publisher. Popular formats should be accessible using standard viewing tools. However some formats may require specialist browsers to be installed.	An audit of file formats may inform this statement an provide information on how to install any specialist viewers.
Items may not conform to appropriate accessibility guidelines due to the devolved responsibilities for depositing items and the complexities of implementing the guidelines across the large number of items housed in the repository.	If this is the case, it should be stated.
Future developments to the service will include an “Accessibility problem” button which will enable repository staff to be alerted to the scale of accessibility problems.	This should only be included if it is intended to implement such a service.
Repository staff will work with the University Staff Development Unit to ensure that training is provided on ways of creating accessible documents which will be open to all staff and research students.	This should only be included if it is intended to implement such training.
Repository staff will carry out periodic audits on the accessibility of repository items, monitor trends and act accordingly.	This should only be included if it is intended to implement such a service. Note UKOLN have developed a trial application which could implement such a service which was described in a paper on Automated Accessibility Analysis of PDFs in Repositories.
The Web interface to repository content will conform with University Web site accessibility guidelines.	This statement should taken form the policy for the main University’s Web site accessibility statement.

I hope this has provided something to initiative a discussion on ways in which institutional repositories can address accessibility issues which can provide barriers to researchers with disabilities and build on the successes repositories are having in addressing access barriers providing by copyright issues, complex business models and fragmented resources which may be difficult to find and retrieve.