Quality Assurance
Handbook:
Part 4: Quality Assurance For
Web/Access
This handbook provides advice and support for projects
funded by JISC’s digital library programmes. The handbook
provides advice for projects in their choice of standards, best
practices and implementation architectures. The handbook
provides a quality assurance methodology which will help to
ensure that projects funded by JISC’s digital library
programmes are interoperable and widely accessible.
This handbook addresses the issue of Web.
Editor
Brian Kelly, UKOLN
Publication date: 5 May 2006
Version:
1.1
Changes
Added briefing document 02. 16 Dec 2004.
Added briefing document 46. 7 Oct 2004.
Added briefing documents 32, 35, 45, 46, 55, 57, 97
27 Apr 2006.
Table Of Contents
1
2
3
4
Introduction
1
Background
1
About QA Focus
1
Scope Of QA Focus
1
The QA Focus Team
2
About This Handbook
3
Licence For Use Of Content Of The Handbook
3
Briefing Documents
4
Top 10 Web Tips
6
QA for Web Sites: Useful Pointers
8
The Purpose Of Your Project Web Site
10
URI Naming Conventions For Your Project Web Site
12
Changing A Project's Web Site Address
15
Compliance With HTML Standards
17
Use Of Proprietary Formats On Web Sites
19
Approaches To Link Checking
21
Search Facilities For Your Web Site
23
404 Error Pages On Web Sites
25
Enhancing Web Site Navigation Using The LINK Element
27
Accessing Your Web Site On A PDA
29
How To Evaluate A Web Site's Accessibility Level
31
Use of Automated Tools For Testing Web Site Accessibility
34
Accessibility Testing In Web Browsers
37
Performance Indicators For Your Project Web Site
39
Use Of Cascading Style Sheets (CSS)
41
Top 10 Tips For Preserving Web Sites
43
Mothballing Your Web Site
45
Deployment Of XHTML 1.0
47
An Introduction To RSS And News Feeds
49
An Introduction To Wikis
51
Usage Statistics For Web Sites
53
An Introduction To Web Services
55
An Introduction To Web 2.0
57
An Introduction To AJAX
61
Introduction To OPML
63
A URI Interface To Web Testing Tools
65
QA for Web Sites: Useful Pointers
67
Case Studies
69
Edinburgh University Library Online: Work In Progress
70
Gathering Usage Statistics And Performance Indicators: The (NMAP) Experience
73
Usability Testing For The Non-Visual Access To The Digital Library (NoVA) Project 78
Approaches to Accessibility at MIMAS
84
Standards And Accessibility Compliance For The FAILTE Project Web Site
88
Standards And Accessibility Compliance For The DEMOS Project Web Site
91
Strategy For Fixing Non-Compliant HTML Pages On The QA Focus Web Site
99
Exploiting ACRONYM And ABBR HTML Elements
101
Using The ACRONYM And ABBR HTML Elements On The QA Focus Web Site
Providing Access To An EU-funded Project Web Site After Completion of Funding
5 Web Toolkit
Web Toolkit
6 Web Policies and Procedures
Web Policy
Links Policy
7 Further Information
UKOLN
Netskills
Acknowledgements
104
108
111
111
113
113
115
116
116
116
117
1 Introduction
1
Introduction
Background
Welcome to QA Focus’s “Quality Assurance For Web” Handbook. This
handbook has been published by the JISC-funded QA Focus project. The
handbook provides advice on compliance with the standards and best practices
in the area of metadata.
About QA Focus
QA Focus has funded by the JISC to help develop quality assurance
methodology which projects funded by JISC’s digital library programmes
should seek to implement in order to ensure that project deliverables comply
with appropriate standards and best practices which. This will help to ensure
that project deliverables and widely accessible and interoperable and to
facilitate the deployment of deliverables into a service environment.
The approach taken by QA Focus has been developmental: rather than seeking
to impose requirements on projects, which are being undertaken by many
institutions across the country, with differing backgrounds and levels of
funding and resources, we have sought to raise an awareness of JISC’s
commitment to use of open standards, to describe various technical
frameworks which can help in deploying open standards and to outline ways
of ensuring that selected standards and used in a compliance fashion.
We do, however, recognise the difficulties which projects may experience in
implementing open standards (such as, for example, the immaturity of
standards or the poor support for standards by tool vendors; the resource
implications in implementing some of the standards; etc.). We have sought to
address such concerns by developing a matrix framework to assist in the
selection of standards which are appropriate for use by standards, in the light
of available funding, available expertise, maturity of standard, etc.
We hope that the wide range of advice provided in this handbook will be
valuable to projects. However the most important aspect of this handbook is
the quality assurance QA) methodology which is outlined in the handbook.
The QA methodology has been developed with an awareness of the constraints
faced by projects. We have sought to develop a light-weight QA methodology
which can be easily implemented and which should provide immediate
benefits to projects during the development of their deliverables as well as
ensuring interoperability and ease of deployment into service which will help
to ensure the maximum effectiveness of JISC’s overall digital library
development work.
Scope Of QA Focus
QA Focus seeks to ensure technical interoperability and maximum
accessibility of project deliverables. QA Focus therefore has a focus on the
technical aspects of project’s work.
Our remit covers the following technical aspects:
1
1 Introduction
Digitisation: The digitisation of resources, including text, image,
moving image and sound resources.
Access: Access to resources, with particular references to access using
the Web.
Metadata: The use of metadata, such as resource discovery metadata.
Software development: The development and deployment of software
applications.
Service deployment: Deployment of project deliverables into a service
environment.
In addition to these core technical areas we also address:
Standards: The selection and deployment of standards for use by
projects.
Quality assurance: The development of quality assurance procedures by
projects.
QA Focus’s was originally funded to support JISC’s 5/99 programme.
However during 2003 the remit was extended to support JISC’s FAIR and
X4L in addition to 5/99.
The QA Focus Team
QA Focus began its work on 1 January 2002. Initially the service was
provided by UKOLN and ILRT, University of Bristol. However, following
ILRT’s decision to re-focus on their core activities they left QA Focus and
were replaced by the AHDS on 1 January 2003. The project officially finished
in June 2004. Since the documents produced by the project have been made
more widely available to support JISC’s development programme and for
wider use.
This handbook has been developed by members of the QA Focus team: Brian
Kelly, UKOLN (QA Focus project leader), Amanda Closier, UKOLN,
Marieke Guy, UKOL, Hamish James, AHDS and Gareth Knight, AHDS.
2
2 About This Handbook
2
About This Handbook
This handbook provides advice on best practices for use of the Web.
The handbook forms part of a series of Quality Assurance handbooks, which
cover the areas which have been addressed by QA Focus work:
Part 1: About Quality assurance: The development of quality
assurance procedures by projects.
Part 2: Quality Assurance For Standards: The selection and
deployment of standards for use by projects.
Part 3: Quality Assurance For Digitisation: The digitisation of
resources, including text, image, moving image and sound resources.
Part 4: Quality Assurance For Web/Access: Access to resources,
especially access using the Web.
Part 5: Quality Assurance For Metadata: The use of metadata, such as
resource discovery metadata.
Part 6: Quality Assurance For Software: Development and
deployment of software applications.
Part 7: Quality Assurance For Service Deployment: Deployment of
project deliverables into a service environment.
Part 8: Quality Assurance In Other Areas: Quality assurance in areas
not covered elsewhere.
The handbook consists of three main sections:
Briefing Documents: Brief, focussed advice on best practices.
Case studies: Descriptions of the approaches taken by projects to the
deployment of best practices.
Toolkit: Self-assessment checklists which can help ensure that projects
have addressed the key areas.
Licence For Use Of Content Of The Handbook
This handbook contains access to QA Focus briefing document on the topic of
digitisation. The majority of the briefing documents have a Creative Commons
Attribution-NonCommercial-ShareAlike License which grants permission for
third parties to copy, distribute and display the document and to make
derivative works provided:

The authors are given due credit. We suggest the following:
"This document is based on an original document produced by the
JISC-funded QA Focus project provided by UKOLN and AHDS."

You may not use this work for commercial purposes.

If you alter, transform, or build upon this work, you may distribute
the resulting work only under a licence identical to this one.
Briefing documents for which the licence is application are shown
with the illustrated Creative Commons logo.
3
3 Briefing Documents On Web/Access
3
Briefing Documents
Background
This section addresses access to resources, primarily through use of the Web.
The World Wide Web is the key delivery platform for many projects. There is
an expectation that projects will comply with W3C’s standards in this area,
including HTML and CSS.
There is a need to ensure that systematic processes for checking compliance
with such standards and used. It is not appropriate to rely on the appearance on
a Web page in a Web browser as browsers are designed to be tolerant of
errors. In addition we should seek to ensure that resources can be accessed by
accessibility tools (such as speaking browsers) and by non-traditional devices
(such as PDAs).
In addition to access to resources using traditional Web browsers there is an
increasing expectation that resources will be processed by automated software
or delivered in formats other than HTML.
The briefing documents seek to describe best practices in this area.
Briefing Documents
The following briefing documents which address the area of access/Web have
been produced:




















Top 10 Web Tips, (briefing-55)
QA For Web Sites, (briefing-46)
Compliance With HTML Standards (briefing-01)
Use Of Proprietary Formats On Web Sites (briefing-03)
Approaches To Link Checking (briefing-07)
Accessing Your Web Site On A PDA (briefing-05)
Search Facilities For Your Web Site (briefing-08)
404 Error Pages On Web Sites (briefing-05)
Enhancing Web Site Navigation Using The LINK Element (briefing-10)
The Purpose Of Your Project Web Site (briefing-15)
How To Evaluate A Web Site's Accessibility Level (briefing-12)
Use of Automated Tools For Testing Web Site Accessibility (briefing-02)
Accessibility Testing In Web Browsers, (briefing-57)
URI Naming Conventions For Your Project Web Site (briefing-16)
Changing A Project's Web Site Address, (briefing-32)
Performance Indicators For Your Project Web Site (briefing-17)
Use Of Cascading Style Sheets (CSS) (briefing-34)
Deployment Of XHTML 1.0, (briefing-35)
A URI Interface To Web Testing Tool, (briefing-59)
Top 10 Tips For Preserving Web Sites, (briefing-45)
4
3 Briefing Documents On Web/Access
 Mothballing Your Web Site, (briefing-04)
Advisory documents which cover specific technical areas are available within
the section on the appropriate technical area.
5
3 Briefing Documents On Web/Access
Top 10 Web Tips
About This Document
This briefing document gives the top 10 tips for Web site developers.
Citation Details
Top 10 Web Tips, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-55/>
Keywords: Web, tips, briefing
The Top 10 Tips
1
Ensure Your Web Site Complies With HTML Standards
You should ensure that your Web site complies with HTML standards. This will
involve selecting the standard for your Web site (which currently should be either
HTML 4.0 or XHTML 1.0); implementing publishing procedures which will ensure
that your Web pages comply with the standard and quality assurance procedures to
ensure that your publishing processes work correctly [1] [2].
2
Make Use Of CSS – And Ensure The CSS Is Compliant
You should make use of CSS (Cascading Style Sheets) to define the appearance of your
HTML pages. You should seek to avoid use of HTML formating elements (e.g. avoid
spacer GIFs, <FONT> tags, etc.) – although it is recognised that use of tables for
formatting may be necessary in order to address the poor support for CSS-positioning
in some Web browsers. You should also ensure that your CSS is compliant with
appropriate standards [3].
3
Provide A Search Facility For Your Web Site
You should provide a search facility for your project Web site, if is contains more than
a few pages [4] (and externally-hosted search engines are an option if you do not have
the technical resources to install software locally).
4
Ensure Your 404 Error Page Is Tailored
You should aim to ensure that the 404 error page for your Web site is not the default
page but has been configured with appropriate branding, advice and links to appropriate
resources, such as the search facility [5].
5
Have A URI Naming Policy For Your Web Site
You should ensure that you have a URI naming policy for your Web site [6].
6
Check Your Links – And Have a Link-Checking Policy
You should ensure that you check for broken links on your Web site. You should
ensure that links work correctly when pages are created or updated. You should also
ensure that you have a link checking policy which defines the frequency for checking
links and your policy when broken links are detected [7].
7
Think About Accessibility
You should address the accessibility of your Web site from the initial planning stages.
You should ensure that you carry out appropriate accessibility testing and that you have
an accessibility policy [8].
6
3 Briefing Documents On Web/Access
8
Think About Usability
You should address the usability of your Web site from the initial planning stages. You
should ensure that you carry out appropriate usability testing and that you have an
usability policy.
9
Use Multiple Browsers For Checking
You should make use of several browsers for testing the accessibility, usability and
functionality of your Web site. You should consider making use of mainstream
browsers (Internet Explorer, Netscape/Mozilla) together with more specialist browsers
such as Opera.
10
Implement QA Policies For Your Web Site
You should ensure that you have appropriate quality assurance procedures for your
Web site.
References
1
2
3
4
5
6
7
8
Compliance with HTML Standards, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-01/>
Deployment Of XHTML 1.0, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-35/>
Use Of Cascading Style Sheets (CSS), QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-34/>
Search Facilities For Your Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-08/>
404 Error Pages On Web Sites, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-06/>
URI Naming Conventions For Your Project Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-16/>
Approaches To Link Checking, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-07/>
Accessibility Testing, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-02/>
7
3 Briefing Documents On Web/Access
QA for Web Sites: Useful Pointers
About This Document
This briefing document provides some useful pointers and advice on QA for Web sites.
Citation Details
QA for Web Sites: Useful Pointers, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-46/>
Keywords: Web, QA, briefing
Quality Assurance
Below are some key pointers that can help you enhance the Quality Assurance
procedures used for your Web site.
Useful Pointers
1
Authoring Tools Are the tools that you use to create your Web site
appropriate for their tasks? Do they produce compliant and accessible code?
Can the tools be configured to incorporate QA processes such as HTML
validation, link checking, spell checking, etc? If not, perhaps you should
consider evaluating other authoring tools or alternative approaches to
creating and maintaining your content.
2
Tracking Problems How do you deal with problem reporting? Consider
implementing a fault reporting log. Make sure that all defects are reported,
that ownership is assigned, details are passed on to the appropriate person, a
schedule for fixes is decided upon, progress made is recorded and the
resolution of problem is noted. There could also be a formal signing off
procedure.
3 Use A QA Model A model such as the QA Focus Timescale Model will
help you to plan the QA you will need to implement over the course of your
project:
Strategic QA: Carried out before development takes place. This
involves establishing best methodology for your Web site, the choice
of standards, etc.
Workflow QA: Carried out as formative QA before and during
development. This involves establishing and documenting a
workflow, processes etc.
Sign-off QA: Carried out as summative QA once one stage of
development has been carried out. This involves establishing an
auditing system where everything is reviewed.
On-going QA: Carried out as summative QA once one stage of
development has been carried out. This involves establishing a system
to report check, fix any faults found etc.
4 Use Automated Testing Tools There are a variety of tools out there for
use and a number are open source or free to use. These can be used for
HTML and CSS validation, link checking, measuring load times, etc.
8
3 Briefing Documents On Web/Access
5 Don’t Forget Manual Approaches Manual approaches to Web site testing
can address areas which will not be detecting through use of automated
tools. You should aim to test key areas of your Web site and ensure that
systematic errors which are found are addressed in areas of the Web site
which are not tested.
6 Use A Benchmarking Approach A benchmarking approach involves
comparisons of the findings for your Web site with your peers. This enables
comparisons to be made which can help you identify areas in which you
may be successful and also areas in which you may be lagging behind your
peers.
7 Rate The Severity Of Problems You could give a severity rating to
problems found to decide whether the work be done now or it can wait till
the next phase of changes. An example rating system might be:
Level 1: There is a failure in the infrastructure or functionality
essential to the Web site.
Level 2: The functionality is broken, pages are missing, links are
broken, graphics are missing, there are navigation problems, etc.
Level 3: There are browser compatibility problems, page formatting
problems, etc.
Level 4: There are display issues for example with the font or text
issues such as grammar.
8 Learn From The Problems You Find Make sure that do not just fix
problems you find, but understand why the problems have occurred so that
you can improve your publishing processes so that the errors do not
reoccur.
Useful URLs
The following URLs may be of interest.

Understanding Quality,
URL: <http://www.philosophe.com/qa/quality.html>

Testing Without A Formal Test Plan,
URL: <http://www.philosophe.com/testing/without_testplans.html>

W3C Quality Assurance,
URL: <http://www.w3.org/2001/06tips/>
9
3 Briefing Documents On Web/Access
The Purpose Of Your Project Web Site
About This Document
This briefing document describes the importance of having a clear understanding of the
purpose of your Web site.
Citation Details
The Purpose Of Your Project Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-15/>
Keywords: Web, purpose, briefing
Background
Before creating a Web site for your project you should give some thought to
the purpose of the Web site, including the aims of the Web site, the target
audiences, the lifetime, resources available to develop and maintain the Web
site and the technical architecture to be used. You should also think about
what will happen to the Web site once project funding has finished.
Purposes
Your project Web site could have a number of purposes. For example:

The Web site could provide information about the project.

The Web site could provide access to the project deliverables.

The Web site could be used to support communications with members
of the project team.

The Web site could act as a repository of information about the
management of the projects, including minutes of meetings, reports to
funders, etc.
Your Web site could, of course, fulfil more than a single role. Alternatively
you may choose to provide more than one Web site.
Why You Need To Think About The Different Purposes
You should have an idea of the purposes of your project Web site before
creating it for a number of reasons:

You may wish to have more stringent QA procedures for Web sites
which are intended for a broad audience and which is intended to have
a longer lifetime.

You may wish to be proactive in promoting a Web site intended for
public use.

You may wish to be proactive in ensuring that a Web site which is not
intended for public use does not become indexing by search engines or
is not linked to be mistake.

You may wish to allow a public Web site to be indexed and archived
by third parties.
10
3 Briefing Documents On Web/Access

You may wish to ensure that a Web site intended for use by project
partners or other closed communities is not indexed or archived,
especially if there may be confidentiality or data protection issues.
Web Site For Information About The Project
Once funding has been approved for your project Web site you may wish to
provide information about the project, often prior to the official launch of the
project and before project staff are in post. There is a potential danger that this
information will be indexed by search engines or treated as the official project
page. You should therefore ensure that the page is updated once an official
project Web site is launched so that a link is provided to the official project
page. You may also wish to consider stopping search engines from indexing
such pages by use of the Standard For Robot Exclusion [1].
Web Site For Access To Project Deliverables
Many projects will have an official project Web site. This is likely to provide
information about the project such as details of funding, project timescales and
deliverables, contact addresses, etc. The Web site may also provide access to
project deliverables, or provide links to project deliverables if they are
deployed elsewhere or are available from a repository.
Usually you will be proactive in ensuring that the official project Web site is
easily found. You may wish to submit the project Web site to search engines.
Web Site To Support Communications With Project Partners
Projects with several partners may have a Web site which is used to support
communications with project partners. The Web site may provide access to
mailing lists, realtime communications, decision-making support, etc. The
JISCMail service may be used or commercial equivalents such as
YahooGroups. Alternatively this function may be provided by a Web site
which also provides a repository for project resources.
Web Site As Repository For Project Resources
Projects with several partners may have a Web site which is used to provide a
repository for project resources. The Web site may contain project plans,
specifications, minutes of meetings, reports to funders, financial information,
etc. The Web site may be part of the main project Web site, may be a separate
Web site (possibly hosted by one of the project partners) or may be provided
by a third party. You will need to think about the mechanisms for allowing
access to authorised users, especially if the Web site contains confidential or
sensitive information.
References
1. robots.txt Robots Exclusion Standard,
<http://www.robotstxt.org/>
11
3 Briefing Documents On Web/Access
URI Naming Conventions For Your Project Web Site
About This Document
This briefing document describes the importance of establishing URI naming
policies for your Web site.
Citation Details
URI Naming Conventions For Your Project Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-16/>
Keywords: Web, URI, URL, guidelines, naming conventions, briefing
Background
Once you have agreed on the purpose(s) of your project Web site(s) [1] you
will need to choose a domain name for your Web site and conventions for
URIs. It is necessary to do this since this can affect (a) the memorability of the
Web site and the ease with which it can be cited; (b) the ease with which
resources can be indexed by search engines and (c) the ease with which
resources can be managed and repurposed.
Domain Name
You may wish to make use of a separate domain name for your project Web
site. If you wish to use a .ac.uk domain name you will need to ask UKERNA.
You should first check the UKERNA rules [2]. A separate domain name has
advantages (memorability, ease of indexing and repurposing, etc) but this may
not be appropriate, especially for short-term projects. Your organisation may
prefer to use an existing Web site domain.
URI Naming Conventions
You should develop a policy for URIs for your Web site which may include:




Conventions on use of case (e.g. specifying that all resources should be in
lower case), separators (e.g. a hyphen should be used to separate
components of a URI) and permitted characters (e.g. spaces should not be
used in URIs).
Conventions on the directory structure. The directory structure may be
based on the main functions provided by your Web site.
Conventions on dates and version control. You may wish to agreed on a
convention for including dates in URIs. You may also wish to agree on a
convention for version control (which could make use of date
information).
Conventions for file names and formats.
Issues
Grouping Of Resources
It is strongly recommended that you make use of directories to group related
resources. This is particularly important for the project Web site itself and for
key areas of the Web site. The entry point for the Web site and key areas
12
3 Briefing Documents On Web/Access
should be contained in the directory itself: e.g. use
http://www.foo.ac.uk/bar/ to refer to project BAR and not
http://www.foo.ac.uk/bar.html) as this allows the bar/ directory
to be processed in its entirety, independently or other directories. Without this
approach automated tools such as indexing software, and tools for auditing,
mirroring, preservation, etc. would process other directories.
URI Persistency
You should seek to ensure that URIs are persistent. If you reorganise your
Web site you are likely to find that internal links may be broken, that external
links and bookmarks to your resources are broken, that citations to resources
case to work. You way wish to provide a policy on the persistency of URIs on
your Web site.
File Names and Formats
Ideally the address of a resource (the URI) will be independent of the format
of the resource. Using appropriate Web server configuration options it is
possible to cite resources in a way which is independent of the format of the
resource. This should allow easy of migration to new formats (e.g. HTML to
XHTML) and, using a technology known as Transparent Content Negotiation
[3] provide access to alternative formats (e.g. HTML or PDF) or even
alternative language versions.
File Names and Server-Side Technologies
Ideally URIs will be independent of the technology used to provide access to
the resource. If server-side scripting technologies are given in the file
extension for URIs (e.g. use of .asp, .jsp, .php, .cfm, etc. extensions)
changing the server-side scripting technology would probably require
changing URIs. This may also make mirroring and repurposing of resources
more difficult.
Static URIs Or Query Strings?
Ideally URIs will be memorable and allow resources to be easily indexed and
repurposed. However use of Content Management Systems or databases to
store resources often necessitates use of URIs which contain query strings
containing input parameters to server-side applications. As described above
this can cause problems.
Possible Solutions
You should consider the following approaches which address some of the
concerns:
 Using file extensions: e.g. foo refers to foo.html or foo.asp
 Using directory defaults: e.g. foo/ refers to foo/intro.html or
foo/intro.asp
 Rewriting dynamic URIs to static URIs
13
3 Briefing Documents On Web/Access
References
1. The Purpose Of Your Project Web Site, QA Focus,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing15/html/>
2. UKERNA, <http://www.ukerna.ac.uk>
3. Transparent Content Negotiation,W3C,
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html>
14
3 Briefing Documents On Web/Access
Changing A Project's Web Site Address
About This Document
This QA Focus briefing document advises on procedures when you need to change the
address of your project Web site.
Citation Details
Changing A Project's Web Site Address, QA Focus, UKOLN, <http://www.ukoln.ac.uk/qafocus/documents/briefings/briefing-32/>
Keywords: Web, URL, URLs, domain, Web Site address, briefing
Background
A project’s Web site address will provide, for many, the best means for
finding out about the project, reading abouts its activities and using the
facilities which the projects provides. It is therefore highly desirable that a
project’s Web site address remains stable. However there may be occasions
when it is felt necessary to change a project’s Web site address. This
document provides advice on best practices which should help to minimise
problems.
Best Practices For A Project Web Site Address
Ideally the entry point for project’s Web site will be short and memorable.
However this ideal is not always achievable. In practice we are likely to find
that institutional or UKERNA guidelines on Web addresses preclude this
option.
The entry point should be a simple domain name such as
<http://www.project.ac.uk/> or a directory such as
<http://www.university.ac.uk/depts/library/project/>. Avoid use of a file name
such as <http://www.university.ac.uk/depts/library/project/Welcome.html> as
this makes the entry point longer and less memorable and can cause problems
if the underlying technologies change.
Reasons For Changing
If the address of a project Web site is determined by institutional policies, it is
still desirable to avoid changing the address unnecessarily. However there may
be reasons why a change to the address is needed.
Implementing Best Practices: There may be an opportunity to implement
best practices for the address which could not be done when the Web site was
launched.
Changes In Organisation’s Name: The name of an institution may change
e.g. the institution is taken over or merges with another institution.
Changes In Organisational Structure: The organisational structure may
change e.g. departments may merge or change their name.
Changes In Project Partners: The project partner hosting the Web site may
leave the project.
15
3 Briefing Documents On Web/Access
Project Becomes Embedded In Organisation: The project may become
embedded within the host institution and this requires a change in the address.
Project Is Developed With Other Funding Streams: The project may
continue to be developed through additional funding streams and this requires
a change in the address.
Project Becomes Obsolete: The project may be felt to be obsolete.
Technical Changes: Technological changes may necessitate a change in the
address.
Changes In Policies: Institutional policy changes may necessitate a change in
the address.
Changes In Web Site Function: The project Web site may change its
function or additional Web sites may be needed. For example, the main Web
site may initially be about the project and a new Web site is to be launched
which provides access to the project deliverables.
Advice On Changing Addresses
Projects should consider potential changes to the Web site address before the
initial launch and seek to avoid future changes or to minimise their effect.
However if this is not possible the following advice is provided:
Monitor Links: Prior to planning a change use the www.linkpopularity.com
(or equivalent) service to estimate the numbers of links to you Web sites.
Monitor Search Engines: Examine the numbers of resources from your Web
site which are indexed by popular search engines.
This information will give you an indication of the impact a change to your
Web site address may have. If you intend to change the address you should:
Consider Technical Issues: How will the new Web site be managed? How
will resources be migrated?
Consider Migration: How will the change of address be implemented? How
will links to the old address be dealt with? How will you inform users of the
change?
Inform Stakeholders: Seek to inform relevant stakeholders, such as funding
bodies, partners and others affected by the change.
Checking Processes
It is advisable to check links prior to the change and afterwards, to ensure that
no links are broken during the change. You should seek to ensure that links on
your Web site go to the new address.
16
3 Briefing Documents On Web/Access
Compliance With HTML Standards
About This Document
This briefing document summarises the importance of complying fully with HTML standards
and approaches for checking compliance.
Citation Details
Compliance With HTML Standards, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-01/>
Keywords: Web, HTML, standards, compliance, briefing
Why Bother?
Compliance with HTML standards is needed for a number of reasons:




HTML compliant resources are more likely to be accessible to a wide
range of Web browsers including desktop browsers such as Internet
Explorer, Netscape, Mozilla, Opera, Lynx and specialist browsers on
PDAS, digital TVs, kiosks, etc.
HTML compliant resources are more easily processed and repurposed
by other applications.
HTML compliant resources will be rendered more quickly by modern
browsers.
HTML compliance is required by the AAA W3C WAI accessibility
guidelines.
Which Standards?
The World Wide Web Consortium, W3C, recommend use of the XHTML 1.0
(or higher) standard. This has the advantage of being an XML application
(allowing use of XML tools) and can be rendered by most browsers. However
authoring tools which are widely deployed may not yet produce XHTML and
there may be financial implications (licence costs, training, etc.) in upgrading.
In such circumstances HTML 4.0 may be used.
Cascading style sheets (CSS) should be used in conjunction with
XHTML/HTML to describe the appearance of Web resources.
Approaches To Creating HTML Resources
Web resources may be created in a number of ways. Often HTML authoring
tools such as DreamWeaver, FrontPage, etc. are used, although experienced
HTML authors may prefer to use a simple editing tool. Another approach is to
make use of a Content Management System. An alternative approach is to
convert proprietary file formats (e.g. MS Word or PowerPoint). In addition
sometimes proprietary formats are not converted but are stored in their native
format.
Monitoring Compliance
A number of approaches may be taken to monitoring compliance with HTML
standards. For example you can make use of validation features provided by
17
3 Briefing Documents On Web/Access
modern HTML authoring tools, use desktop compliance tools or Web-based
compliance tools.
The different tools can be used in various ways. Tools integrated with an
HTML authoring tool are used by the page author. It is important that the
author is trained to use such tools on a regular basis. It should be noted that it
may be difficult to address systematic errors (e.g. all files missing the
DOCTYPE declaration) with this approach.
A popular approach is to make use of SSIs (server-side includes) to retrieve
common features (such as headers, footers, navigation bars, etc.). This can be
useful for storing HTML elements (such as the DOCTYPE declaration) in a
manageable form. However this may cause validation problems if the SSI is
not processed.
Another approach is to make use of a Content Management System or similar
server-side technique, such as retrieving resources from a database. In this
case it is essential that the template used by the CMS complies with standards.
It may be felt necessary to separate the compliance process from the page
authoring. In such cases use of a dedicated HTML checker may be needed.
Such tools are often used in batch, to validate multiple files. In many cases
voluminous warnings and error messages may be provided. This information
may provide indications of systematic errors which should be addressed in
workflow processes.
An alternative approach is to use Web-based checking services. An advantage
with this approach is that the service may be used in a number of ways: the
service may be used directly by entering the URL of a resource to be validated
or live access to the checking service may be provided by including a link
from a validation icon as used at <http://www.ukoln.ac.uk/qafocus/> as shown in Figure 1 (this approach could be combined with use of
cookies or other techniques so that the icon is only displayed to an
administrator).
Figure 1: Using Icons As ‘Live Links to Validation Services
Another approach is to configure your Web server so that users can access the
validation service by appending an option to the URL. For further information
on this technique see <http://www.ukoln.ac.uk/,tools> and
<http://www.ariadne.ac.uk/issue34/web-focus/>. This
technique can be deployed with a simple option on your Web server’s
configuration file.
18
3 Briefing Documents On Web/Access
Use Of Proprietary Formats On Web Sites
About This Document
This briefing document describes approaches which can be taken when it is felt
necessary to provide access to proprietary file formats on a Web site.
Citation Details
Use Of Proprietary Formats On Web Sites, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-03/>
Keywords: Web, standards, proprietary formats, Microsoft, MS Word, MS PowerPoint,
Microsoft, briefing
Use Of Proprietary Formats
Although it is desirable to make use of open standards such as XHTML when
providing access to resources on Web sites there may be occasions when it is
felt necessary to use proprietary formats. For example:
 It is necessary to provide control over the page appearance which can
only be achieved easily using formats such as MS Word, Adobe PDF,
etc.
 Open standards are not available or tools are not yet widely deployed.
 Web access is used as a mechanism for delivering files.
 Conversion to an open format would be resource-intensive.
 The resource was created by a third-party and you do not have access
to tools to convert the resource.
URL Naming Conventions For Access To Proprietary Formats
If it is necessary to provide access to a proprietary file format you should not
cite the URL of the proprietary file format directly. Instead you should give
the URL of a native Web resource, typically a HTML page. The HTML page
can provide additional information about the proprietary format, such as the
format type, version details, file size, etc. If the resource is made available in
an open format at a later date the HTML page can be updated to provide
access to the open format – this would not be possible if the URL of the
proprietary file was used.
An example of this approach is illustrated. In this case access to MS
PowerPoint slides are available from a HTML page. The link to the file
contains information on the PowerPoint version details.
Note that HTML resources generated in this way should be stored in their own
directory so that they can be managed separately from other resources.
19
3 Briefing Documents On Web/Access
Converting Proprietary Formats
Various tools may be available to convert resources from a proprietary format
to HTML. Many authoring tools nowadays will enable resources to be
exported to HTML format. However the HTML may not comply with HTML
standards or use CSS and it may not be possible to control the look-and-feel of
the generated resource.
Another approach is to use a specialist conversion tool which may provide
greater control over the appearance of the output, ensure compliance with
HTML standards, make use of CSS, etc.
If you use a tool to convert a resource to HTML it is advisable to store the
generated resource in its own directory in order to be able to manage the
master resource and its surrogate separately.
You should also note that some conversion tools can be used dynamically,
allowing a proprietary format to be converted to HTML on-the-fly.
MS Word
MS Word files can be saved as HTML from within MS Word itself. However
the HTML that is created is of poor quality, often including proprietary or
deprecated HTML elements and using CSS in a form which is difficult to
reuse.
MS PowerPoint
MS PowerPoint files can be saved as HTML from within MS PowerPoint
itself. However the Save As option provides little control over the output.
The recommended approach is to use the Save As Web Page option and
then to chose the Publish button. You should then ensure that the HTML
can be read by all browsers (and not just IE 4.0 or later). You should also
ensure that the file has a meaningful title and the output is stored in its own
directory.
Dynamic Conversion
In some circumstances it may be possible to provide a link to an online
conversion service. Use of Adobe’s online conversion service for converting
files from PDF is illustrated.
It should be noted that this approach may result in a loss of quality from the
original resource and is dependent on the availability of the remote service.
However in certain circumstances it may be useful.
20
3 Briefing Documents On Web/Access
Approaches To Link Checking
About This Document
This briefing document describes approaches to use of link checking tools and highlights
possible limitations of such tools.
Citation Details
Approaches To Link Checking, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-07/>
Keywords: Web, links, link checking, briefing
Why Bother?
There are several reasons why it is important to ensure that links on Web sites
work correctly:
 Web sites are based on hyperlinking, and if hyperlinks fail to work,
the Web site can be regarded as not working correctly.
 Broken links reflect badly on the body hosting the Web sites.
 Hyperlinks are increasingly being used to deliver the functionality of
Web sites, through links to JavaScript resources, style sheets files,
metadata, etc. Broken links to these resources will result in the Web
site not functioning as desired.
However there are resource implications in maintaining link integrity.
Approaches To Link Checking
A number of approaches can be taken to checking broken links:
 Web site maintainer may run a link checking tool.
 A server-based link checking tool may send email notification of
broken links.
 A remote link checking service may send email notification of broken
links.
 Web server error log files may be analysed for requests for nonexistent resources.
 Web server 404 error pages may provide a mechanism for users
notifying the Web site maintainer of broken links.
Note that these approaches are not exclusive: Web site maintainers may
choose to make use of several approaches.
Policy Issues
There is a need to implement a policy on link checking. The policy could be
that links will not be checked or fixed – this policy might be implemented for
a project Web site once the funding has finished. For a small-scale project
Web site the policy may be to check links when resources are added or
updated or if broken links are brought to the project’s attention, but not to
21
3 Briefing Documents On Web/Access
check existing resources – this is likely to be an implicit policy for some
projects.
For a Web site one which has a high visibility or gives a high priority to the
effectiveness of the Web site, a pro-active link checking policy will be needed.
Such a policy is likely to document the frequency of link checking, and the
procedures for fixing broken links. As an example of approaches taken to link
checking by a JISC service, see the article about the SOSIG subject gateway
[1].
Tools
Experienced Web developers will be familiar with desktop link-checking
tools, and many lists of such tools are available [2] [3]. However desktop
tools normally need to be used manually. An alternative approach is to use
server-based link-checking software which send email notification of broken
links.
Externally-hosted link-checking tools may also be used. Tools such as
LinkValet [4] can be used interactively or in batch. Such tools may provide
limited checking for free, with a licence fee for more comprehensive checking.
Another approach is to use a browser interface to tools, possibly using a
Bookmarklet [5] although UKOLN’s server-based ,tools approach [6] [7] is
more manageable.
Other Issues
It is important to ensure that link checkers check for links other than <a
href="">. There is a need to check that external JavaScript and CSS files
(referred to by the <link> tag) and that checks are carried out on
personalised interfaces to resources.
References
1
A Spring-Clean For SOSIG: A Systematic Approach To Collection
Management, Huxley, L., Place, E., Boyd, D. and Cross, P., Ariadne,
issue 33, <http://www.ariadne.ac.uk/issue33/planet-sosig/>
2
Open Directory,
<http://dmoz.org/Computers/Software/Internet/Site_Management/
Link_Management/>
3
Google Directory,
<http://directory.google.com/Top/Computers/Software/
Internet/Site_Management/Link_Management/>
4
LinkValet, <http://www.htmlhelp.com/tools/valet/>
5
Bookmarklets, <http:// www.bookmarklets.com/>
6
,tools, <http://www.ukoln.ac.uk/,tools>
7
Interfaces To Web Testing Tools, Ariadne issue 34,
<http://www.ariadne.ac.uk/issue34/web-focus/>
22
3 Briefing Documents On Web/Access
Search Facilities For Your Web Site
About This Document
This briefing document describes approaches for providing search facilities on a Web site in
order to improve its usability.
Citation Details
Search Facilities For Your Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-08/>
Keywords: Web, searching, searching, briefing
Background
Web sites which contain more than a handful of pages should provide a search
facility. This is important for several reasons:
 End users will not be aware of the size of your Web site, and so will
wish to use a search tool to explore it.
 End users will not necessary understand the browse structure of your
Web site.
 Search engines are one of the most widely used tools by end users.
However there are resource implications in maintaining link integrity.
Approaches To Providing Search Facilities
The two main approaches to the provision of search engines on a Web site are
to host a search engine locally or to make use of an externally-hosted search
engine.
Local Search Engine
The traditional approach is to install search engine software locally. The
software may be open source (such as ht://Dig [1]) or licensed software (such
as Inktomi [2]). It should be noted that the search engine software does not
have to be installed on the same system as the Web server. This means that
you are not constrained to using the same operating system environment for
your search engine as your Web server.
Because the search engine software can hosted separately from the main Web
server it may be possible to make use of an existing search engine service
within the organisation which can be extended to index a new Web site.
Externally-Hosted Search Engine
An alternative approach is to allow a third party to index your Web site. There
are a number of companies which provide such services. Some of these
services are free: they may be funded by advertising revenue. Such services
include Google [3], Atomz [4] and FreeFind [5].
Pros And Cons
Using a locally-installed search engine gives you control over the software.
You can control the resources to be indexed and those to be excluded, the
23
3 Briefing Documents On Web/Access
indexing frequency, the user interface, etc. However such control may have a
price: you may need to have technical expertise in order to install, configure
and maintain the software.
Using an externally-hosted search engine can remove the need for technical
expertise: installing an externally-hosted search engine typically requires
simply completing a Web form and then adding some HTML code to your
Web site. However this ease-of-use has its disadvantages: typically you will
lose the control over the resources to be indexed, the indexing frequency, the
user interfaces, etc. In addition there is the dependency on a third party, and
the dangers of a loss of service if the organisation changes its usage
conditions, goes out of business, etc.
Trends
Surveys of search facilities used on UK University Web sites have been
carried out since 1998 [6]. This provides information not only on the search
engines tools used, but also to spot trends.
Since the surveys began the most widely used tool has been ht://Dig – an open
source product. In recent years the licensed product Inktomi has shown a
growth in usage. Interestingly, use of home-grown software and specialist
products has decreased – search engine software appears now to be a
commodity product.
Another interesting trend appears to be in the provision of two search
facilities; a locally-hosted search engine and a remote one – e.g. see the
University of Lancaster [7].
References
1 ht://Dig, <http://www.htdig.org/>
2 Inktomi, <http://www.inktomi.com/>
3 Google, <http://services.google.com/googleuniv/login>
4 Atomz, <http://www.atomz.com/>
5 FreeFind <http://www.freefind.com/>
6 Surveys of Search Engines on UK University Web Sites,
<http://www.ukoln.ac.uk/web-focus/surveys/uk-he-search-engines/>
7 University of Lancaster Search Page,
<http://www.lancs.ac.uk/search.htm>
24
3 Briefing Documents On Web/Access
404 Error Pages On Web Sites
About This Document
This briefing document describes how to improve the usability of a Web site by providing an
appropriately configured 404 error page.
Citation Details
404 Error Pages On Web Sites, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-06/>
Keywords: Web, 404, error page, briefing
Importance Of 404 Error Pages
A Web sites 404 error page can be one of the most widely accessed pages on a
Web site. The 404 error page can also act as an important navigational tool,
helping users to quickly find the resource they were looking for. It is therefore
important that 404 error pages provide adequate navigational facilities. In
addition, since the page is likely to be accessed by many users, it is desirable
that the page has an attractive design which reflects the Web sites look-andfeel.
Types Of 404 Error Pages
Web servers will be configured with a default 404 error page. This default is
typically very basic.
In the example shown the
404 page provides no
branding, help information,
navigational bars, etc.
An example of a richer 404
error page is illustrated. In
this example the 404 page
is branded with the Web
site’s colour scheme,
contains the Web site’s
standard navigational
facility and provide help
information.
25
3 Briefing Documents On Web/Access
Functionality Of 404 Error Pages
It is possible to define a number of types of 404 error pages:
Server Default
The server default 404 message is very basic. It will not carry any branding or
navigational features which are relevant to the Web site.
Simple Branding, Navigational Features Or Help Information
The simplest approach to configuring a 404 page is to add some simple
branding (such as the name of the Web site) or basic navigation features (link
to the home page) or help information (an email address).
Richer Branding, Navigational Features, Help Information Or
Additional Features
Some 404 pages will make use of the Web sites visual identity (such as a logo)
and will contain a navigational bar which provides access to several areas of
the Web site. In addition more complete help information may be provided as
well as additional features such as a search facility.
Full Branding, Navigational Features, Help Information And
Additional Features
A comprehensive 404 page will ensure that all aspects of branding,
navigational features, help information and additional features such as a search
facility are provided.
As Above Plus Enhanced Functionality
It is possible to provide enhanced functionality for 404 pages such as context
sensitive help information or navigational facilities, feedback mechanisms to
the page author, etc.
Further Information
An article on 404 error pages, based on a survey of 404 pages in UK
Universities is available at <http://www.ariadne.ac.uk/issue20/404/>. An
update is available at <http://www.ariadne.ac.uk/issue32/web-watch/>.
26
3 Briefing Documents On Web/Access
Enhancing Web Site Navigation Using The LINK
Element
About This Document
This briefing document describes how the <LINK> element can be used to enhance the
usability of a Web site.
Citation Details
Enhancing Web Site Navigation Using The LINK Element, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-10/>
Keywords: Web, HTML, link, navigation, usability, briefing
About This Document
This document provides advice on how the HTML <link> element can be
used to improve the navigation of Web sites.
The LINK Element
About
The purpose of the HTML <link> element is to specify relationships with
other documents. Although not widely used the <link> element provides a
mechanism for improving the navigation of Web sites.
The <link> element should be included in the <head> of HTML documents.
The syntax of the element is: <link rel=”relation” href=”url”>.
The key relationships which can improve navigation are listed below.
Relation
next
Function
Refers to the next document in a linear sequence.
prev
Refers to the previous document in a linear sequence.
home
Refers to the home page or the top of some hierarchy.
start
Refers to the first document in a collection of documents.
contents
Refers to a document serving as a table of contents.
help
Refers to a document offering help.
glossary
Refers to a document providing a glossary of terms that
pertain to the current document.
Table 1: Key Link Relations
Benefits
Use of the <link> element enables navigation to be provided in a consistent
manner as part of the browser navigation area rather than being located in an
arbitrary location in the Web page. This has accessibility benefits. In addition
browsers can potential enhance the performance by pre-fetching the next page
in a sequence.
27
3 Briefing Documents On Web/Access
Browser Support
A reason why <link> is not widely used has been the lack of browser
support. This has changed recently and support is now provided in the latest
versions of the Opera and Netscape/Mozilla browsers and by specialist
browsers (e.g. iCab and Lynx).
Since the <link> element degrades gracefully (it does not cause problems for
old browser) use of the <link> element will cause no problems for users of
old browsers.
An illustration of how the <link> element is implemented in Opera is shown
below.
Figure 1: Browser Support For The <link> Element
In Figure 1 a menu of navigational aids is available. The highlighted options
(Home, Contents, Previous and Next) are based on the relationships which
have been defined in the document. Users can use these navigational options
to access the appropriate pages, even though there may be no corresponding
links provided in the HTML document.
Information Management Challenges
It is important that the link relationships are provided in a manageable way. It
would not be advisable to create link relationships by manually embedding
them in HTML pages if the information is liable to change.
It is advisable to spend time in defining the on key navigational locations, such
as the Home page (is it the Web site entry point, or the top of a sub-area of the
Web site). Such relationships may be added to templates included in SSIs.
Server-side scripts are a useful mechanism for exploiting other relationships,
such as Next and Previous – for example in search results pages.
28
3 Briefing Documents On Web/Access
Accessing Your Web Site On A PDA
About This Document
This briefing document describes how making your Web site available on a PDA using a
freely available service can help to identify possible problem areas when your Web resources
are repurposed by tools.
Citation Details
Accessing Your Web Site On A PDA, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-05/>
Keywords: Web, PDA, Avantgo, reuse, re-purpose, briefing
About This Document
With the growing popularity in use of mobile devices and pervasive
networking on the horizon we can expect to see greater use of PDAs (Personal
Digital Assistants) for accessing Web resources.
This document describes a method for accessing a Web site on a PDA. In
addition this document highlights issues which may make access on a PDA
more difficult.
AvantGo
About
AvantGo is a well-known Web based service which
provides access to Web resources on a PDA such as a
Palm or Pocket PC.
The AvantGo service is freely available from
<http://www.avantgo.com/>.
Once you have registered on the service you can provide
access to a number of dedicated AvantGo channels. In
addition you can use an AvantGo wizard to provide access
to any publicly available Web resources on your PDA.
An example of two Web sites showing the interface on a
Palm is illustrated.
Benefits
If you have a PDA you may find it useful to use it to
provide access to your Web site, as this will enable you to
access resources when you are away from your desktop
PC. This may also be useful for your project partners. In
addition you may wish to encourage users of your Web site
to access it in this way.
Other Benefits
AvantGo uses robot software to access your Web site and process it in a
format suitable for viewing on a PDA, which typically has more limited
29
3 Briefing Documents On Web/Access
functionality, memory, and viewing area than a desktop PC. The robot
software may not process a number of features which may be regarded as
standard on desktop browsers, such as frames, JavaScript, cookies, plugins,
etc.
The ability to access a simplified version of your Web site can provide a
useful mechanism for evaluating the ease with which your Web site can be
repurposed and for testing the user interface under non-standard environments.
You should be aware of the following potential problem areas:
Entry Point Not Contained In Project Directory
If the project entry point is not contained in the project’s directory, it is
likely that the AvantGo robot will attempt to download an entire Web site
and not just the project area.
Frames
If your Web site contains frames and you do not use the appropriate option
to ensure that the full content can be accessed by user agents which do not
support frames (such as the AvantGo robot software) resources on your
Web site will not be accessible.
Plugin Technologies
If your Web site contains technologies which require plugins (such as
Flash, Java, etc.) you will not be able to access the resources.
Summary
As well as providing enhanced access to your Web site use of tools such as
AvantGo can assist in testing access to your Web site. If your Web site makes
use of open standards and follows best practices it is more likely that it will be
usable on a PDA and by other specialist devices.
You should note, however, that use of open standards and best practices
will not guarantee that a Web site will be accessible on a PDA.
30
3 Briefing Documents On Web/Access
How To Evaluate A Web Site's Accessibility
Level
About This Document
This briefing document describes approaches for evaluating the accessibility of a Web site.
Citation Details
How To Evaluate A Web Site's Accessibility Level, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-12/>
Keywords: Web, accessibility, evaluation, WAI, briefing
Background
Many Web developers and administrators are conscious of the need to ensure
that their Web sites reach as high a level of accessibility as possible. But how
do you actually find out if a site has accessibility problems? Certainly, you
cannot assume that if no complaints have been received through the site
feedback facility (assuming you have one), there are no problems. Many
people affected by accessibility problems will just give up and go somewhere
else.
So you must be proactive in rooting out any problems as soon as possible.
Fortunately there are a number of handy ways to help you get an idea of the
level of accessibility of the site which do not require an in-depth
understanding of Web design or accessibility issues. It may be impractical to
test every page, but try to make sure you check the Home page plus as many
high traffic pages as possible.
Get A Disabled Person To Look At The Site
If you have a disability, you have no doubt already discovered whether your
site has accessibility problems which affect you. If you know someone with a
disability which might prevent them accessing information in the site, then ask
them to browse the site, and tell you of any problems. Particularly affected
groups include visually impaired people (blind, colour blind, short or long
sighted), dyslexic people and people with motor disabilities (who may not be
able to use a mouse).
If you are in Higher Education your local Access Centre [1] may be able to
help.
View The Site Through A Text Browser
Get hold of a text browser such as Lynx [2] and use it to browse your site.
Problems you might uncover include those caused by images with no, or
misleading, alternative text, confusing navigation systems, reliance on
scripting or poor use of frames.
Browse The Site Using A Speech Browser
You can get a free evaluation version of IBM's Homepage Reader [3] or
pwWebSpeak [4] speech browsers used by many visually impaired users of the
31
3 Briefing Documents On Web/Access
Web. The browsers "speak" the page to you, so shut your eyes and try to
comprehend what you are hearing.
Alternatively, try asking a colleague to read you the Web page out loud.
Without seeing the page, can you understand what you’re hearing?
Look At The Site Under Different Conditions
As suggested by the World Wide Web Consortium (W3C) Web Accessibility
Initiative [5], you should test your site under various conditions to see if there
are any problems including (a) graphics not loaded, (b) frames, scripts and
style sheets turned off and (c) browsing without using a mouse. Also, try using
bookmarklets or favelets to test your side under different conditions: further
information on accessibility bookmarklets can be found at [6].
Check With Automatic Validation Tools
There are a number of Web-based tools which can provide valuable
information on some potential accessibility problems. These include Bobby [7]
and The Wave tools [8].
You should also check whether the underlying HTML of your site validates to
accepted standards using the World Wide Web Consortium's MarkUp
Validation Service [9] as non-standard HTML frequently creates accessibility
barriers.
Acting on Your Observations
Details of any problems found should be noted: the effect of the problem,
which page was affected, plus why you think the problem was caused. You are
unlikely to catch all accessibility problems in the site, but the tests described
here will give you an indication of whether the site requires immediate
attention to raise accessibility. Remember that improving accessibility for
specific groups, such as visually impaired people, will often have usability
benefits for all users.
Commission an Accessibility Audit
Since it is unlikely you will catch all accessibility problems and the learning
curve is steep, it may be advisable to commission an expert accessibility audit.
In this way, you can receive a comprehensive audit of the subject site,
complete with detailed prioritised recommendations for upgrading the level of
accessibility of the site. Groups which provide such audits include the Digital
Media Access Group, University of Dundee and the RNIB (who also audit for
access by the blind).
Acknowledgments
This document was written by David Sloan, DMAG, University of Dundee
and originally published at by the JISC TechDis service We are grateful for
permission to republish this document.
References
1. Access Centres, <http://www.nfac.org.uk/>
2. Lynx, <http://lynx.isc.org/release/>
32
3 Briefing Documents On Web/Access
3. IBM's Homepage Reader, IBM, <http://www-3.ibm.com/
able/hprtrial3.html>
4. pwWebSpeak, < http://www.soundlinks.com/pwgen.htm>
5. Web Content Accessibility Guidelines, W3C.
<http://www.w3.org/TR/WAI-WEBCONTENT/>
6. Bookmarklets: An aid to checking the accessibility of your website, Nicola
McIlroy,
<http://www.dmag.org.uk/resources/design_articles/bookmarklets.asp>
7. Bobby, < http://bobby.watchfire.com/bobby/html/en/>
8. WAVE, <http://www.temple.edu/instituteondisabilities/piat/wave/>
9. W3C HTML Validator, W3C, <http://validator.w3.org/>
33
3 Briefing Documents On Web/Access
Use of Automated Tools For Testing Web Site
Accessibility
About This Document
This briefing document describes how automated tools can be used to test the accessibility of
Web sites.
Citation Details
Use of Automated Tools For Testing Web Site Accessibility, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-02/>
Keywords: Web, accessibility, testing, briefing
Accessibility And Web Sites
It is desirable to maximise the accessibility of Web sites in order to ensure that
We b resources can be accessed by people who may suffer from a range of
disabilities and who may need to use specialist browsers (such as speaking
browsers) or configure their browser to enhance the usability of Web sites
(e.g. change font sizes, colours, etc.).
Web sites which are designed to maximise accessibility should also be more
usable generally, (e.g. for use with PDAs) and are likely to be more easily
processed by automated tools.
Accessibility Testing Tools
Although the development of accessible Web sites will be helped by use of
appropriate templates and can be managed by Content Management Systems,
there will still be a need to test the accessibility of Web sites.
Full testing of accessibility with require manual testing, ideally making
use of users who have disabilities. The testing should also address the
usability of Web sites as well as its accessibility. Manual testing can
however be complemented with use of automated accessibility checking tools.
This document covers the use of automated accessibility checking tools.
Accessibility Standards
The W3C WAI (Web Accessibility Initiative) has developed guidelines on the
accessibility of Web resources. Many institutions are making use of the WAI
guidelines and will seek to achieve compliance with the guidelines to A, AA
or AAA standards. Many testing tools will measure the compliance of
resources with these guidelines.
Examples Of Automated Accessibility Checking Tools
The best-known accessibility checking tool is Bobby which provides a Webbased tool for reporting on the accessibility of a Web page and its compliance
with W3C’s WAI guidelines. As well as the Web site at
<http://bobby.watchfire.com/> a licensed desktop version of
Bobby is available which can be used to check entire Web sites.
34
3 Briefing Documents On Web/Access
A simple interface to Bobby can be obtained for resources on the UKOLN
Web site by appending ,bobby to a URL – see
<http://www.ukoln.ac.uk/qa-focus/documents/
briefings/briefing-59/> for details.
You should avoid use of a single checking tool. W3C WAI provides a list of
accessibility testing tools at <http://www.w3.org/WAI/ER/
existingtools.html#Evaluation>.
Typical Errors Flagged By Automated Tools
When you use testing tools warnings and errors will be provided about the
accessibility of your Web site. A summary of the most common messages is
given below.
No DOCTYPE
HTML resources must contain a DOCTYPE at the top of the HTML file,
which defines the version of HTML used. To provide compliance with
HTML standards this must be provided. Ideally this will be provided in
the HTML template used by authors.
No Character Encoding
HTML resources should describe the character encoding of the
document. This information should be provided. Ideally this will be
provided in the HTML template used by authors.
No ALT Tags
ALT tags are used to provide a textual description of images for the
visually impaired, users of text or speaking browsers, etc. In order to
comply with HTML standards ALT tags must be provided for all
images.
Use Relative Sizes And Positioning Rather Than Absolute
Many HTML features can accept relative or absolute size units. In order
to ensure that resources can be sized properly on non-standard devices
relative values should be used.
Link Phrase Used More Than Once
If more than one link on a page shares the same link text, all those links
should point to the same resource.
Caveats
As mentioned previously, automated testing tools cannot confirm that a
resource is accessible by itself – manual testing will be required to
complement an automated approach. However automated tools can be used to
provide an overall picture, to identify areas in which manual testing many be
required and to identify problems in templates or in the workflow process for
producing HTML resources and areas in which training and education may be
needed.
35
3 Briefing Documents On Web/Access
Note that automated tools may sometimes give inaccurate or misleading
results. In particular:
Use Of Frames
HTML resources which use frames may be incorrectly analysed by
automated tools. You should ensure that the frameset page itself and all
individual framed pages are accessible.
Use Of Redirects
HTML resources which use redirects may be incorrectly analysed by
automated tools. You should ensure that the original page itself and the
destination are accessible. Remember that redirects can be implemented
in a number of ways, including server configuration options and use of
JavaScript, <META> tags, etc. on the client.
Use Of JavaScript
HTML resources which use JavaScript may be incorrectly analysed by
automated tools. You should ensure that the source page itself and the
output from the JavaScript are accessible.
36
3 Briefing Documents On Web/Access
Accessibility Testing In Web Browsers
About This Document
This Briefing document describes how to carry out accessibility testing in popular Web
browsers.
Citation Details
Accessibility Testing In Web Browsers, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-57/>
Keywords: Web, accessibility, Web browser, testing, briefing
About This Document
This document provides advice on configuring popular Web browsers in order
to ensure your Web site is widely accessible. The document covers Internet
Explorer 6.0, Mozilla 1.4 and Opera 7.2 running on Microsoft Windows.
Disabling JavaScript
Some browsers do not support JavaScript. Some organisations / individuals
will disable JavaScript due to security concerns.
Browser
Technique
Internet
Explorer
Select Tools menu and Internet Options option.
Select the Security tab, choose the Internet icon
choose the Custom level option. Scroll to the
Scripting option and choose the Disable (or Prompt)
option.
Mozilla
Select Edit menu and Preferences option. Open the
Privacy and Security option, choose Images
option, select the Do not load any images option
and select OK.
Select File menu and choose the Preferences option.
Choose the Multimedia option, disable JavaScript option
and select OK.
Opera
Resizing Text
Some individuals will need to resize the display in order to read the
information provided.
Internet
Explorer
Select View menu and Text Size option.
Mozilla
Select Edit menu and Preferences option. Open
Appearance option, select the Fonts option, choose a
small font size. Repeat with a large font size.
Select the View menu and choose Zoom option. Then zoom
by a factor or, say, 50% and 150%.
Opera
37
3 Briefing Documents On Web/Access
Disabling Images
Some people cannot see images. Some browsers do not support images, such
as Lynx. Some individuals will disable images in order to improve network
performance.
Browser
Technique
Internet
Explorer
Select Tools menu and Internet Options option.
Select the Advanced tab, scroll to Multimedia and disable
the Show images option.
Mozilla
Select Edit menu and Preferences option. Open
Privacy & Security option, select Images option,
choose the Do not load any images option and select
OK.
Select File menu and choose Preferences option.
Choose Multimedia option, select the Show images
pull-down menu and choose the Show no images option
and select OK.
Opera
Disabling Popup Windows
Some browsers do not support pop-up windows, such as browsers on PDAs.
Individuals may disable pop-up windows due to their misuse by some
commercial sites.
Internet
Explorer
Select the Advanced tab, scroll to Multimedia and disable
the Show images option.
Mozilla
Select Edit menu and Preferences option. Open
Privacy and Security option, select Popup
windows option, select the Block unrequested
popup windows option.
Select File menu and choose the Preferences option.
Choose Windows option, in the Pop-ups pull-down menu
and choose the Refuse Pop-ups option and select OK
Opera
Systematic Testing
You should use the procedures in a systematic way: for example as part of a
formal testing procedure in which specific tasks are carried out.
Use of Bookmarklets And FireFox Extensions
Bookmarklets are browser extension may extend the functionality of a
browser. Many accessibility bookmarklets are available (known as Firefox
Extensions for the Firefox browser). It is recommended that such tools are
used in accessibility testing. See Interfaces To Web Testing Tools at
<http://www.ariadne.ac.uk/issue34/web-focus/>.
38
3 Briefing Documents On Web/Access
Performance Indicators For Your Project Web Site
About This Document
This briefing document describes a number of performance indicators for your Web site.
Citation Details
Performance Indicators For Your Project Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-17/>
Keywords: Web, usage figures, statistics, performance indicators, briefing
Background
It is desirable to measure usage of your project Web site as this can give an
indication of its effectiveness. Measuring how the Web site is being used can
also help in identifying the usability of the Web site. Monitoring errors when
users access your Web site can also help in identifying problem areas which
need to be fixed.
However, as described in this document, usage statistics can be misleading.
Care must be taken in interpreting statistics. As well as usage statistics there
are a number of other types of performance indicators which can be measured.
It is also important that consistent approaches are taken in measuring
performance indicators in order to ensure that valid comparisons can be made
with other Web sites.
Web Statistics
Web statistics are produced by the Web server software. The raw data will
normally be produced by default - no additional configuration will be needed
to produce the server's default set of usage data.
The server log file records information on requests (normally referred to as a
"hit") for a resource on the web server. Information included in the server log
file includes the name of the resource, the IP address (or domain name) of the
user making the request, the name of the browser (more correctly, referred to
as the "user agent") issuing the request, the size of the resource, date and time
information and whether the request was successful or not (and an error code
if it was not). In addition many servers will be configured to store additional
information, such as the "referer" (sic) field, the URL of the page the user was
viewing before clicking on a link to get to the resource.
Tools
A wide range of Web statistical analysis packages are available to analyse
Web server log files [1]. A widely used package in the UK HE sector is
WebTrends [2].
An alternative approach to using Web statistical analysis packages is to make
use of externally-hosted statistical analysis services [3]. This approach may be
worth considering for projects which have limited access to server log files
and to Web statistical analysis software.
39
3 Briefing Documents On Web/Access
Configuration Issues
In order to ensure that Web usage figures are consistent it is necessary to
ensure that Web servers are configured in a consistent manner, that Web
statistical analysis packages process the data consistently and that the project
Web site is clearly defined.
You should ensure that (a) the Web server is configured so that appropriate
information is recorded and (b) that changes to relevant server options or data
processing are documented.
Limitations
You should be aware that the Web usage data does not necessarily give a true
indication of usage due to several factors:


Effects of caching.
Effects of access from robots, off-line browsers, auditing tools, etc.

Difficulties of measuring unique visitors, browser types, etc.
accurately.

Difficulties of defining terms such as sessions.
Despite these reservations collecting and analysing usage data can
provide valuable information.
Other Types Of Indicators
Web usage statistics are not the only type of performance indicator which can
be used. You may also wish to consider:

Monitoring the number of links to your Web site: tools such as
LinkPopularity.com can give the number of links to your Web site.

Numbers of resources indexed: You can analyse the numbers of
resources indexed by search engines such as Google.

Error log analysis: Analysis of your server log error file can indicate
problem areas.
With all of the indicators periodic reporting will allow trends to be detected.
Conclusions
It may be useful to determine a policy on collection and analysis of
performance indicators for your Web site prior to its launch.
References
1. Web Server Log Files, UKOLN,
<http://www.ukoln.ac.uk/nof/support/help/papers/performance/>
2. WebTrends, <http://www.netiq.com/webtrends/>
3. Externally-Hosted Statistical Analysis Services, Exploit Interactive, issue
5, <http://www.exploit-lib.org/issue5/indicators/>
40
3 Briefing Documents On Web/Access
Use Of Cascading Style Sheets (CSS)
About This Document
This briefing document describes the importance of CSS for Web sites.
Citation Details
Use Of Cascading Style Sheets (CSS), QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-34/>
Keywords: Web, CSS, style sheets, briefing
Background
This document reviews the importance of Cascading Style Sheets (CSS) and
highlights the importance of ensuring that use of CSS complies with CSS
standards.
Why Use CSS?
Use of CSS is the recommended way of defining how HTML pages are
displayed. You should use HTML to define the basic structure (using elements
such as <h1>, <p>, <li>, etc.) and CSS to define how these elements should
appear (e.g. heading should be in bold Arial font, paragraphs should be
indented, etc.).
This approach has several advantages:
Maintenance: It is much easier to maintain the appearance of a Web site. If
you use a single CSS file updating this file allows the Web site look-and-feel
to be altered easily; in contrast use of HTML formatting elements would
require every file to be updated to change the appearance.
Functionality: CSS provides rich functionality, including defining the
appearance of HTML pages when they are printed.
Accessibility: Use of CSS provides much greater accessibility, allowing users
with special needs to alter the appearance of a Web page to suit their
requirements. CSS also allows Web pages to be more easily rendered by
special devices, such as speaking browsers, PDAs, etc.
There are disadvantages to use of CSS. In particular legacy browsers such as
Netscape 4 have difficulty in processing CSS. However, since such legacy
browsers are now in a minority the biggest barrier to deployment of CSS is
probably inertia.
Approaches To Use Of CSS
There are a number of ways in which CSS can be deployed:
External CSS Files: The best way to use CSS is to store the CSS data in an
external file and link to this file using the <link> HTML element. This
approach allows the CSS definitions to be used by every page on your Web
site.
41
3 Briefing Documents On Web/Access
Internal CSS: You can store CSS within a HTML by including it using the
<style> element within the <head> section at the top of your HTML file.
However this approach means the style definitions cannot be applied to other
files. This approach is not normally recommended.
Inline CSS: You can embed your CSS inline with HTML elements: for
example <p style=”font-color: red”> uses CSS to specify that text
in the current paragraph is red. However this approach means that the style
definitions cannot be applied to other paragraphs. This approach is
discouraged.
Ensure That You Validate Your CSS
As with HTML, it is important that you validate your CSS to ensure that it
complies with appropriate CSS standards. There are a number of approaches
you can take:
Within your HTML editor: Your HTML editing tool may allow you to
create CSS. If it does, it may also have a CSS validator.
Within a dedicated CSS editor: If you use a dedicated CSS editor, the tool
may have a validator.
Using an external CSS validator: You may wish to use an external CSS
validators, This could be a tool installed locally or a Web-based tool such as
those available at W3C [1] and the Web Design Group [2].
Note that if you use external CSS files, you should also ensure that you check
that the link to the file works.
Systematic CSS Validation
You should ensure that you have systematic procedures for validating your
CSS. If, for example, you make use of internal or inline CSS you will need to
validate the CSS whenever you create or edit an HTML file. If, however, you
use a small number of external CSS files and never embed CSS in individual
HTML files you need only validate your CSS when you create or update one
of the external CSS files.
References
1 Validator CSS, W3C, <http://jigsaw.w3.org/css-validator/>
2 CSSCheck, WDG, <http://www.htmlhelp.com/tools/csscheck/>
42
3 Briefing Documents On Web/Access
Top 10 Tips For Preserving Web Sites
About This Document
This QA Focus briefing document provides top 10 tips on preserving your Web site.
Citation Details
Top 10 Tips For Preserving Web Sites, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-45/>
Keywords: Web, mothballing, preservation, archiving, briefing
About This Document
This document provides top tips which can help to ensure that project Web
sites can be preserved.
The Top 10 Tips
1
Make Use Of Open Standards
You should seek to make use of open standard formats for your Web site. This will help
you to avoid lock-in to proprietary formats for which access may not be available in the
future.
2
Define The Purpose(s) Of Your Web Site
You should have a clear idea of the purpose(s) of your project Web site, and you should
document the purposes. Your Web site could, for example, provide access to project
deliverables for end users; could provide information about the project; could be for use
by project partners; etc. A policy for preservation will be dependent of the role of the
Web site.
3
Have A URI Naming Policy
Before launching your Web site you should develop a URI naming policy. Ideally you
should contain the project Web site within its own directory, which will allow the
project Web site to be processed (e.g. harvested) separately from other resources on the
Web site.
4
Think Carefully Before Having Split Web Sites
The preservation of a Web site which is split across several locations may be difficult to
implement.
5
Think About Separating Web Site Functionality
On the other hand it may be desirable to separate the functionality of the Web site, to
allow, for example, information resources to be processed independently of other
aspects of the Web site. For example, the search functionality of the Web site could
have its own sub-domain (e.g. search.foo.ac.uk) which could allow the information
resources (under www.foo.ac.uk) to be processed separately.
6
Explore Potential For Exporting Resources From A CMS
You should explore the possibility of exporting resources from a backend database or
Content Management Systems in a form suitable for preservation.
7
Be Aware Of Legal, IPR, etc. Barriers To Preservation
You need to be aware of various legal barriers to preservation. For example, do you
own the copyright of resources to be preserved; are there IPR issues to consider; are
43
3 Briefing Documents On Web/Access
confidential documents (such as project budgets, minutes of meetings, mailing list
archives, etc.). to be preserved; etc.
8
Test Mirroring Of Your Web Site
You should test the mirroring of your project Web site to see if there are technical
difficulties which could make preservation difficult. See, for example, the QA Focus
document on Accessing Your Web Site On A PDA [1].
9
Provide Documentation
You should provide technical documentation on your Web site which will allow others
to preserve your Web site and to understand any potential problem areas. You should
also provide documentation on your policy of preservation.
10
Learn From Others
Learn from the experiences of others. For example read the case study on Providing
Access to an EU-funded Project Web Site after Completion of Funding [2] and the
briefing document on Mothballing Web Sites [3].
References
1 Accessing Your Web Site On A PDA, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-05/>
2 Providing Access to an EU-funded Project Web Site after Completion of Funding, QA
Focus, UKOLN, <http://www.ukoln.ac.uk/qa-focus/documents/case-studies/casestudy-17/>
3 Mothballing Web Sites, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-04/>
44
3 Briefing Documents On Web/Access
Mothballing Your Web Site
About This Document
This briefing document describes approaches to ‘mothballing’ a Web site once project
funding finishes.
Citation Details
Mothballing Your Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-04/>
Keywords: Web, mothballing, preservation, archiving, briefing
About This Document
When the funding for a project finishes it is normally expected that the
project’s Web site will continue to be available in order to ensure that
information about the project, the project’s findings, reports, deliverables, etc.
are still available.
This document provides advice on “mothballing” a project Web site.
Web Site Content
The entry point for the project Web site should make it clear that the project
has finished and that there is no guarantee that the Web site will be
maintained.
You should seek to ensure that dates on the Web site include the year – avoid
content which says, for example, “The next project meeting will be held on 22
May”.
You may also find it useful to make use of cascading style sheets (CSS) which
could be used to, say, provide a watermark on all resources which indicate that
the Web site is no longer being maintained.
Technologies
Although software is not subject to deterioration due to aging, overuse, etc.
software products can cease to work over time. Operating systems upgrades,
upgrades to software libraries, conflicts with newly installed software, etc. can
all result in software products used on a project Web site to cease working.
There are a number of areas to be aware of:

If you are using unusual configuration features for the Web server
software, the Web site may stop working if the server software is
upgraded or replaced (you move from Microsoft’s IIS software to
Apache).

If you are using special features of the Web site’s search engine
software aspects of the Web site may cease to work if the search
engine software is upgraded or replaced.

If you are using online forms on your Web site these may cease to
work if the backend scripts are updated.
45
3 Briefing Documents On Web/Access

If you are using a Content Management System or server-side
scripting technologies (e.g. PHP, ASP, etc.) on your Web site these
may cease to work if the backend technologies are updated.

If you provide automated feedback or annotation tools which allow
users to provide comments on resources on your Web site there is a
danger that the tools may be used to submit spam or obscene messages.
With popular feedback tools there may be automated devices which
will submit inappropriate messages automatically.
Process For Mothballing
We have outlined a number of areas in which a project Web site may degrade
in quality once the project Web site has been “mothballed”.
In order to minimise the likelihood of this happening and to ensure that
problems can be addressed with the minimum of effort it can be useful to
adopt a systematic set of procedures when mothballing a Web site.
It can be helpful to run a link checker across your Web site. You should
seek to ensure that all internal links (links to resources on your own Web site)
work correctly. Ideally links to external resources will also work, but it is
recognised that this may be difficult to achieve. It may be useful to provide a
link to a report of the link check on your Web site.
It would be helpful to provide documentation on the technical architecture of
your Web site, which describes the server software used (including use of any
unusual features), use of server-side scripting technologies, content
management systems, etc.
It may also be useful to provide a mirror of your Web site by using a
mirroring package or off-line browser. This will ensure that there is a static
version of your Web site available which is not dependent on server-side
technologies.
Contacts
You should give some thought to contact details provided on the Web site.
You will probably wish to include details of the project staff, partners, etc.
However you may wish to give an indication if staff have left the organisation.
Ideally you will provide contact details which are not tied down to a particular
person. This may be needed if, for example, your project Web site has been
hacked and the CERT security team need to make contact.
Planning For Mothballing
Ideally you will ensure that your plans for mothballing your Web site are
developed when you are preparing to launch your Web site!
46
3 Briefing Documents On Web/Access
Deployment Of XHTML 1.0
About This Document
This QA Focus briefing document provides advice on the deployment Of XHTML 1.0.
Citation Details
Deployment Of XHTML 1.0, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-35/>
Keywords: Web, URL, URLs, domain, Web site address, briefing
Background
This document describes the current recommended versions of HTML. The
advantages of XHTML 1.0 are given together with potential challenges in
deploying XHTML 1.0 so that it follows best practices.
Versions Of HTML
HTML has evolved since it was first created, responding to the need to
provide richer functionality, maximise its accessibility and allow it to integrate
with other architectural developments. The final version of the HTML
language is HTML 4.0. This version is mature and widely supported, with a
wide range of authoring tools available and support provided in Web
browsers.
However HTML has limitations: HTML resources cannot easily be reused; it
is difficult to add new features to the HTML language; it is difficult to
integrate HTML pages with other markup languages (e.g. MathML for
including mathematical expressions, SVG for including scalable vector
graphics, etc).
XHTML 1.0
XHTML was developed address these concerns. XHTML is the HTML
language described in the XML language. This means that the many
advantages of XML (ability to reuse resources using the XSLT language;
ability to integrate other XML application, etc.) are available for authors
creating conventional Web pages.
In order to support migration from HTML to a richer XHTML world,
XHTML has been designed so that it is backwards compatible with the current
Web browsers.
Since XHTML 1.0 provides many advantages and can be accessed by current
browsers it would seem that use of XHTML 1.0 is recommended. However
there are a number of issues which need to be addressed before deploying
XHTML 1.0 for your Web site.
47
3 Briefing Documents On Web/Access
Deployment Issues
Compliance
Although HTML pages should comply with the HTML standard, browsers are
expected to be tolerant of errors. Unfortunately this has led to an environment
in which many HTML resources are non-compliant. This environment makes
it difficult to repurpose HTML by other applications. It also makes rendering
of HTML resources more time-consuming than it should, since browsers have
to identify errors and seek to render them in a sensible way.
The XML language, by contrast, mandates that XML resources comply with
the standard. This has several advantages: XML resources will be clean
enabling the resources to be more easily reused by other applications;
applications will be able to process the resources more rapidly; etc. Since
XHTML is an XML application an XHTML resource must be compliant in
order for it to be processed as XML.
XHTML 1.0 And MIME Types
Web browsers identify file formats by checking the resource’s MIME type.
HTML resources use a text/html MIME type. XHTML resources may use
this MIME type; however the resources will not be processed as XML,
therefore losing the benefits provided by XML. Use of the
application/xhtml+xml MIME type (amongst others) allows resources
to be processed as XML. This MIME type is therefore recommended if you
wish to exploit XML’s potential.
Implementation Issues
You should be aware of implementation issues before deploying XHTML 1.0:
Guaranteeing Compliance: You must ensure that your resources are
compliant. Unlike HTML, non-compliant resources should not be processed
by XML tools. This may be difficult to achieve if you do not have
appropriate tools and processed.
Browser Rendering: Although use of an application/xml MIME
type is recommended to maximise the potential of a more structured XML
world, this environment is not tolerant of errors. Use of the text/html
MIME type will allow non-compliant XHTML resources to be viewed, but
exploiting this feature simply perpetuates the problems of a HTML-based
Web.
Resource Management: It is very import that you give thought to the
management of a Web site which uses XHTML. You will need to ensure
that you have publishing processed which avoids resources becoming noncompliant. You will also need to think about the approaches of allocating
MIME types.
Conclusions
Use of XHTML 1.0 and the application/xhtml+xml MIME type
provides a richer, more reusable Web environment. However there are
challenges to consider in deploying this approach. Before deploying XHTML
you must ensure that you have addressed the implementation difficulties.
48
3 Briefing Documents On Web/Access
An Introduction To RSS And News Feeds
About This Document
This document provides a brief description of RSS news feed technologies which can be used
as part of an communications strategy by projects and within institutions. The document
summarises the main challenges to be faced when considering deployment of news feeds.
Citation Details
An Introduction To RSS And News Feeds, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-77/>
Keywords: Web, RSS, news, news feeds, briefing
Background
RSS is increasingly being used to provide news services and for syndication of
content. The document provides a brief description of RSS news feed
technologies which can be used as part of an communications strategy by
projects and within institutions. The document summarises the main
challenges to be faced when considering deployment of news feeds.
What Are News Feeds?
News feeds are an example of automated syndication. News feed technologies
allow information to be automatically provided and updated on Web sites,
emailed to users, etc. As the name implies news feeds are normally used to
provide news; however the technology can be used to syndicate a wide range
of information.
Standards For News Feeds
The BBC ticker [1] is an example of a news feed application. A major
limitation with this approach is that the ticker can only be used with
information provided by the BBC.
The RSS standard was developed
as an open standard for news
syndication, allowing applications
to display news supplied by any
RSS provider.
<title>BBC News</title>
<url>http://news.bbc.co.uk/
nol/shared/img/bbc_news_120x60
.gif</url>
<link>http://news.bbc.co.uk/
</link>
RSS is a lightweight XML
application (see RSS fragment).
Ironically the RSS standard proved
so popular that it led to two
different approaches to its
standardisation. So RSS now
stands for RDF Site Summary and
Really Simple Syndication (in
addition to the original phrase Rich
Site Summary).
<item>
<title>Legal challenge to ban
on hunting</title>
<description>The Countryside
Alliance prepares a legal
challenge to Parliament Act
... </description>
<link>http://news.bbc.co.uk/
go/click/rss/0.91/public//1/hi/... </link>.
Despite this confusion, in practice many RSS viewers will display both
versions of RSS (and the emerging new standard, Atom).
49
3 Briefing Documents On Web/Access
News Feeds Readers
There are a large number of RSS reader software
applications available [2] and several different
models. RSSxpress [3] (illustrated right) is an
example of a Web-based reader which embeds an
RSS feed in a Web page. An example of a scrolling
RSS ticker is shown above [4].
In addition to these two approaches, RSS readers
are available with an email-style approach for the
Opera Web browser [5] and Outlook [6] and as
extensions for Web browsers [7] [8].
Creating News Feeds
There are several approaches to the creation of RSS news feeds. Software such
as RSSxpress can also be used to create and edit RSS files. In addition there
are a number of dedicated RSS authoring tools, including standalone
applications and browser extensions (see [9]). However a better approach may
be to generate RSS and HTML files using a CMS or to transform between
RSS and HTML using languages such as XSLT.
Issues
Issues which need to be addressed when considering use of RSS include:
 The architecture for reading and creating RSS feeds
 The procedures needed in order to guarantee the quality of the news
feed content
 How news feeds fits in with your organisation’s communications
strategy
Further Information
1
2
3
4
5
6
7
8
9
Desktop Ticker, BBC, <http://news.bbc.co.uk/1/hi/help/3223354.stm>
RSS Readers, Weblogs Compendium,
<http://www.lights.com/weblogs/rss.html>
RSSxpress, UKOLN, <http://rssxpress.ukoln.ac.uk/>
ENewsBar, <http://www.enewsbar.com/>
RSS Newsfeeds In Opera Mail,
<http://www.opera.com/products/desktop/m2/rss/>
Read RSS In Outlook, intraVnews, <http://www.intravnews.com/>
RSS Extension for Firefox, Sage, <http://sage.mozdev.org/>
RSS Reader, Pluck, <http://www.pluck.com/product/rssreader.aspx>
Web / Authoring / Languages / XML / RSS, Webreference.com,
<http://www.webreference.com/authoring/languages/xml/rss/>
50
3 Briefing Documents On Web/Access
An Introduction To Wikis
About This Document
This briefing document aims to give a brief description of Wikis and to summarise the main
challenges to be faced when considering the deployment of Wiki technologies."
Citation Details
An Introduction To Wikis, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-78/>
Keywords: Web, Wiki, briefing
Background
Wiki technologies are increasingly being used to support development work
across distributed teams. This document aims to give a brief description of
Wikis and to summarise the main challenges to be faced when considering the
deployment of Wiki technologies.
What Is A Wiki?
A Wiki or wiki (pronounced "wicky" or "weekee") is a Web site (or other
hypertext document collection) that allows a user to add content. The term
Wiki can also refer to the collaborative software used to create such a Web site
[1].
The key characteristics of typical Wikis are:
 The ability to create and edit content within a Web environment
without the need to download any special software.
 The use of a simple markup language which is designed to simplify
the process of creating and editing documents.
 The ability to easily create and edit content, often without the need for
special privileges.
Wikipedia – The Largest Wiki
The Wikipedia is the largest and bestknown Wiki – see
<http://www.wikipedia.org/>.
The Wikipedia provides a good
example of a community Wiki in
which content is provided by
contributors around the world.
The Wikipedia appears to have
succeeded in providing an environment
and culture which has minimised the
dangers of misuse. Details of the
approaches taken on the Wikipedia are
given on the Wikimedia Web site [2].
51
Figure 1: The Wikipedia
3 Briefing Documents On Web/Access
What Can Wikis Be Used For?
Wikis can be used for a number of purposes:
 On public Web sites to enable end users to easily contribute
information.
 In teaching. Wikis can provide an opportunity to learn about team
working, trust, etc. A good example is provided by Queen’s
University Belfast [3].
 By researchers. Wikis are by Web researchers to make it easier to
develop collaborative documents e.g. the FOAF Wiki [4].
 On Intranets, where departmental administrators with minimal HTML
experience may be able to manage departmental content.
 Wikis can be used at events for note-taking in discussion groups [5].
A useful article on Making the Case for a Wiki is available in Ariadne [6].
Wikis – The Pros And Cons
Advantages of Wikis include:
 No need to install HTML authoring tools.
 Minimal training may be needed.
 Can help develop a culture of sharing and working together (cf. open
source).
 Useful for joint working when there are agreed shared goals.
Disadvantages of Wikis include:
 The success of the Wikipedia may not necessarily be replicated
elsewhere.
 There is not (yet) a standard lightweight Wiki markup language.
 A collaborative Wiki may suffer from a lack of a strong vision or
leadership.
 There may be copyright and other legal issues regarding collaborative
content.
 Can be ineffective when there is a lack of consensus.
Further Information
1 Wiki, Wikipedia, <http://en.wikipedia.org/wiki/Wiki>
2 Wikimedia principles, Wikimedia,
<http://meta.wikimedia.org/wiki/Wikimedia_principles>
3 IT and Society Wiki, Queen’s University Belfast,
<http://itsoc.mgt.qub.ac.uk/ITandSociety>
4 FOAF Wiki, FoafProject, <http://rdfweb.org/topic/FoafProject>
5 Experiences of Using a Wiki for Note-taking at a Workshop, B. Kelly,
Ariadne 42, Jan 2005, <http://www.ariadne.ac.uk/issue42/web-focus/>
6 Making the Case for a Wiki, E. Tonkin, Ariadne 42, Jan 2005,
<http://www.ariadne.ac.uk/issue42/tonkin/>
52
3 Briefing Documents On Web/Access
Usage Statistics For Web Sites
About This Document
This QA Focus briefing document gives an introduction to Web site usage statistics and
provides advice on using such data.
Citation Details
Usage Statistics For Web Sites, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-84>
Keywords: Web, usage statistics, URI, briefing
About This Document
Information on performance indicators for Web sites has been published
elsewhere [1] [2]. This document provides additional information on the
specific need for usage statistics for Web sites and provides guidance on ways
of ensuring the usage statistics can be comparable across Web sites.
About Usage Statistics For Web Sites
When a user accesses a Web page several resources will normally be
downloaded to the user (the HTML file, any embedded images, external style
sheet and JavaScript files, etc.). The Web server will keep a record of this,
including the names of the files requested and the date and time, together with
some information about the user’s environment (e.g. type of browser being
used).
Web usage analysis software can then be used to provide overall statistics on
usage of the Web site. As well as giving an indication of the overall usage of a
Web site, information can be provided on the most popular pages, the most
popular entry points, etc.
What Can Usage Statistics Be Used For?
Usage statistics can be used to give an indication of the popularity of Web
resources. Usage statistics can be useful if identifying successes or failures in
dissemination strategies or in the usability of a Web site.
Usage statistics can also be useful to system administrators who may be able
to use the information (and associated trends) in capacity planning for server
hardware and network bandwidth.
Aggregation of usage statistics across a community can also be useful in
profiling the impact of Web services within the community.
Limitations Of Usage Statistics
Although Web site usage statistics can be useful in a number of areas, it is
important to be aware of the limitations of usage statistics. Although initially it
may seem that such statistics should be objective and unambiguous, in reality
this is not the case.
Some of the limitations of usage statistics include:
53
3 Briefing Documents On Web/Access
 The numbers may be under-reported due to caches – which improve
the performance of Web sites by keeping a copy of Web resources.
 The numbers may be over-reported due to use of off-line browsers
which can download Web resources which are not viewed.
 The numbers may be over-reported due to reported on accessed by
indexing software (e.g. the Google robot software).
 Aggregation of usage statistics may be flawed due to organisations
processing the data in-consistently (e.g. some removing data from
robots when others do not).
 Errors may be introduced when merging statistical data from a variety
of sources.
Recommendations
Although Web site usage statistics cannot be guaranteed to provide a clear and
unambiguous summary of Web site usage, this does not mean that the data
should not be collected and used. There are parallels with TV viewing figures
which are affected by factors such as video recording. Despite such known
limitations, this data is collected and used in determining advertising rates.
The following advice may be useful
Document Your Approaches And Be Consistent
You should ensure that you document the approaches taken (e.g. details of the
analysis tool used) and any processing carried out on the data (e.g. removing
robot traffic or access from within the organisation). Ideally you will make
any changes to the processing, but if you do you should document this.
Consider Use Of Externally Hosted Usage Services
Traditional analysis packages process server log files. An alternative approach
is to make use of an externally-hosted usage analysis service. These services
function by providing a small graphical image (which may be invisible) which
is embedded on pages on your Web site. Accessing a page causes the graphic
and associated JavaScript code, which is hosted by a commercial company, to
be retrieved. Since the graphic is configured to be non-cachable, the usage
data should be more reliable. In addition the JavaScript code can allow
additional data to be provided, such as additional information about the end
users PC environment.
References
1
Performance Indicators For Your Project Web Site, QA Focus briefing
document No. 17, <http://www.ukoln.ac.uk/qafocus/documents/briefings/briefing-17/>
2
Performance Indicators For Web Sites, Exploit Interactive (5), 2000,
<http://www.exploit-lib.org/issue5/indicators/>
54
3 Briefing Documents On Web/Access
An Introduction To Web Services
About This Document
This QA Focus briefing document gives an introduction to Web Services..
Citation Details
An Introduction To Web Services, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-85>
Keywords: Web, Web Services, briefing
What Are Web Services?
Web services are a class of Web application, published, located and accessed
via the Web, that communicates via an XML (eXtensible Markup Language)
interface [1]. As they are accessed using Internet protocols, they are available
for use in a distributed environment, by applications on other computers.
What’s The Innovation?
The idea of Internet-accessible programmatic interfaces, services intended to
be used by other software rather than as an end product, is not new. Web
services are a development of this idea. The name refers to a set of standards
and essential specifications that simplify the creation and use of such service
interfaces, thus addressing interoperability issues and promoting ease of use.
Well-specified services are simple to integrate into larger applications, and
once published, can be used and reused very effectively and quickly in many
different scenarios. They may even be aggregated, grouped together to
produce sophisticated functionality.
Example: Google Spellchecker And Search Services
The Google spellchecker service, used by the Google search engine, suggests
a replacement for misspelt words. This is a useful standard task; simply hand it
a word, and it will respond with a suggested spelling correction if one is
available. One might easily imagine using the service in one's own search
engine, or in any other scenario in which user input is taken, perhaps in an
intelligent “Page not found” error page, that attempts to guess at the correct
link. The spellchecker's availability as a web service simplifies testing and
adoption of these ideas.
Furthermore, the use of Web services is not limited to Web-based
applications. They may also usefully be integrated into a broad spectrum of
other applications, such as desktop software or applets. Effectively transparent
to the user, Web service integration permits additional functionality or
information to be accessed over the Web. As the user base continues to grow,
many development suites focus specifically on enabling the reuse and
aggregation of Web services.
What Are The Standards Underlying Web Services?
'Web services' refers to a potentially huge collection of available standards, so
only a brief overview is possible here. The exchange of XML data uses a
55
3 Briefing Documents On Web/Access
protocol such as SOAP or XML-RPC. Once published, the functionality of the
Web service may be documented using one of a number of emerging
standards, such as WSDL, the Web Service Description Language.
WSDL provides a format for description of a Web service interface, including
parameters, data types and options, in sufficient detail for a programmer to
write a client application for that service. That description may be added to a
searchable registry of Web services.
A proposed standard for this purpose is UDDI (Universal Description,
Discovery and Integration), described as a large central registry for businesses
and services. Web services are often seen as having the potential to 'flatten the
playing field', and simplify business-to-business operations between
geographically diverse entities.
Using Web Services
Due to the popularity of the architecture, many resources exist to support the
development and use of Web services in a variety of languages and
environments. The plethora of available standards may pose a problem, in that
a variety of protocols and competing standards are available and in
simultaneous use. Making that choice depends very much on platform,
requirements and technical details.
Although Web services promise many advantages, there are still ongoing
discussions regarding the best approaches to the underlying technologies and
their scope.
References
1. The JISC Information Environment and Web Services, A. Powell and E. Lyon,
Ariadne, issue 31, April 2002, <http://www.ariadne.ac.uk/issue31/informationenvironments/>
2. World Wide Web Consortium Technical Reports, W3C,
<http://www.w3.org/TR/>
Further Information

Web Services Description Working Group, W3C,
<http://www.w3.org/2002/ws/desc/>

Top Ten FAQs for Web Services, XML.COM,
<http://webservices.xml.com/pub/a/ws/2002/02/12/webservicefaqs.html>

Web Services, Wikipedia, <http://en.wikipedia.org/wiki/Web_services>
56
3 Briefing Documents On Web/Access
An Introduction To Web 2.0
About This Document
This QA Focus briefing document gives an introduction to Web 2.0.
Citation Details
An Introduction To Web 2.0, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-92/>
Keywords: Web, Web 2.0, briefing
Web 2.0
The term "Web 2.0" refers to what some see as a second phase of development
of the Web including its architecture and its applications. As used by its
proponents, the phrase refers to one or more of the following:

the transition of Web sites from isolated information silos to sources of
content and functionality, thus becoming a computing platform serving
web applications to end users.
 a social phenomenon referring to an approach to creating and
distributing Web content itself, characterised by open communication,
decentralisation of authority, freedom to share and re-use, and "the
market as a conversation".
 a more organised and categorised content, with a far more developed
deep-linking Web architecture.
 a shift in economic value of the Web, possibly surpassing that of the dot
com boom of the late 1990s
 a marketing term to differentiate new Web businesses from those of the
dot com boom, which due to the bust now seem discredited.
However, a consensus on its exact meaning has not yet been reached. Many
find it easiest to define Web 2.0 by associating it with companies or products
that embody its principles. Some of the more well known Web 2.0 entities are
Google Maps, Flickr, del.icio.us, digg, and Technorati.
Many recently developed concepts and technologies are seen as contributing
to Web 2.0, including Weblogs, Wikis, Podcasts, RSS feeds and other forms
of many to many publishing; social software, Web APIs, Web standards, Ajax
and others.
Proponents of the Web 2.0 concept say that it differs from early Web
development, retroactively labelled Web 1.0, in that it is a move away from
static Web sites, the use of search engines, and surfing from one Web site to
the next, to a more dynamic and interactive Web. Others argue that the
original and fundamental concepts of the Web are not actually being
superseded. Sceptics argue that the term is little more than a buzzword, or that
it means whatever its proponents want it to mean in order to convince their
customers, investors and the media that they are creating something
fundamentally new, rather than continuing to develop and use well-established
technologies.
57
3 Briefing Documents On Web/Access
Overview
Web 1.0 often consisted of static HTML pages that were updated rarely, if at
all.. The success of the dot-com era depended on a more dynamic Web
(sometimes labelled Web 1.5) where content management systems served
dynamic HTML pages created on the fly from a content database that could
more easily be changed. In both senses, so-called eyeballing was considered
intrinsic to the Web experience, thus making page hits and visual aesthetics
important factors.
Proponents of Web 2.0 believe that Web usage is increasingly oriented toward
interaction and rudimentary social networks, which can serve content that
exploits network effects with or without creating a visual, interactive Web
page. In one view, Web 2.0 sites act more as points of presence, or userdependent portals, than as traditional Web sites.
Perhaps Web content will become less under the control of specialised Web
designers and closer to Tim Berners-Lee's original concept of the Web as a
democratic, personal, and DIY medium of communication. Content is less
likely to flow through email and more likely to be posted on a attractive Web
page and distributed by RSS.
With its allusion to the version numbers that commonly designate software
upgrades, Web 2.0 was a natural way to indicate an improved form of the
World Wide Web, and the term has been in occasional use for a number of
years. It was eventually popularised by O'Reilly Media and MediaLive
International for a conference they hosted after Dale Dougherty mentioned it
during a brainstorming session. Dougherty suggested that the Web was in a
renaissance, with changing rules and evolving business models. The
participants assembled examples — "DoubleClick was Web 1.0; Google
AdSense is Web 2.0. Ofoto is Web 1.0; Flickr is Web 2.0." - rather than
definitions.
Origin of The Term
In their first conference opening talk, O'Reilly and Battelle summarised key
principles they believe characterise Web 2.0 applications: the Web as
platform; data as the driving force; network effects created by an "architecture
of participation"; innovation in assembly of systems and sites composed by
pulling together features from distributed, independent developers (a kind of
"open source" development); lightweight business models enabled by content
and service syndication; the end of the software adoption cycle ("the perpetual
beta"); software above the level of a single device, leveraging the power of
"the Long Tail".
An earlier usage of the phrase Web 2.0 was as a synonym for "Semantic
Web", and indeed, the two concepts complement each other. The combination
of social networking systems such as FOAF and XFN with the development of
tag-based folksonomies and delivered through Blogs and Wikis creates a
natural basis for a semantic environment. Although the technologies and
services that comprise Web 2.0 are less powerful than an internet in which the
machines can understand and extract meaning, as proponents of the Semantic
Web envision, Web 2.0 represents a step in its direction.
58
3 Briefing Documents On Web/Access
Advanced Technology
Advancing from the old HTML, the technology infrastructure of Web 2.0 is
complex and evolving, it includes server software, content syndication,
messaging protocols, standards-based browsers, and various client
applications. (Non-standard browser plugins and enhancements are generally
eschewed.) These differing but complementary approaches provide Web 2.0
with information storage, creation, and dissemination capabilities that go
beyond what was formerly expected of Web sites.
A Web site could be said to be built using Web 2.0 technologies if it features a
number of the following techniques:
Technical:









CSS, semantically valid XHTML markup, and Microformats
Unobtrusive Rich Application techniques (such as Ajax)
Technologies such as XUL and SVG
Syndication of data in RSS/Atom
Aggregation of RSS/Atom data
Clean and meaningful URLs
Weblog (Blog) publishing
JCC and REST or XML Webservice APIs
Some social networking aspects
General

The site should not act as a "walled garden" - it should be easy to get
data in and out of the system.
 Users usually own their data on the site and can modify at their
convenience.
 Mainly Web-based - most successful Web 2.0 applications can be
used almost entirely through a Web browser: this is commonly
referred to by the phrase "network as platform".
 Data returns should be dynamic, not static, changing depending on
variables associated with the user's query (e.g. keywords, location).
RSS
The first and most important evolution towards Web 2.0 involves the
syndication of Web site content, using standardised protocols which permit
end-users to make use of a site's data in another context, ranging from another
Web site, to a browser plugin, or a separate desktop application. Protocols
which permit syndication include RSS, RDF (as in RSS 1.1), and Atom, all of
which are flavours of XML. Specialised protocols such as FOAF and XFN
(both for social networking) extend functionality of sites or permit end-users
to interact without centralised Web sites.
New Web Protocols
Web communication protocols are a key element of the Web 2.0
infrastructure. Two major ones are REST and SOAP.
59
3 Briefing Documents On Web/Access

REST (Representational State Transfer) indicates a way to access and
manipulate data on a server using the HTTP verbs GET, POST, PUT,
and DELETE.
 SOAP involves POSTing XML messages and requests to a server that
may contain quite complex, but pre-defined, instructions for it to follow.
In both cases, access to the service is defined by an API. Often this API is
specific to the server, but standard Web service APIs (for example, for posting
to a blog) are also widely used. Most, but not all, communications with Web
services involve some form of XML (Extensible Markup Language).
Recently, a concept known as Ajax has evolved that can improve the user
experience in some browser-based Web applications. It involves a Web page
requesting an update for some part of its content, and altering that part in the
browser, without refreshing the whole page at the same time. There are
proprietary implementations (as in Google Maps) and open forms that can
utilise Web service APIs, syndication feeds, or even screen scraping.
Another relevant standard is WSDL (Web Services Description Language),
which is the standard way of publishing a SOAP API.
Server-side Software
Web 2.0 functionality builds on the existing Web server architecture, but puts
much greater emphasis on back-end software. Syndication differs only
nominally from dynamic content management publishing methods, but Web
services typically require much more robust database and workflow support,
and become very similar to the traditional intranet functionality of an
application server.
Web 2.0 has created new online social networks amongst the general public.
Some web sites run social software where people work together; others
reproduce multiple RSS feeds on one page; others provide deep-linking
between individual Web sites.
The syndication and messaging capabilities of Web 2.0 have created a tightlywoven social fabric not possible previously. The meaning of these changes,
however, has pundits divided. Basically, ideological lines run thusly: Web 2.0
either empowers the individual and provides an outlet for the 'voice of the
voiceless'; or it elevates the amateur to the detriment of professionalism,
expertise and clarity.
About This Document
This briefing document is based on the Web 2.0 definition given in Widipedia
– see <http://en.wikipedia.org/wiki/Web_2.0>. The Wikipedia Web site
should be accessed in order to follow links provided in the original version of
this document.
60
3 Briefing Documents On Web/Access
An Introduction To AJAX
About This Document
This QA Focus briefing document provides an introduction to AJAX.
Citation Details
An Introduction To AJAX, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-93/>
Keywords: Web, AJAX, Web 2.0, briefing
What Is AJAX?
Asynchronous JavaScript and XML (AJAX) is an umbrella term for a
collection of Web development technologies used to create interactive Web
applications, mostly W3C standards (the XMLHttpRequest specification is
developed by WHATWG [1]:

XHTML – a stricter, cleaner rendering of HTML into XML.

CSS for marking up and adding styles.

The Javascript Document Object Model (DOM) which allows the
content, structure and style of a document to be dynamically accessed
and updated.

The XMLHttpRequest object which exchanges data asynchronously
with the Web server reducing the need to continually fetch resources
from the server.
Since data can be sent and retrieved without requiring the user to reload an
entire Web page, small amounts of data can be transferred as and when
required. Moreover, page elements can be dynamically refreshed at any level
of granularity to reflect this. An AJAX application performs in a similar way
to local applications residing on a user’s machine, resulting in a user
experience that may differ from traditional Web browsing.
The Origins of AJAX
Recent examples of AJAX usage include Gmail [2], Flickr [3] and
24SevenOffice [4]. It is largely due to these and other prominent sites that
AJAX has become popular only relatively recently – the technology has been
available for some time. One precursor was dynamic HTML (DHTML), which
twinned HTML with CSS and JavaScript but suffered from cross-browser
compatibility issues. The major technical barrier was a common method for
asynchronous data exchange; many variations are possible, such as the use of
an “iframe” for data storage or JavaScript Object Notation for data
transmission, but the wide availability of the XMLHttpRequest object has
made it a popular solution. AJAX is not a technology, rather, the term refers to
a proposed set of methods using a number of existing technologies. As yet,
there is no firm AJAX standard, although the recent establishment of the Open
AJAX group [5], supported by major industry figures such as IBM and
Google, suggests that one will become available soon.
61
3 Briefing Documents On Web/Access
Using AJAX
AJAX applications can benefit both the user and the developer. Web
applications can respond much more quickly to many types of user interaction
and avoid repeatedly sending unchanged information across the network.
Also, because AJAX technologies are open, they are supported in all
JavaScript-enabled browsers, regardless of operating system – however,
implementation differences of the XMLHttpRequest between browsers cause
some issues, some using an ActiveX object, others providing a native
implementation. The upcoming W3C ‘Document Object Model (DOM) Level
3 Load and Save Specification’ [6] provides a standardised solution, but the
current solution has become a de facto standard and is therefore likely to be
supported in future browsers.
Although the techniques within AJAX are relatively mature, the overall
approach is still fairly new and there has been criticism of the usability of its
applications; further information on this subject is available in the AJAX and
Usability QA Focus briefing document [7]. One of the major causes for
concern is that JavaScript needs to be enabled in the browser for AJAX
applications to work. This setting is out of the developer’s control and
statistics show that currently 10% of browsers have JavaScript turned off [8].
This is often for accessibility reasons or to avoid scripted viruses.
Conclusions
The popularity of AJAX is due to the many advantages of the technology, but
several pitfalls remain related to the informality of the standard, its
disadvantages and limitations, potential usability issues and the idiosyncrasies
of various browsers and platforms. However, the level of interest from
industry groups and communities means that it is undergoing active and rapid
development in all these areas.
References
1. Web Hypertext Application Technology Working Group,
<http://www.whatwg.org/>
2. Gmail, <http://gmail.google.com/>
3. Flickr, <http://www.flickr.com/>
4. 24SevenOffice, <http://www.24sevenoffice.com/>
5. The Open AJAX group,
<http://www.siliconbeat.com/entries/ajax.pdf>
6. Document Object Model (DOM) Level 3 Load and Save Specification,
<http://www.w3.org/TR/DOM-Level-3-LS/>
7. AJAX and Usability, QA Focus briefing document,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-94/>
8. W3Schools Browser statistics,
<http://www.w3schools.com/browsers/browsers_stats.asp>
62
3 Briefing Documents On Web/Access
Introduction To OPML
About This Document
This QA Focus briefing document provides an introduction to OPML.
Citation Details
An Introduction To OPML, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-97/>
Keywords: Web, OPML, Web 2.0, briefing
OPML
OPML stands for Outline Processor Markup Language: OPML was
originally developed as an outlining application by Radio Userland. However
it has been adopted for a range of other applications, in particular providing an
exchange format for RSS.
This document describes the OPML specification and provides examples of
use of OPML for the exchange of RSS feeds.
The OPML Specification
The OPML specification [1] defines an outline as a hierarchical, ordered list of
arbitrary elements. The specification is fairly open which makes it suitable for
many types of list data. The OPML specification is very simple, containing the
following elements:
<opml version="1.0">
The root element which contains the version attribute and one head
and one body element.
<head>
Contains metadata. May include any of these optional elements: title,
dateCreated, dateModified, ownerName, ownerEmail,
expansionState, vertScrollState, windowTop, windowLeft,
windowBottom, windowRight.
<body>
Contains the content of the outline. Must have one or more outline
elements.
<outline>
Represents a line in the outline. May contain any number of arbitrary
attributes. Common attributes include text and type.
Limitations Of OPML
OPML has various shortcomings:

OPML stores data in XML attributes, which violates a XML design
principle.
 Information about OPML items cannot itself be hierarchically marked
up (ironically), due to the use of attributes to store that information.
 The RFC-822 date format used in OPML is considered obsolete.
63
3 Briefing Documents On Web/Access
OPML Applications
Import and Export of RSS Files
OPML can be used in a number of application areas. One area of particular
interest is in the exchange of RSS files. OPML can be used to group together
related RSS feeds. RSS viewers which provide support for OPML can then be
used to read in the group, to avoid having to import RSS files individually.
Similarly RSS viewers may also provide the ability to export groups of RSS
files as a single OPML file.
OPML Viewers
OPML viewers can be used to view and explore
OPML files. OPML viewers have similar
functionality as RSS viewers, but allow groups of
RSS files to be viewed.
The QA Focus Web site makes use of RSS and
OPML to provide syndication of the key QA
Focus resources [2]. This is illustrated in Figure 1,
which shows use of the Grazr inline OPML
viewer [3]. This application uses JavaScript to
read and display the OPML data.
Figure 1: Grazr
Other OPML viewers include Optimal OPML [4], and OPML Surfer [5].
Acknowledgments
This briefing document makes use of information published in the OPML
section on Wikipedia [6].
References
1. OPML Specification, <http://www.opml.org/spec>
2. RSS Feeds, QA Focus, <http://www.ukoln.ac.uk/qa-focus/rss/#opml>
3. Grazr, <http://www.grazr.com/>
4. Optimal OPML, <http://www.optimalbrowser.com/optimal.php>
5. OPML Surfer, <http://www.kbcafe.com/rss/opmlsurfer.aspx>
6.
OPML, Wikipedia,
<http://en.wikipedia.org/wiki/Outline_Processor_Markup_Language>
64
3 Briefing Documents On Web/Access
A URI Interface To Web Testing Tools
About This Document
This QA Focus briefing document describes a URI-interface to a wide range of testing tools.
Citation Details
A URI Interface To Web Testing Tools, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-59/>
Keywords: Web, testing, URI, briefing
Background
As described in other QA Focus briefing documents [1] [2] it is important to
ensure that Web sites comply with standards and best practices in order to
ensure that Web sites function correctly, to provide widespread access to
resources and to provide interoperability. It is therefore important to check
Web resources for compliance with standards such as HTML, CSS,
accessibility guidelines, etc.
This document summarises different models fort such testing tools and
describes a model which is based on provided an interface to testing tools
through a Web browsers address bar.
Models For Testing Tools
There are a variety of models for testing tools:
Desktop checking tools: Tools installed on a desktop computer, such as
link-checking software. Such tools will be familiar to many Web
developers.
Server-based tools: Tools installed on a server computer. Such tools
normally require systems administrators privileges.
Web-based tools: Tools which are accessible using a Web-interface.
This type of tool is a particular type of a server-based tool.
Although a variety of models are available, they all suffer from the lack of
integration will the normal Web viewing and publishing process. There is a
need to launch a new application or go to a new Web resource in order to
perform the checking.
A URI Interface To Testing Tools
A URI interface to testing tools avoids the barrier on having to launch an
application or move to a new Web page. With this approach if you wish to
validate a page on your Web site you could simply append an argument (such
as ,validate) in the URL bar when you are viewing the page.
The page being viewed will then be submitted to a HTML validation service.
This approach can be extended to recursive checking: appending
,rvalidate to a URI will validate pages beneath the current page.
65
3 Briefing Documents On Web/Access
This approach is illustrated. Note that this technique can be applied to a wide
range of Web-based checking services including:





CSS
compliance
Link checking
Automated
accessibility
checking
HTTP header
analysis
…
This approach has
been implemented
on the QA Focus
Web site (and on
UKOLN’s Web
site). For a complete list of tools available append ,tools to any URL on the
UKOLN Web site or see [3].
Implementing The URI Interface
This approach is implemented using a simple Web server redirect. This has the
advantage of being implemented in a single place and being available for use
by all visitors to the Web site.
For example to implement the ,validate URI tool the following line
should be added to the Apache configuration file:
RewriteRule /(.*),validate
http://validator.w3.org/check?uri=
http://www.foo.ac.uk/$1 [R=301]
where www.foo.ac.uk should be replaced by the domain name of your Web
server (note that the configuration details should be given in a single line).
This approach can also be implemented on a Microsoft ISS platform, as
described at [3].
References
1 Compliance with HTML Standards, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-01/>
2 Use Of Cascading Style Sheets (CSS), QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-34/>
3 Web Site Validation and Auditing Tools, UKOLN,
<http://www.ukoln.ac.uk/site/tools/>
66
3 Briefing Documents On Web/Access
QA for Web Sites: Useful Pointers
About This Document
This briefing document provides some useful pointers and advice on QA for Web sites.
Citation Details
Mothballing Your Web Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-46/>
Keywords: Web, useful pointers
Quality Assurance
Below are some key pointers that can help you enhance the Quality Assurance
procedures used for your Web site.
Useful Pointers
1
Authoring Tools Are the tools that you use to create your Web site
appropriate for their tasks? Do they produce compliant and accessible code?
Can the tools be configured to incorporate QA processes such as HTML
validation, link checking, spell checking, etc? If not, perhaps you should
consider evaluating other authoring tools or alternative approaches to creating
and maintaining your content.
2
Tracking Problems How do you deal with problem reporting? Consider
implementing a fault reporting log. Make sure that all defects are reported, that
ownership is assigned, details are passed on to the appropriate person, a
schedule for fixes is decided upon, progress made is recorded and the
resolution of problem is noted. There could also be a formal signing off
procedure.
3 Use A QA Model A model such as the QA Focus Timescale Model will help
you to plan the QA you will need to implement over the course of your
project:
Strategic QA: Carried out before development takes place. This involves
establishing best methodology for your Web site, the choice of standards,
etc.
Workflow QA: Carried out as formative QA before and during
development. This involves establishing and documenting a workflow,
processes etc.
Sign-off QA: Carried out as summative QA once one stage of development
has been carried out. This involves establishing an auditing system where
everything is reviewed.
On-going QA: Carried out as summative QA once one stage of
development has been carried out. This involves establishing a system to
report check, fix any faults found etc.
4 Use Automated Testing Tools There are a variety of tools out there for
use and a number are open source or free to use. These can be used for
HTML and CSS validation, link checking, measuring load times, etc.
67
3 Briefing Documents On Web/Access
5 Don’t Forget Manual Approaches Manual approaches to Web site testing
can address areas which will not be detecting through use of automated
tools. You should aim to test key areas of your Web site and ensure that
systematic errors which are found are addressed in areas of the Web site
which are not tested.
6 Use A Benchmarking Approach A benchmarking approach involves
comparisons of the findings for your Web site with your peers. This enables
comparisons to be made which can help you identify areas in which you
may be successful and also areas in which you may be lagging behind your
peers.
7 Rate The Severity Of Problems You could give a severity rating to
problems found to decide whether the work be done now or it can wait till
the next phase of changes. An example rating system might be:
Level 1: There is a failure in the infrastructure or functionality
essential to the Web site.
Level 2: The functionality is broken, pages are missing, links are
broken, graphics are missing, there are navigation problems, etc.
Level 3: There are browser compatibility problems, page formatting
problems, etc.
Level 4: There are display issues for example with the font or text
issues such as grammar.
8 Learn From The Problems You Find Make sure that do not just fix
problems you find, but understand why the problems have occurred so that
you can improve your publishing processes so that the errors do not
reoccur.
Useful URLs
The following URLs may be of interest.

Understanding Quality,
URL: <http://www.philosophe.com/qa/quality.html>

Testing Without A Formal Test Plan,
URL: <http://www.philosophe.com/testing/without_testplans.html>

Software QA and Testing Resource Centre,
URL: <http://www.softwareqatest.com/qafaq2.html>

Web Site Test Tools,
URL: <http://www.softwareqatest.com/qaweb1.html>

W3C Quality Assurance,
URL: <http://www.w3.org/2001/06tips/>

WebWatch Benchmarking Articles,
URL: <http://www.ukoln.ac.uk/webfocus/webwatch/articles/#latest>
68
4 Case Studies On Web/Access
4
Case Studies
Background
This section addresses access to resources, primarily through use of the Web.
The World Wide Web is the key delivery platform for many projects. There is
an expectation that projects will comply with W3C’s standards in this area,
including HTML and CSS.
There is a need to ensure that systematic processes for checking compliance
with such standards and used. It is not appropriate to rely on the appearance on
a Web page in a Web browser as browsers are designed to be tolerant of
errors. In addition we should seek to ensure that resources can be accessed by
accessibility tools (such as speaking browsers) and by non-traditional devices
(such as PDAs).
In addition to access to resources using traditional Web browsers there is an
increasing expectation that resources will be processed by automated software
or delivered in formats other than HTML.
The briefing documents seek to describe best practices in this area.
Case Studies
The following case studies which address the area of access/Web have been
produced:








Edinburgh University Library Online: Work In Progress (case-study26)
Gathering Usage Statistics And Performance Indicators: The (NMAP)
Experience (case-study-06)
Usability Testing for the Non-Visual Access to the Digital Library
(NoVA) Project (case-study-11)
Approaches to Accessibility at MIMAS (case-study-15)
Standards and Accessibility Compliance for the FAILTE Project Web
Site (case-study-31)
Standards and Accessibility Compliance for the DEMOS Project Web
Site (case study-10)
Strategy For Fixing Non-Compliant HTML Pages On The QA Focus
Web Site (case study-23)
Providing Access to an EU-funded Project Web Site after Completion
of Funding (case-study-17)

Exploiting ACRONYM And ABBR HTML Elements (case-study-29)

Using The ACRONYM And ABBR HTML Elements On The QA Focus
Web Site (case-study-30)
Case studies which cover specific technical areas are available within the
section on the appropriate technical area.
69
4 Case Studies On Web/Access
Edinburgh University Library Online:
Work In Progress
About This Document
This case study describes the approaches taken at the Edinburgh University Library towards
ensuring that their Web site complied with accessibility guidelines.
Citation Details
Edinburgh University Library Online: Work In Progress, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-26/>
Related Documents
See also the How To Evaluate A Web Site's Accessibility Level (briefing-12) and Use Of
Cascading Style Sheets (CSS) (briefing-34) briefing documents.
Keywords: Web, accessibility, Edinburgh University, Library Online, case study
Background
Library Online [1] shown in Figure 1 is
the main library Web site/portal for the
University of Edinburgh [2]. Although it
is not a project site, one of its functions is
to provide a gateway to project sites with
which the Library is associated [3].
In the last seven years or so it has grown
to around 2,000 static pages plus an
increasing amount of dynamic content,
the main database-driven service being
the related web-based Library Catalogue
[4]. At the time of writing (October
Figure 1: Library Online Entry Point
2003), a proprietary Digital Object
Management System has been purchased and is being actively developed. This
will no doubt impinge on some areas of the main site and, in time, probably
the Catalogue: notably access to e-journals and other digital
resources/collections. However, for the time being, Library Online and the
Catalogue between them provide the basic information infrastructure.
Problem Being Addressed
The challenges include enhancing accessibility and usability; also maintaining
standards as these develop. Problems exist with legacy (HTML) code, with
increasingly deprecated layout designs and separating content from
presentation. Addressing these issues globally presents real problems whilst
maintaining currency and a continuous, uninterrupted service. It is, of course,
a live site - and an increasingly busy one. There are currently over twenty
members of staff editing and publishing with varying levels of expertise and
no overall Content Management System, as such.
Policy has also been to maintain support for a whole range of older browsers,
further complicating matters.
70
4 Case Studies On Web/Access
The Approach Taken
Fortunately, the site design was based on Server-Side Includes (SSIs) and a
great deal of effort was put into conforming to best practice guidelines as they
were articulated over five years ago. The architecture appears to remain
reasonably sound. So an incremental approach has been adopted generally,
though some enhancements have been achieved quite rapidly across the board
by editing site-wide SSIs. A recent example of the latter has been the
introduction of the "Skip Navigation" accessibility feature across the whole
site.
A fairly radical redesign of the front page was carried out within the last two
years. This will need to be revisited before too long but the main focus is
presently on the body of the site, initially higher level directories,
concentrating on the most heavily-used key areas.
Enhancements to accessibility and usability are documented in our fairly
regularly updated accessibility statement [5]. These include:
 Font sizes are relative so users may resize text according to needs
 "Skip Navigation" feature introduced to allow text browsers and users
of assistive technology to bypass repetitive elements
 Stylesheets are being used extensively to separate content from
presentation
 Content should still be visible to browsers with no support for
stylesheets
 Pages are increasingly "resolution-independent" and able to expand or
contract to fit users' screens
 Images have alternate text (alt) tags
 As far as possible, links are written to make sense out of context
 Main links have titles added which display in many visual browsers as
"tooltips" but are also used by assistive technologies
 Where appropriate, text versions of pages are provided
 Page layouts still based on tables will have summaries amended to
"null" to avoid confusion with data tables. Also table headers are not
being used for layout tables
 Access keys have been introduced experimentally in an alternative
contact form
None of these features should be contentious, though precise interpretations
may vary. Many have been built in to the design since day one (e.g. "alt" tags);
others have been applied retrospectively and incrementally. All are, we hope,
worthwhile!
Additional functionality with which we are currently experimenting includes
media styles, initially for print. The original site navigation design was quite
graphically rich and not very "printer-friendly". Progress is being made in this
area - but who knows what devices we may need to support in the future?
Perhaps we shall eventually have to move to XML/XSLT as used within our
Collections Gateway due for launch soon. Meanwhile, for Library Online,
even XHTML remains no more than a possibility at present.
71
4 Case Studies On Web/Access
Our approach to site development is essentially based on template and
stylesheet design, supported by Server-Side Include technology for ease of
management and implementation. This largely takes care of quality assurance
and our proposed approach to content management should underpin this. We
are moving towards fuller adoption of Dreamweaver (MX) for development
and Macromedia Contribute for general publishing. Accessibility and usability
quality assurance tools are already in regular use including LIFT Online and
other resources identified on the site. It seems very likely that this will
continue.
All this remains very much work in progress ... Upgrading legacy code, layout
design, integration and interoperability with other information systems etc.
Categorically, no claims are made for best practice; more a case of constantly
striving towards this.
Problems Experienced
The main problems experienced - apart from time and resources naturally have been (a) the need to support older browsers; (b) the sheer number of
static pages and (c) the amount of legacy code and use of tabular layouts
Things We Would Do Differently
With the benefit of hindsight, perhaps stylesheets could have been
implemented more structurally. Validity has always been regarded as
paramount, while separation of true content from pure presentation might have
been given equal weight(?) This is now being reassessed.
We might have derived some benefit from more extensive database
deployment - and may well in the future - but we must constantly review,
reappraise possibilities offered by new technologies etc. and, above all, listen
to our users.
I have referred to some significant developments in prospect which present
more opportunities to do things differently - but whether we get these right or
wrong, there will always be scope for improvement on the Web, just as in the
"real" world. Like politics, it seems to be the art of the possible - or should that
be a science?
References
1. Library Online, Edinburgh University Library, <http://www.lib.ed.ac.uk/>
2. University of Edinburgh, <http://www.ed.ac.uk/>
3. Projects and Initiatives, Edinburgh University Library,
<http://www.lib.ed.ac.uk/projects/>
4. Edinburgh University Library Catalogue, <http://catalogue.lib.ed.ac.uk/>
5. Design for Accessibility and Usability, Edinburgh University Library,
<http://www.lib.ed.ac.uk/news/design.shtml>
Contact Details
Steve Scott, Library Online Editor, University of Edinburgh, Edinburgh
Email: steve.scott@ed.ac.uk
72
4 Case Studies On Web/Access
Gathering Usage Statistics And Performance
Indicators: The (NMAP) Experience
About This Document
This case study describes the use of Web site performance indicators by the NMAP project.
Citation Details
Gathering Usage Statistics And Performance Indicators: The (NMAP) Experience, QA
Focus, UKOLN, <http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-06/>
Related Documents
See also the Performance Indicators For Your Project Web Site (briefing-17) briefing
document.
Keywords: Web, usage, usage statistics, NMAP, case study
Background
The NMAP project [1] was funded under the JISC 05/99 call for proposals to
create the UK's gateway to high quality Internet resources for nurses,
midwives and the allied health professions.
NMAP is part of the BIOME Service, the health and life science component of
the national Resource Discovery Network (RDN), and closely integrated with
the existing OMNI gateway. Internet resources relevant to the NMAP target
audiences are identified and evaluated using the BIOME Evaluation
Guidelines. If resources meet the criteria they are described and indexed and
included in the database.
NMAP is a partnership led by the University of Nottingham with the
University of Sheffield and Royal College of Nursing (RCN). Participation
has also been encouraged from several professional bodies representing
practitioners in these areas. The NMAP team have also been closely involved
with the professional portals of the National electronic Library for Health
(NeLH).
The NMAP service went live in April 2001 with 500 records. The service was
actively promoted in various journal, newsletters, etc. and presentations or
demonstrations were given at various conference and meetings. Extensive use
was made of electronic communication, including mailing lists and
newsgroups for promotion.
Work in the second year of the project included the creation of two VTS
tutorials: the Internet for Nursing, Midwifery and Health Visiting, and the
Internet for Allied Health.
Problem Being Addressed
As one of the indicators of the success, or otherwise, in reaching the target
group we wanted to know how often the NMAP service was being used, and
ideally who they are and how they are using it.
73
4 Case Studies On Web/Access
The idea was to attempt to ensure we were meeting their needs, and also gain
data which would help us to obtain further funding for the continuation of the
service after the end of project funding.
There seems to be little standardisation of the ways in which this sort of data is
collected or reported, and although we could monitor our own Web server, the
use of caching and proxy servers makes it very difficult to analyse how many
times the information contained within NMAP is being used or where the
users are coming from.
These difficulties in the collection and reporting of usage data have been
recognised elsewhere, particularly by publishers of electronic journals who
may be charging for access. An international group has now been set up to
consider these issues under the title of project COUNTER [2] which issued a
“Code of Practice" in January 2003.
The Approach Taken
We took a variety of approaches to try to collect some meaningful data. The
first and most obvious of these is log files from the server which were
produced monthly and gave a mass of data including:






General Summary
Monthly Report:
Daily Summary
Hourly Summary
Domain Report
Organisation Report





Status Code Report
File Size Report
File Type Report
Directory Report
Request Report
A small section of one of the log files showing the general summary for
November 2002 can be seen below. Note that figures in parentheses refer to
the 7-day period ending 30-Nov-2002 23:59.
Successful requests: 162,910 (39,771)
Average successful requests per day: 5,430 (5,681)
Successful requests for pages: 162,222 (39,619)
Average successful requests for pages per day: 5,407 (5,659)
Failed requests: 2,042 (402)
Redirected requests: 16,514 (3,679)
Distinct files requested: 3,395 (3,217)
Unwanted logfile entries: 51,131
Data transferred: 6.786 Gbytes (1.727 Gbytes)
Average data transferred
per day: 231.653 Mbytes
(252.701 Mb)
A graph of the pages served can be
seen in Figure 1.
The log files also provided some
interesting data on the
geographical locations and
services used by those accessing
the NMAP service.
Listing domains, sorted by the
amount of traffic, example from
74
Figure 1: Pages served per month
4 Case Studies On Web/Access
December 2002, showing those over 1%.
Requests
% bytes
Domain
48237
31.59%
.com (Commercial)
40533
28.49%
[unresolved numerical addresses]
32325
24.75%
.uk (United Kingdom)
14360
8.52%
ac.uk
8670
7.29%
nhs.uk
8811
7.76%
.net (Network)
1511
1.15%
.edu (USA Educational)
Table 1: Linking to NMAP
A second approach was to see how many other sites were linking to the
NMAP front page URL. AltaVista was used as it probably had the largest
collection back in 2000 although this has now been overtaken by Google. A
search was conducted each month using the syntax
link:http://nmap.ac.uk The results can be seen in Figure 2.
Figure 2 - Number of sites linking to NMAP (according to AltaVista)
The free version of the service provided by InternetSeer [3] was also used.
This service checks a URL every hour and will send an email to one or more
email addresses saying if the site is unavailable. This service also provides a
weekly summary by email which, along with the advertising, includes a report
in the format:
========================================
Weekly Summary Report
========================================
http://nmap.ac.uk
Total Outages: 0.00
Total time on error: 00:00
Percent Uptime: 100.0
Average Connect time*: 0.13
Outages- number of times we were unable to access this URL
Time on Error- the total time this URL was not available
(hr:min)
% Uptime- the percentage this URL was available for the day
Connect Time- average time in seconds to connect to this URL
During the second year of the project we also conducted an online
questionnaire with 671 users providing data about themselves, why they used
75
4 Case Studies On Web/Access
NMAP and their thoughts on its usefulness or otherwise, however this is
beyond the scope of this case study and is being reported elsewhere.
Problems Experienced
Although these techniques provided some useful trend data about the usage of
the NMAP service there are a series of inaccuracies, partly due to the nature of
the Internet, and some of the tools used.
The server log files are produced monthly (a couple of days in areas) and
initially included requests from the robots used by search engines, these were
later removed from the figures. The resolution of the domains was also a
problem with 28% listed as "unresolved numerical addresses" which gives no
indication where the users is accessing from. In addition it is not possible to
tell whether .net or .com users are in the UK or elsewhere. The number of
accesses from .uk domains was encouraging and specifically those from .ac
& .nhs domains. It is also likely (from data gathered in our user
questionnaire) that many of the .net or .com users are students or staff in
higher or further education or NHS staff who accessing the NMAP service via
a commercial ISP from home.
In addition during the first part of 2002 we wrote two tutorials for the RDN
Virtual Training Suite (VTS) [4], which were hosted on the BIOME server
and showed up in the number of accesses. These were moved in the later part
of 2002 to the server at ILRT in Bristol and therefore no longer appear in the
log files. It has not yet been possible to get access figures for the tutorials.
The "caching" of pages by ISPs and within .ac.uk and .nhs.uk servers does
mean faster access for users but probably means that the number of users in
undercounted in the log files.
The use of AltaVista "reverse lookup" to find out who was linking to the
NMAP domain was also problematic. This database is infrequently updated
which accounts from the jumps seen in Figure 2. Initially when we saw a large
increase in November 2001 we thought this was due to our publicity activity
and later realised that this was because it included internal links within the
NMAP domain in this figure, therefore from April 2002 we collected another
figure which excluded internal links linking to self.
None of these techniques can measure the number of times the records from
within NMAP are being used at the BIOME or RDN levels of JISC services.
In addition we have not been able to get regular data on the number of
searches from within the NeLH professional portals which include an RDNInclude search box [5] to NMAP.
Things We Would Do Differently
In the light of our experience with the NMAP project we recommend that
there is a clear strategy to attempt to measure usage and gain some sort of
profile of users of any similar service.
I would definitely use Google rather than AltaVista and would try to specify
what is needed from log files at the outset. Other services have used user
registration and therefore profiles and cookies to track usage patterns and all
of these are worthy of consideration.
76
4 Case Studies On Web/Access
References
1.
2.
3.
4.
5.
NMAP, <http://nmap.ac.uk>
Project COUNTER, <http://www.projectcounter.org/>
InternetSeer, <http://www.internetseer.com/>
RDN Virtual Training Suite, RDN, <http://www.vts.rdn.ac.uk/>
RDN-Include, RDN, <http://www.rdn.ac.uk/rdn-i/>
Contact Details
Rod Ward
Greenfield Medical Library
Queen's Medical Centre
Nottingham NG7 2UH
Email: rw@biome.ac.uk
77
4 Case Studies On Web/Access
Usability Testing For The Non-Visual Access To The
Digital Library (NoVA) Project
About This Document
This case study describes approaches to usability and accessibility testing carried out by the
NoVA project.
Citation Details
Usability Testing for the Non-Visual Access to the Digital Library (NoVA) Project, QA
Focus, UKOLN, <http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-11/>
Related Documents
See also How To Evaluate A Web Site's Accessibility Level (briefing-12) briefing document.
Keywords: Web, usability, accessibility, testing, NoVA, case study
Background
The Non-Visual Access to the Digital Library (NoVA) project was
concerned with countering exclusion from access to information, which can all
too easily occur when individuals do not have so-called 'normal' vision.
Usability tests undertaken for the NoVA project provided an insight to the
types of problems faced by users and interestingly, although the focus of the
project was on the information seeking behaviour of blind and visually
impaired people (generally using assistive technologies), the control group of
sighted users also highlighted usability problems. This showed that although
awareness of Web accessibility is increasing, all types of user could be faced
with navigational problems, thus reinforcing the importance of involving a
variety of different users in any design and development project.
Some problems experienced were due to accessibility and usability conflicts
such as inappropriate or unhelpful use of alternative text, or poor use of
language. Other problems were due to a lack of understanding of the different
ways users interact and navigate around Web-based resources. Careful
consideration must therefore be given not only to assure conflicts between
accessibility and usability are addressed, but to the layout and navigation of a
site and to the ways different assistive technologies interact with them.
This case study will look specifically at the usability testing phase of the
NoVA project. The final report of the NoVA project [1] fully describes the
methodology, findings and conclusions, and outlines a number of
recommendations for digital library system design.
Problem Being Addressed
Despite evidence of much good work to make interfaces accessible and on
methods for accessibility checking (see for example: EDNER, 2002 [2] and
the World Wide Web Consortium Accessibility Guidelines [3] ), there is less
work published on usability issues or how people using assistive technologies
(such as screen readers) navigate around the Web interface.
Although sites may adhere to accessibility recommendations, users can still
experience navigational problems. This is partly due to the fact that Web
78
4 Case Studies On Web/Access
pages are increasingly designed for parallel or non-serial navigation, offering a
variety of options within one page (frames, tables, drop down menus etc).
Parallel design can cause problems for users who are navigating the site using
assistive technologies which force them down a serial (or linear) route, for
example a screen reader reading out every hypertext link on a page one by
one.
The overall objective of the NoVA project was to develop understanding of
serial searching in non-serial digital library environments, with particular
reference to retrieval of information by blind and visually impaired people.
Serial searching was defined for the project a linear movement between pages,
non-serial (or parallel) searching was defined as movements around a page,
between frames or interacting with a number of options such as a table,
dialogue box or drop-down menu.
The Approach Taken
Using a combination of desk research, task analysis and user interviews, the
objectives of the study were to:




Review existing studies into Web-based information seeking
behaviour.
Undertake a series of experiments with non-serial searching and
retrieval, and subsequent use of digital content.
Map approaches so as to develop understanding of how searching and
retrieval can be optimised in non-serial environments.
Report on findings and to make recommendations for digital library
system design.
The NoVA usability tests used a combination of observation, transaction
logging and verbal protocol, together with pre-and post-task questions.
The Sample
A sample of 20 sighted and 20 blind and visually impaired people was used to
undertake a series of usability experiments. Definitions of terms were set at
the beginning of the project. The 'sighted' sample was made up of users who
were all able to read a standard (14" - 15") screen. The term 'visually impaired'
was defined for the NoVA project as people who needed to use assistive
technology, or had to be very close to the screen to be able to 'read' it. The
sample size for the NoVA project enabled comparative analysis to take place
between two user groups, however it should be noted that Nielsen (2000) [4]
suggests excellent results can be obtained from usability tests comprising as
little as five users (although he recommends at least 15 users to discover all
the usability design problems).
The Usability Experiments
Four information-seeking tasks were set using four Web-based resources:
1. Search engine
2. Library OPAC
3. Online shopping site
79
4 Case Studies On Web/Access
4. Directory of Internet resources
Although not all of these might be viewed strictly as digital library resources,
each resource displayed elements of parallelism in their design and were
generally accessible, to greater and lesser degrees, according to the WAI
recommendations.
Each of the tasks was consistently set so that comparative analysis could take
place between the sighted and visually impaired users. For example, users
were asked to search for a national and regional weather forecast using the
same search engine.
It was recognised that success in performing searches could be influenced by
previous knowledge or experience, either of the technology, the site visited,
the subject matter of the task, or by individual interpretation and approach to a
task. In an attempt to obtain a balanced picture, the tasks set covered a fairly
broad subject base such as weather forecasts, shopping for clothes and travel
information.
Every attempt was made to create a relaxed atmosphere and to dispel feelings
among the users that they were being tested in any way (although inevitably
this still occurred to some extent). This included an initial explanation of the
purpose of the study, i.e. to highlight Web usability issues rather than to test
information seeking skills. The observer also chatted informally prior to the
tasks and offered the users tea/coffee and biscuits to put them at ease.
Naturally, the users were ensured that all their responses would be kept strictly
anonymous and only used for the stated purpose of the study.
To ensure everyone started from the same place, users were required to
commence using the stated electronic resource, but were allowed to choose
whether they used the search facility or browsed the site for relevant links. So
for example, when asked to look for the national weather forecast for the UK,
users were required to start with the search engine, either by typing in search
terms or by browsing for a relevant weather link.
Users were not given a time limit to complete each task. At the beginning of
the session they were told that they could stop the task at any time and were
given examples such as "if you are satisfied that you have found the
information", "if you are not satisfied, but think you have found all the
information there is", or "if you are fed up with the task". The reason for this
was to try and simulate real-life information searching behaviour, where
information required by a user may or may not be found from within a specific
resource and was not a judgment of the amount of information retrieved.
Data Capture
Data was gathered using a combination of on-screen data capture (Lotus
ScreenCam which records on-screen activity and verbal dialog), sound
recording and note taking. This method enabled each task to be recorded
(either on-screen or by the sound of the assistive technology with verbal
dialog) and backed up by note taking.
Users were asked to verbally describe what they were doing during each task.
Users were also asked a set of pre- and post-task questions. These comprised
general questions, such as how to tell a page is loading, initial comments about
80
4 Case Studies On Web/Access
the interfaces and the type of information provided; and usability questions,
such as their overall experience navigating around the resource. Both the
verbal protocol and the pre- and post task questions provided a richer picture
of the user's experience by enabling the observer to ascertain not only what
they had done, but why they had done it, and how they felt about it.
Interviews were conducted before and after each task to help ensure the
electronic resource and the task performed were still fresh in the user's mind
before moving on to the next resource.
Data Transcription
Data was transcribed in two ways:
1. Each step of the search process was logged and coded according to the
action performed by the user. For example, the action of clicking on a
link was coded as CO, tabbing down a page was coded as TD and the
TI code was assigned to the action of typing in terms.
2. Pre- and Post-task questions were transcribed verbatim.
Data from the searches and questions were entered and coded into a Computer
Assisted Qualitative Data Analysis tool (Atlas-ti) [5].
Data Analysis
Data was analysed using Atlas-ti analysis tool, which provided an efficient
method of data storage and retrieval. Although entering and coding data was
initially time consuming, once completed it provided quick and easy access to
the large amounts of data gathered for the project. It was then possible to
generate queries and reports for data analysis and report writing.
Each step taken during a search was coded to show the number and type of
keystroke used within each search task. This was used to compare the
information seeking behaviour of the two samples (sighted and visually
impaired) and to look at different trends within each.
Data from the pre- and post-task questions was grouped and coded into
categories. This enabled comparisons to be made relating to specific questions.
For example, coding quotes from users relating to the question 'How do you
know if a page is loading?' revealed that only one of the sighted users
mentioned the listening to the hard drive, whereas many of the visually
impaired users said they relied on this clue to tell them that the page is
loading.
Problems and Solutions
Gathering volunteers for the study was a time-consuming process and could
have been a problem if it had not been built in to the NoVA project time
frame. It is therefore worth bearing in mind that a substantial amount of time
and effort is needed to gather a suitable sample.
In order to obtain specific data on the way people search electronic sources, it
was necessary to select a sample of people who were reasonably familiar with
using the Internet and, where appropriate, were comfortable using assistive
technology. This meant that it was not possible to gather a true random
81
4 Case Studies On Web/Access
sample. Although this was not particularly problematic for the study, it did
mean that the results could not be generalised to the population as a whole.
Data was gathered using a combination of on-screen data capture (Lotus
ScreenCam [6]), sound recording and note taking. Initially it was hoped that
ScreenCam could be used throughout, however the pilot tests revealed that
ScreenCam can interfere with assistive technologies, so it was necessary to use
a combination of sound recording and note taking for the visually impaired
sample.
It was difficult to create a natural environment for the users to perform the
tasks, and although every attempt was made to make the users feel
comfortable and to dispel any feelings that their ability was being tested,
inevitably at times this did occur. However, this problem was probably
unavoidable for the capture of qualitative data.
The observer attempted not to prompt subjects or give any instructions while
the subject was performing the task. This proved difficult at times, particularly
when it was evident that the user was becoming distressed. In some cases the
observer had to provide a "hint" to enable the user to continue (it is suggested
that this type of intervention is sometimes necessary in certain circumstances,
as is prompting a user to ensure the transcription is accurately logged [7]).
Conclusions
The usability tests undertaken for the NoVA project provided a rich picture of
the types of problems faced by users when navigating around Web-based
resources, particularly when using assistive technologies. It also provided
evidence of the types of features users liked and disliked, how they overcame
navigational problems and what types of features enhanced their searching
experience, all of which can be fed back into recommendations for the design
of digital library systems.
Although the sample chosen was appropriate for the NoVA study, for general
usability studies it would be desirable to try to include users with a variety of
disabilities such as motor impairments, hearing impairments and visual
impairments. Testing with users with a mix of abilities will help ensure the site
is usable as well as interesting and engaging. Usability testing should be used
alongside accessibility checking to provide a rich picture of the accessibility
and usability of a Web site, which will help designers and developers to ensure
their sites embrace universal access and access for all.
The findings of the NoVA usability testing, together with conclusions and
recommendations are described in the final report on the NoVA project Web
site [1].
References
1. Non-Visual Access To The Digital Library: The Use Of Digital Library
Interfaces By Blind And Visually Impaired People, Craven, J. and Brophy,
P., Library and Information Commission Research Report 145,
Manchester: CERLIM, <http://www.cerlim.ac.uk/projects/nova.html>
2. Web Accessibility Issues for Higher & Further Education. Issues Paper 6,
EDNER Project, <http://www.cerlim.ac.uk/edner/ip/ip06.rtf>
82
4 Case Studies On Web/Access
3. Web Content Accessibility Guidelines 1.0, W3C,
<http://www.w3.org/TR/WCAG10/>
4. Why You Only Need To Test With 5 Users, Nielsen, J. (2000), Alertbox,
<http://www.useit.com/alertbox/20000319.html>
5. Atlas-ti, <http://www.atlasti.de/>
6. Lotus Screen Cam, <http://www.lotus.com/products/screencam.nsf>
7. Usability Engineering, Nielsen, J. (1993). Academic Press, p.197.
Contact Details
Jenny Craven
CERLIM
Manchester Metropolitan University
Manchester
Email: j.craven@mmu.ac.uk
83
4 Case Studies On Web/Access
Approaches to Accessibility at MIMAS
About This Document
This case study describes the approaches taken by MIMAS to ensuring their projects and
services complied with accessibility guidelines.
Citation Details
Approaches to Accessibility at MIMAS, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-15/>
Related Documents
Se also the How To Evaluate A Web Site's Accessibility Level (briefing-12) briefing
document.
Keywords: Web, accessibility, MIMAS, case study
Background
MIMAS [1] is a JISC-funded service [2] which provides the UK higher
education, further education and research community with networked access
to key data and information resources to support teaching, learning and
research across a wide range of disciplines. Services supported by MIMAS
include the ISI Web of Science Service for UK Education, CrossFire, UK
Census aggregate statistics, COPAC, the Archives Hub, JSTOR, a Spatial
Data service which includes satellite data, and a new International Data
Service (part of the Economic and Social Data Service) [3].
Problem Being Addressed
This document describes the approaches which have been taken by MIMAS to
ensure that its services provide levels of accessibility which are compatible
with MIMAS's available resources and the services it provides.
The work was carried out in order to ensure that MIMAS services are
compliant with the SENDA legislation wherever possible.
The Approach Taken
A MIMAS Project Management Team called ACE (Accessibility Compliance
Exercise) was set up with the remit of making recommendations on
accessibility work. We were set the task of making the MIMAS Web site
compliant at least with Priority 1 WAI guidelines [4] by 1 September 2002.
The ACE Team consisted of a coordinator and four members of MIMAS staff
with a range of skills, and chosen so that each section manager (of which there
are three) had at least one person on the team. We knew that it would take a
great deal of effort from many members of staff and that it was crucial to have
the support of all managers.
The coordinator reported to the MIMAS and Manchester Computing
management team and left technical issues to the rest of the team.
The team went about identifying the services, projects, areas of the MIMAS
Web sites and other items which are supported and/or hosted by MIMAS.
84
4 Case Studies On Web/Access
Usually the creator or maintainer, but in some cases the section manager was
identified as the person responsible for each area and a member of the ACE
team (the "ACE contact") was assigned to assist and monitor progress.
We drew a distinction between Web pages (information), data and
applications. It took some time to get the message through to all staff that
ACE (and SENDA) was concerned with all aspects of the services and that we
needed to check applications as well as Web pages. We could all have some
informed opinion about Web pages, but applications often required an expert
in the area to think about the accessibility of a package. Managers were asked
to request and gather statements from suppliers on the accessibility of their
products.
A Web page was set up on the staff intranet to document the progress each
service was making, who the main players were, and to summarise areas of
concern that we needed to follow up. This helped the ACE Team to estimate
the scope of any work which was needed, and managers to allocate time for
staff to train up in HTML and accessibility awareness. We also provide notes
on how to get started, templates, training courses etc., and we continue to add
information that we think will help staff to make their pages more accessible.
The ACE team met fortnightly to discuss progress. Members of the team
recorded progress on the staff intranet, and the coordinator reported to the
management team and to others in the Department (Manchester Computing)
engaged in similar work.
Goals
The ACE team recommended that MIMAS Web resources should aim to
comply with at least WAI Priority 1 guidelines. The ACE team had the
following aims:
1. To ensure that all Web pages under the auspices of MIMAS comply to
appropriate accessibility criteria by 1 September 2002. The minimum
criteria for existing pages is WAI Priority 1, but higher levels will be
sought where possible. WAI Priority 2 is the minimum level for new
resources.
2. To establish local conventions (for example where alternatives are
permitted within the WAI guidelines)
3. To provide guidance on accessibility issues, Web page design and
HTML to MIMAS staff.
4. To liaise, where appropriate, with other members of the Manchester
Computing department engaged in similar activities
5. To raise awareness of the issues and encourage staff to go on training
courses such as those provided by Manchester Computing WWW
Authoring courses [5] and Netskills courses [6].
Implementing The Solution
Software (Macromedia's LIFT) was purchased to assist staff evaluate their
pages, and extra effort was brought in to assist in reworking some areas
accessible.
85
4 Case Studies On Web/Access
The ACE team set up an area on the staff intranet. As well as the ongoing
progress report, and information about the project and the ACE team this
contained hints and tips on how to go about evaluating the accessibility of
Web pages, validating the (X)HTML, how to produce an implementation plan,
examples of good practice etc.
Other information on the Staff intranet included:












A case study on using Dreamweaver and LIFT to address accessibility
issues for the Zetoc service
Sample files showing:
Recommended META tags for MIMAS resources (including Dublin
Core)
Examples of XHTML 1.0 transitional and HTML 4.01 Web pages
Drop-down menus to access MIMAS services
How to skip to main content
Links to useful resources:
Lists of Priority 1 checkpoints
Approaches to accessibility for Java
Tools for link checking
Examples of cascading style sheets
Recommendations for providing online access to documents
Problems Experienced
The ACE team had their own pages to make accessible, whilst also being
available o help staff who needed guidance with their own Web sites. We all
had our usual day jobs to do, and time was short.
Some Web sites needed a lot of work. We brought in external help to rework
two large sites and encouraged the systematic use of Dreamweaver in order to
maintain the new standards. Using the Dreamweaver templates prepared by
the ACE team helped those staff who were not that familiar with HTML
coding.
Although Manchester computing and JISC put on Accessibility courses, not
all staff were able to attend. Group meetings were used to get the message
across, and personal invitations to attend the ACE workshops were successful
in engaging HTML experts, managers, programmers and user support staff.
There was still a lot to do after September 2002. Not all sites could reach
Priority 1 by September 2002. For these, and all services, we are
recommending an accessibility statement which can be reached form the
MIMAS home page. We continue to monitor the accessibility of Web pages
and are putting effort into making Web sites conform to the local conventions
that we have now set out in the MIMAS Accessibility Policy. This Policy is
for staff use, rather than a public statement, and is updated from time to time.
Accessibility statements [7] are specific to each service.
86
4 Case Studies On Web/Access
Phase 2
In January and February 2003, the ACE team ran a couple of workshops to
demonstrate key elements of the ACE policy - e.g. how to validate your pages,
and to encourage the use of style sheets, Dreamweaver, and to discuss ways of
making our Web sites more accessible generally.
We still have to ensure that all new staff are sent on the appropriate
accessibility courses, and that they are aware of the standards we have set and
aim to maintain.
Things We Would Do Differently
Workshops help everyone to be more aware of the issues and benefited the
ACE team as well as staff. Because of time constraints we were unable to
prepare our won ACE workshops until January 2003, by which time most sites
were up to Level 1. Other people's workshops (e.g. the JISC workshop) helped
those attending to understand the issues relating to their own sites, those
maintained by others at MIMAS, and elsewhere.
Talking to staff individually, in small groups, and larger groups, was essential
to keep the momentum going.
It would have been helpful to be more specific about the accessibility features
we want built in to the Web sites. For example, we encourage "skip to main
content" (Priority 3), and the inclusion of Dublin Core metadata.
References
1. MIMAS, <http://www.mimas.ac.uk/>
2. JISC, <http://www.jisc.ac.uk/>
3. ESDS, <http://www.esds.ac.uk/>
4. WAI Guidelines, W3C, <http://www.w3.org/WAI/>
5. Manchester Computing, <http://www.mc.man.ac.uk/>
6. Netskills, <http://www.netskills.ac.uk/>
7. MIMAS Accessibility Statements, MIMAS,
<http://www.mimas.ac.uk/accessibility.html>
Contact Details
Anne McCombe
MIMAS
University of Manchester
Manchester
87
4 Case Studies On Web/Access
Standards And Accessibility Compliance For The
FAILTE Project Web Site
About This Document
This case study describes the approaches taken by the FAILTE project to the deployment of
best practices for standards and accessibility.
Citation Details
Standards and Accessibility Compliance for the FAILTE Project Web Site, QA Focus,
UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-02/>
Related Documents
See also the Compliance With HTML Standards (briefing-01) briefing document.
Keywords: Web, standards, accessibility, compliance, FAILTE, case study
Background
The FAILTE project [1] was funded by JISC to provide a service which
engineering lecturers in higher education could use to identify and locate
electronic learning resources for use in their teaching. The project started in
August 2000. One of the first tasks was to set up a project Web site describing
the aims, progress and findings of the project and the people involved.
Problem Being Addressed
As an experienced Web author
I decided to use this
opportunity to experiment
with two specifications which
at that time were relatively
new, namely cascading style
sheets (CSS) and HTML. At
the same time I also wanted to
create pages which looked
reasonably attractive on the
Web browsers in common use
(including Netscape 4.7 which Figure 1: The FAILTE home page
has poor support for CSS) and
which would at least display intelligible text no matter what browser was used.
Why Use XHTML and CSS?
Here is not the place for a detailed discussion of the merits of separating
logical content markup from formatting, but I will say that I think that, since
this is how HTML was envisaged by its creators, it works best when used in
this way. Some of the reasons at the time of starting the Web site were:

I had recently been through the tedious experience of adjusting the
appearance of a Web site which had the formatting information held in
88
4 Case Studies On Web/Access



each page, and having one file which held the formatting information
for the entire site seemed an attractive proposition.
I wanted to increase the accessibility of the Web site by not using
tables to control the layout of the pages
At that time several of my colleagues were telling me that CSS "just
didn't work". I wanted to produce an example which showed to what
extent it was possible to rely CSS alone for styling.
It has been my experience that avoiding browser-specific
"enhancements" to HTML reduces the long-term maintenance
requirements for Web sites.
The Approach Taken
A quick investigation of the Web server log files from a related server which
dealt with the same user community as our project targeted lead us to the
decision that we should worry about how the Web site looked on Netscape
4.7, but not browsers with poorer support of XHTML and CSS (e.g. Netscape
4.5 and Internet Explorer 3).
The Web site was a small one, and there would be one contributor: me. This
meant that I did not have to worry about the lack of authoring tools for
XHTML at the time of setting up the Web site. I used HomeSite version 4.5, a
text editor for raw HTML code, mainly because I was familiar with it.
Divisions (<div> tags) were used in place of tables to create areas on the page
(a banner at the top, a side bar for providing a summary of the page content),
graphics were used sparingly, and colour was used to create a consistent and
recognisable look across the site. It is also worth noting that I approached the
design of the Web site with the attitude that it I could not assume that it would
be possible to control layout down to the nearest point.
While writing the pages I tested mainly against Netscape 4.7, since this had
the poorest support for XHTML and CSS. I also made heavy use of the W3C
XHMTL and CSS validation service [2], and against Bobby [3] to check for
accessibility issues. Once the code validated and achieved the desired effect in
Netscape 4.7 I checked the pages against a variety of browser platforms.
While it was never my aim to comply with a particular level of accessibility,
the feedback from Bobby allowed me to enhance accessibility while building
the pages.
Problems Experienced
Most of the problems stemmed from the need to support Netscape 4.7, which
only partially implements the CSS specification. This cost time while I tried
approaches which didn't work and then looked for work-around solutions to
achieve the desired effect. For example, Netscape 4.7 would render pages with
text from adjacent columns overlapping unless the divisions which defined the
columns had borders. Thus the <div> tags have styles which specify borders
with border-style: none; which creates a border but doesn't display it.
The key problem here is the partial support which this version of Netscape has
for CSS: older versions have no support, and so the style sheet has no effect on
89
4 Case Studies On Web/Access
the layout, and it is relatively easy to ensure that the HTML without the style
sheet makes sense.
Another problem was limiting the amount of white space around headings. On
one page in particular there were lots of headings and only short paragraphs of
text. Using the HTML <h1>, <h2>, <h3>, etc. tags left a lot of gaps and led to
a page which was difficult to interpret. What I wanted to do was to have a
vertical space above the headings but not below. I found no satisfactory way
of achieving this using the standard heading tags which worked in Netscape
4.7 and didn't cause problems in other browsers. In the end, I created class
styles which could be applied to a <span> to give the effect I wanted e.g.:
<p><span class="h2">Subheading</span><br />
Short paragraph</p>
This was not entirely satisfactory since any indication that the text was a
heading is lost if the browser does not support CSS.
Pleasant Surprises
The Web site is now two years old and in that time I have started using two
new browsers. I now use Mozilla as my main browser and was pleasantly
surprised that the site looks better on that than on the browsers which I used
while designing it. The second browser is an off-line Web page viewer which
can be used to view pages on a PDA, and which makes a reasonable job
rendering the FAILTE Web site - a direct result of the accessibility of the
pages, notably the decision not to use a table to control the layout of the page.
This is the first time that the exhortation to write Web sites which are deviceindependent has been anything other than a theoretical possibility for me
(remember WebTV?)
Things I Would Do Differently
I think that it is now much easier to use XHTML and CSS since the support
offered by authoring tools is now better. I would also reconsider whether
Netscape 4.7 was still a major browser: my feeling is that while it still needs
supporting in the sense that pages should be readable using it, I do not think
that it is necessary to go to the effort of making pages look attractive. In
particular I would not create styles which imitated <Hn> in order to modify
the appearance of headings. I look forward to the time when it is possible to
write a page using standard HTML repertoire of tags without any styling so
that it makes sense as formatted text, with clear headings, bullet lists etc., and
then to use a style sheet to achieve the graphical effect which was desired.
References
1 FAILTE, <http://failte.ac.uk/>
2 HTML Validation Service, W3C, <http://validator.w3.org/>
3 Bobby, WatchFire, <http://bobby.watchfire.com/>
Contact Details
Phil Barker, ICBL, MACS, Heriot-Watt University, Edinburgh
Email: philb@icbl.hw.ac.uk/
90
4 Case Studies On Web/Access
Standards And Accessibility Compliance For The
DEMOS Project Web Site
About This Document
This case study describes the approaches taken to use of standards and accessible Web design
by the DEMOS project.
Citation Details
Standards and Accessibility Compliance for the DEMOS Project Web Site QA Focus,
UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-10/>
Related Documents
See also the Compliance With HTML Standards (briefing-01) briefing document.
Note
This case study is also included in the QA For Standards Handbook.
Keywords: Web, standards, accessibility, compliance, DEMOS, case study
Background
Funded by the Higher Education Funding Council for England under strand
three of the initiative 'Improving Provision for Students with Disabilities', the
aim of the DEMOS Project [1] was to develop an online learning package
aimed at academic staff and to examine the issues faced by disabled students
in higher education. The project was a collaboration between the four
universities in the Manchester area - the University of Salford [2], the
University of Manchester [3], the Manchester Metropolitan University [4] and
UMIST [5].
The Web Site
At the start of the
project the purpose
of the Web site was
still unclear, which
made it difficult to
plan the information
structure of the site.
Of course, it would
serve as a medium
to disseminate the
project findings,
research reports,
case studies... but
Figure 1: The Demos Web Site
for months the
design and the information architecture of this site seemed to be in a neverending state of change.
91
4 Case Studies On Web/Access
In the early stage of the project virtual learning environments, such as WebCT,
were tested and deemed unsuitable for delivering the course material, due to
the fact that they did not satisfy the requirements for accessibility.
At this point it was decided that the Web site should carry the course modules.
This changed the focus of the site from delivering information about the
progress of the project to delivering the online course material.
In the end we envisioned a publicly accessible resource that people can use in
their own time and at their own pace. They can work through the modules in
the linear fashion they were written in or they can skip through via the table of
contents available on every page. There are also FAQ pages, which point to
specific chapters.
Many academic institutions have already added links to the DEMOS materials
on their own disability or staff development pages.
Problem Being Addressed
To ignore accessibility would have been a strange choice for a site that wants
to teach people about disability. Accessibility was therefore the main criteria
in the selection of a Web developer.
I have been a Web designer since 1998 and specialised in accessibility from
the very beginning. For me it is a matter of ethics. Now it is also the law.
The challenge here was to recreate, at least partially, the feeling of a learning
environment with its linear structure and incorporating interactivity in form of
quizzes and other learning activities without the use of inaccessible techniques
for the creation of dynamic content.
The Approach Taken
Accessibility techniques were applied from the beginning. But the site also
represents an evolution in my own development as a Web designer, it always
reflected my own state of knowledge. Where in the beginning accessibility
meant eradicating the font tag, it now means standard-compliant code and
tableless CSS layout.
Valid and Accessible Design and Code
This site was designed in compliance with the latest standards developed by
the World Wide Web Consortium (W3C) [6] and using the latest accessibility
techniques [7] as recommended by the Web Accessibility Initiative (WAI) [8].
In December 2001 the code base of the site was switched over to XHTML 1.0
Transitional. In November 2002 the site was further improved by changing it
to a CSS layout, which is used to position elements on the page without the
use of tables. The only layout table left is the one holding the header: logo,
search box and top navigation icons.
Stylesheets are also used for all presentational markup and a separate print
stylesheet has been supplied.
The code was validated using the W3C Validation Service [9].
92
4 Case Studies On Web/Access
Standards = Accessibility
With the advent of standard-compliant (version 6 and 7) browsers, the Web
developer community started pushing for the adoption of the W3C guidelines
as standard practise by all Web designer. Now that version 3 and 4 browsers
with all their proprietary mark-up were about to be consigned to the scrap
heap of tech history, it was finally possible to apply all the techniques the
W3C was recommending. Finally the makers of user agents had started
listening to the W3C too and were making browsers that rendered pages
designed according to standards correctly. (It turns out things weren't all that
rosy but that's the topic for another essay.)
Standards are about accessibility, or, as the W3C phrases it, 'universal design'.
They ensure that universal access is possible, i.e. that the information
contained on a Web page can be accessed using:





a modern standard-compliant browser on an up-to-date high spec PC
an old browser on a slow connection and legacy hardware
a text-only browser (often used as a basis for screen readers)
assistive technology (screen readers, foot pedals, braille printers, etc.)
a small device (PDA, mobile phone)
User Control
The most important reason for designing according to standards is that it gives
the user control over how a Web page is presented. The user should be able to
increase font sizes, apply preferred colours, change the layout, view headers in
a logical structure, etc.
This control can be provided by the Web designer by:




using correct structural markup
using stylesheets to specify presentational styles (such as fonts and
colours)
using CSS layout (instead of table layout)
applying accessibility techniques
On the DEMOS site, all presentational styles are specified in stylesheets. The
site 'transforms gracefully' when stylesheets are ignored by the user agent,
which means that the contents of a page linearises logically. The user has
control over background and link colours via the browser preferences and can
increase or decrease font sizes.
The DEMOS Guide to Accessible Web Design contains a chapter on User
Control [10], which describes how these changes can be applied in various
browsers.
Accessibility Techniques
(The links below lead to pages on the DEMOS site, more precisely: the
DEMOS Guide to Accessible Web Design [11])
Some of the techniques used:

A mechanism to skip to the main content was provided.
93
4 Case Studies On Web/Access












Access keys were defined.
Alternative descriptions were provided for all images. Purely
decorative images contain an empty ALT attribute.
Links are separated with printable characters.
Stylesheets are used to allow user control.
All acronyms and abbreviations are labelled.
Icons and colours are used in a consistent manner to improve
accessibility for users with cognitive or learning disabilities.
The site can be navigated via the keyboard.
Tables are only used for data, not for layout (except for the header
table).
Frames and dynamic content are avoided.
Accessible interactivity was provided using PHP.
Text is kept scannable, language clear and jargon is explained in
glossaries.
Language changes are declared for the benefit of screen readers.
More information and details: Accessibility techniques used on the DEMOS
site [12] (listed by WAI checkpoints).
Inclusive Design
Web developers sometimes believe that accessibility means providing a
separate text-only or low-graphics version for the blind. First of all: I have
always been on that side of the camp that believes that there should be only
one version of a site and that it should be accessible.
"Don't design an alternative text-only version of the site: disabled people
are not second class citizens..." (Antonio Volpon, evolt.org [13]).
Secondly, accessibility benefits not only blind people [14]. To be truly
inclusive we have to consider people with a variety of disabilities, people with
a range of visual, auditory, physical or cognitive disabilities, people with
learning disabilities, not to forget colour blindness, senior citizens, speakers of
foreign languages, etc.
Surely not all of them are part of the target audience, but you never know, and
applying all available accessibility techniques consistently does not take that
much more effort.
We tried to provide a satisfactory experience for everyone, providing user
control, keyboard access, icons and colour to loosen things up, whitespace and
headers to break up text in digestable chunks. And we encourage people to
provide feedback, especially if they experience any problems.
Accessibility Testing
To ensure accessibility the site was tested across a variety of user agents and
on different platforms. A number of screenshots from these tests [15] can be
found at the DEMOS site. The site has also been tested using the Bobby [16]
and Wave [17] accessibility checkers. It is AAA compliant, which means that
it meets all three levels of accessibility.
94
4 Case Studies On Web/Access
Accessible Interactivity
One of the last things we finally solved to our satisfaction was the problem of
creating interactive quizzes and learning activities for the course modules
without the use of inaccessible techniques. Many of the techniques for the
creation of dynamic and multimedia content (JavaScript, Java, Flash...) are not
accessible.
Eventually we discovered that PHP, a scripting language, was perfect for the
job. PHP is processed server-side and delivers simple HTML pages to the
browser without the need for plug-ins or JavaScript being enabled.
Problems Encountered
Information Architecture and Navigation
As mentioned before, the Web site started without a clear focus and without a
clear structure. Therefore there wasn't much planning and structured
development. In the first months content was added as it was created (in the
beginning mainly information about the project) and the site structure grew
organically. This caused some problems later when main sections had to be
renamed and content restructured. From the Web development point of view
this site has been a lesson in building expandability into early versions of Web
site architecture.
Since there was so much uncertainty about the information architecture in the
beginning, the navigation system is not the best it could be. The site grew
organically and navigations items were added as needed. The right-hand
navigation was added much later when the site had grown and required more
detailed navigation - more detailed than the main section navigation at the top
of the page underneath the logo and strapline.
But the right-hand navigation is mainly sub-navigation, section navigation,
which might be confusing at times. At the same time, however, it always
presents a handy table of contents to the section the visitor is in. This was
especially useful in the course modules.
The breadcrumb navigation at the top of the main content was also added at a
later date to make it easier for the visitor to know where they are in the
subsections of the site.
Netscape 4
Already mentioned in Phil Barker's report on the FAILTE Web site [18],
Netscape 4 was also my biggest problem.
Netscape 4 users still represent a consistent 12% of visitors in the UK
academic environment (or at least of the two academic sites I am responsible
for). Since this is the target audience for the DEMOS site, Netscape 4 quirks
(i.e. its lack of support for standards) had to be taken into account.
Netscape understands just enough CSS to make a real mess of it. Older
browsers (e.g. version 3 browsers) simply ignore stylesheets and display pages
in a simpler fashion with presentational extras stripped, while standardcompliant browsers (version 6 and 7) display pages coded according to
standards correctly. Netscape 4 is stuck right between those two scenarios,
95
4 Case Studies On Web/Access
which is the reason why the DEMOS site used tables for layout for a long
time.
Tables are not really a huge accessibility problem if used sparingly and wisely.
Jeffrey Zeldman wrote in August 2002 in 'Table Layout, Revisited' [19]:
Table layouts are harder to maintain and somewhat less forward
compatible than CSS layouts. But the combination of simple
tables, sophisticated CSS for modern browsers, and basic CSS
for old ones has enabled us to produce marketable work that
validates - work that is accessible in every sense of the word.
Tables might be accessible these days because screenreader software has
become more intelligent but standard-compliance was my aim and layout
tables are not part of that.
Luckily techniques have emerged that allow us to deal with the Netscape 4
quirks.
One option is to prevent Netscape 4 from detecting the stylesheet, which
means it would deliver the contents in the same way as a text-only browser,
linearised: header, navigation, content, footer following each other. No
columns, colours, font specifications. But an audience of 12% is too large to
show a site to that has lost its 'looks'. The site still had to look good in
Netscape 4.
The other option is to use a trick to get Netscape 4 to ignore some of the CSS
instructions [20] . Deliver a basic stylesheet to Netscape 4 and an additional
stylesheet with extra instructions to modern browsers. This required a lot of
tweaking and actually consumed an enormous amount of time but only
because I was new to CSS layout. I have converted a number of other sites to
CSS layout in the meantime, getting better at it every time.
The DEMOS site now looks good in modern browsers, looks OK but not
terrific in Netscape 4, and simply linearises logically in browsers older than
that and in text-only browsers.
To Do
There are still a few issues that need looking at, e.g. the accessibility of input
forms needs improving (something I'm currently working on) and the
structural mark-up needs improving so that headers are used in logical order
starting with <h1>
There are also a few clashes of forms with the CSS layout. All forms used on
the DEMOS site are still in the old table layout. I haven't had the time to figure
out what the problem is.
Eventually I also plan to move the code to XHTML Strict and get rid of the
remains of deprecated markup [21], which XHTML Transitional, the
DOCTYPE [22] used at the moment, still forgives.
The Site's Future
Of course it is important to keep the materials produced over the last two and a
half years accessible to the public after the funding has run out. This will
happen at the end of March 2003. This site will then become part of the
96
4 Case Studies On Web/Access
Access Summit Web site (at time of writing still under construction). Access
Summit is the Joint Universities Disability Resource Centre that was set up in
1997 to develop provision for and support students with disabilities in higher
education in Manchester and Salford.
We currently don't know whether we will be able to keep the domain name, so
keep in mind that the URL of the DEMOS site might change. I will do my best
to make it possible to find the site easily.
Further Information
DEMOS Web site, <http://www.demos.ac.uk/>
Jarmin.com Guide to Accessible Web Design,
<http://jarmin.com/accessibility/>
A collation of tips, guidelines and resources by the author of this case study.
Focuses on techniques but includes chapters on barriers to access, evaluation,
legislation, usability, writing for the Web and more. Includes a huge resources
section <http://jarmin.com/accessibility/resources/> where you can find links
to W3C guidelines, accessibility and usability articles, disability statistics,
browser resources, validation tools, etc. This section also contains resources
that helped me understand the power of stylesheets
<http://jarmin.com/accessibility/resources/css_layout.html>.
DEMOS Accessibility Guide, <http://jarmin.com/demos/access/>
Consists of the Techniques section from the Guide to Accessible Web Design
<http://jarmin.com/accessibility/>, plus extra information on accessibility
techniques used on the DEMOS site
<http://jarmin.com/demos/access/demos.html> (listed by WAI checkpoints)
and a number of demonstrations <http://jarmin.com/demos/access/
demos06.html> on how the site looks under a variety of circumstances.
References
1.
2.
3.
4.
5.
6.
7.
The DEMOS Project, <http://jarmin.com/demos/>
University of Salford, <http://www.salford.ac.uk/>
University of Manchester, <http://www.man.ac.uk/>
Manchester Metropolitan University, <http://www.mmu.ac.uk/>
UMIST, <http://www.umist.ac.uk/>
World Wide Web Consortium (W3C), <http://www.w3.org/>
Guide to Accessible Web Design, Iris Manhold,
<http://jarmin.com/accessibility/>
8. Web Accessibility Initiative (WAI), W3C, <http://www.w3.org/wai/>
9. Validation Service, W3C, <http://validator.w3.org/>
10. DEMOS Accessibility Guide: User Control, Iris Manhold,
<http://jarmin.com/demos/access/control.html>
11. DEMOS Accessibility Guide, Iris Manhold,
<http://jarmin.com/demos/access/>
12. Accessibility Techniques Used On The DEMOS Site,
<http://jarmin.com/demos/access/demos.html>
97
4 Case Studies On Web/Access
13. The Lifecycle of Web Accessibility, Antonio Volpon, evolt.org,
<http://evolt.org/article/The_Lifecycle_of_Web_Accessibility/20/50376/>
14. Benefits Of Accessibility, Iris Manhold,
<http://jarmin.com/accessibility/access/index.html>
15. The DEMOS site Tested, <http://jarmin.com/demos/access/demos06.html>
16. Bobby Accessibility Checker,
<http://bobby.watchfire.com/bobby/html/en/index.jsp>
17. Wave Accessibility Checker, <http://www.wave.webaim.org/>
18. Standards and Accessibility Compliance for the FAILTE Project Web Site,
QA Focus, Phil Barker, <http://www.ukoln.ac.uk/qafocus/documents/case-studies/case-study-02/>
19. Table Layout, Revisited, Jeffrey Zeldman, A List Apart, 17 August 2001,
<http://www.zeldman.com/daily/
0802d.html#livedandlovedlikefrank>
20. Tricking Browsers And Hiding Styles, Eric A. Meyer,
<http://www.ericmeyeroncss.com/bonus/trick-hide.html>
21. Deprecated markup, <http://jarmin.com/demos/access/deprecat.html>
22. Doctype, <http://jarmin.com/demos/access/doctype.html>
98
4 Case Studies On Web/Access
Strategy For Fixing Non-Compliant HTML Pages On
The QA Focus Web Site
About This Document
This case study describes how use of the W3C’s Web log validator tool has been used on the
QA Focus Web site to identify key non-compliant HTML pages which need to be fixed.
Citation Details
Strategy For Fixing Non-Compliant HTML Pages On The QA Focus Web Site, QA Focus,
UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-23/>
Related Document
See also the Compliance With HTML Standards (briefing-01) briefing document.
Keywords: Web, HTML, standards, compliance, checking, QA Focus, case study
Problem Being Addressed
It is important that HTML resources comply with the HTML standard.
Unfortunately in many instances this is not the case, due to limitations of
HTML authoring and conversion tools, a lack of awareness of the importance
of HTML compliance and the attempts made by Web browsers to render noncompliant resources. This often results in large numbers of HTML pages on
Web sites not complying with HTML standards. An awareness of the situation
may be obtained only when HTML validation tools are run across the Web
site.
If large numbers of HTML pages are found to be non-compliant, it can be
difficult to know what to do to address this problem, given the potentially
significant resources implications this may involve.
One possible solution could be to run a tool such as Tidy [1] which will seek
to automatically repair non-compliant pages. However, in certain
circumstances an automated repair could results in significant changes to the
look-and-feel of the resource. Also use of Tidy may not be appropriate if
server-side technologies are used, as opposed to simple serving of HTML
files.
This case study describes an alternative approach, based on use of W3C's Web
Log Validator Tool.
Solution Used
W3C's Log Validator Tool
W3C's Log Validator Tool [2] processes a Web site's server log file. The
entries are validated and the most popular pages which do not comply with the
HTML standard are listed.
99
4 Case Studies On Web/Access
Use On The QA Focus Web Site
The Web Log Validator Tool has been installed on the UKOLN Web site. The
tool has been configured to process resources on the QA Focus area (i.e.
resources in the http://www.ukoln.ac.uk/qa-focus/ area.
The tool has been
configured to run
automatically once a
month and the findings
held on the QA Focus
Web site [3]. An example
of the output is shown in
Figure 1.
When the tool is run an
email is sent to the Web
site editor and the
findings are examined.
We have a policy that we
Figure 1: Output From Web Log Validator Tool
will seek to fix HTML
errors which are reported by this tool.
This approach is a pragmatic one. It helps us to prioritise the resources to fix
by listed the most popular pages which are non-compliant. Since only 10 noncompliant pages are listed it should be a relatively simple process to fix these
resources. In addition if the errors reflect errors in the underlying template, we
will be in a position to make changes to the template, in order to ensure that
new pages are not created containing the same problems.
Lessons Learnt
We have internal procedures for checking that HTML pages are compliant.
However as these procedures are either dependent on manual use (checking
pages after creation or updating) or run periodically (periodic checks across
the Web site) it is useful to make use of this automated approach as an
additional tool.
Ideally this tool would be deployed from the launch of the Web site, in order
to ensure best practices were implemented from the start.
References
1
2
3
HTML Tidy Project Page, <http://tidy.sourceforge.net/>
Log Validator Tool, W3C, <http://www.w3.org/QA/Tools/LogValidator/>
QA Focus Statistics: Non-Compliant HTML Pages, QA Focus,
<http://www.ukoln.ac.uk/qa-focus/statistics/web-log-validator/>
Contact Details
Brian Kelly, UKOLN, University of Bath, BATH, UK, BA2 7AY
Email: B.Kelly@ukoln.ac.uk
100
4 Case Studies On Web/Access
Exploiting ACRONYM And ABBR HTML Elements
About This Document
This case study describes use of a harvester which has been developed to create an automated
glossaries.
Citation Details
Exploiting ACRONYM And ABBR HTML Elements, QA Focus, UKOLN,
<http http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-29/>
Keywords: Web, Web site, acronym, abbreviation, HTML, case study
Background
The UK Centre for Materials Education [1] supports academic practice and
innovative learning and teaching approaches in Materials Science and
Engineering, with the aim of enhancing the learning experience of students.
The Centre is based at the University of Liverpool, and is one of 24 Subject
Centres of the national Learning and Teaching Support Network [2].
Problem Being Addressed
Within any field, the use of discipline-specific language is widespread, and
UK Higher Education is no exception. In particular, abbreviations are often
used to name projects, programmes or funding streams. Whilst use of these
initialisms can be an essential tool of discussion amongst peers, they can also
reduce accessibility and act as a barrier to participation by others.
In this context, many individuals and organisations maintain glossaries of
abbreviations. However, glossaries of this nature usually require manual
editing which can be incredibly resource intensive.
This case study describes a tool developed at the UK Centre for Materials
Education to help demystify abbreviations used in the worlds of Higher
Education, Materials Science, and Computing, through the use of an
automated 'Web crawler'.
The Approach Taken
The HTML 4 specification [3] provides two elements that Web authors can
use to define abbreviations mentioned on their Web sites; <abbr> to markup
abbreviations and <acronym> to markup pronounceable abbreviations,
known as acronyms.
The acronyms and abbreviations are normally identified by underlining of the
text. Moving the mouse over the underlined words in a modern browser which
provides the necessary support (e.g. Opera and Mozilla) results in the
expansion of the acronyms and abbreviations being displayed in a pop-up
window, as illustrated in Figure 1.
Using this semantic markup as a rudimentary data source, the crawler retrieves
Web pages and evaluates their HTML source code for instances of these tags.
When either of the tags is found on a page, the initials and the definition
101
4 Case Studies On Web/Access
provided are recorded in a
database, along with the
date/time and the URL of
the page where they were
seen.
The pairs of abbreviations
and definitions identified
by the crawler are then
made freely available
online at [4] as illustrated in
Figure 2 to allow others to
benefit from the work of
the crawler.
Problems Experienced
Figure 1: Rendering Of <ACRONYM> Element
The limiting factor first
encountered in developing the crawler has been the lack of Web sites making
use of the <abbr> and <acronym> tags. Consequently, the number of
entries defined in the index is relatively small, and the subject coverage
limited. Sites implementing the tags are predominantly those that address Web
standards and accessibility, leading to a strong bias in the index towards
abbreviations used in these areas.
A number of factors likely contribute to a lack of use of the tags. Firstly, many
Web authors might not be aware of the existence of the tags. Even in the
current generation of Web browsers, there is little or no support for rendering
text differently where it has been marked up as an abbreviation or acronym
within a Web page. Therefore there is little opportunity to discover the tags
and their usage by chance.
The second major factor
affecting the quality of the
index produced by the
crawler has been the
inconsistent and
occasionally incorrect
definition of terms in pages
that do use the tags. Some
confusion also exists about
the semantically correct
way of using the tags,
especially the distinction
between abbreviations and
acronyms, and whether
incorrect semantics should
be used in order to make
use of the browser support
that does exist.
Figure 2: The Glossary Produced By
Harvesting
<ABBR> and <ACRONYM> Elements
Things We Would Do
102
4 Case Studies On Web/Access
Differently/Future Developments
To provide a truly useful resource, the crawler needs to be developed to
provide a larger index, with some degree of subject classification. How this
classification might be automated raises interesting additional questions.
Crucially, the index size can only be increased by wider use of the tags.
Across the HE sector as a whole, one approach might be to encourage all
projects or agencies to 'take ownership' of their abbreviations or acronyms by
defining them on their own sites. At present this is rarely the case.
In order to provide a useful service the crawler is reliant on more widespread
deployment of <acronym> and <abbr> elements and that these elements
are used correctly and consistently. It is pleasing that QA Focus is
encouraging greater usage of these elements and is also addressing the quality
issues [5].
Lastly, if sites were to produce their pages in XHTML [5] automated
harvesting of information in this way should be substantially easier. XML
parsing tools could be used to process the information, rather than relying on
processing of text strings using regular expressions, as is currently the case.
References
1. UK Centre for Materials Education, <http://www.materials.ac.uk/>
2. Learning and Teaching Support Network, <http://www.ltsn.ac.uk/>
3. HTML 4.01 Specification, W3C,
<http://www.w3.org/TR/html4/>
4. Abbreviations and Acronyms related to Materials, Higher Education and
Computing, <http://www.materials.ac.uk/acronyms/>
5. Using The ACRONYM And ABBR HTML Elements On The QA Focus Web
Site, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-30/>
6. XHTML 1.0 The Extensible HyperText Markup Language (Second Edition),
W3C, <http://www.w3.org/TR/xhtml1/>
Contact Details
Tom Heath
Web Developer
UK Centre for Materials Education
Materials Science and Engineering
Ashton Building, University of Liverpool
Liverpool, L69 3GH
Email t.heath@liv.ac.uk
URL: http://www.materials.ac.uk/about/tom.asp
103
4 Case Studies On Web/Access
Using The ACRONYM And ABBR HTML Elements
On The QA Focus Web Site
About This Document
This case study describes how the acronym/abbreviation harvester has been used to create an
automated glossary of terms on the QA Focus Web site.
Citation Details
Using The ACRONYM And ABBR HTML Elements On The QA Focus Web Site, QA Focus,
UKOLN, <http http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-30/>
Keywords: Web, Web site, acronym, abbreviation, glossary, HTML, QA Focus, case study
Background
After hearing about the automated tool which harvested <abbr> and
<acronym> elements [1] it was decided to begin the deployment of these
elements on the QA Focus Web site. This case study reviews the issues which
needed to be addressed.
Problem Being Addressed
The <abbr> and <acronym> elements were developed primarily to enhance
the accessibility of Web pages, by allowing the definitions of abbreviations
and acronyms to be displayed. The acronyms and abbreviations are normally
identified by underlining of the text. Moving the mouse over the underlined
words in a modern browser which provides the necessary support (e.g. Opera
and Mozilla) results in the expansion of the acronym or abbreviation being
displayed in a pop-up window. An example is illustrated in Figure 1.
As Tom Heath's case
study describes, these
elements can be
repurposed in order to
produce an automated
glossary.
Since the QA Focus
Web site contains many
abbreviations and
acronyms (e.g. Web
terms such as HTML
and SMIL, programme,
project and service
terms such as JISC,
FAIR and X4L and
Figure 1: Rendering The <ACRONYM>
expressions from the
Element
educational sector such
as HE and HEFCE it
was recognised that there is a need for such terms to be explained. This is
normally done within the text itself e.g. "The JISC (Joint Information Systems
Committee) ...". However the QA Focus team quickly recognised the potential
104
4 Case Studies On Web/Access
of the <abbr> and <acronym> harvesting tool to produce an automated
glossary of tools.
This case study describes the issues which QA Focus needs to address in order
to exploit the harvesting tool effectively.
The Approach Taken
The QA Focus Web site makes use of PHP which assemble XHTML
fragments. The HTML-Kit authoring tool is used to manage the XHTML
fragments. This approach was used to create <abbr> and <acronym> elements
as needed e.g.:
<abbr title="Hypertext Markup Language">HTML</abbr>
In order to ensure that the elements had been used correctly we ensure that
pages are validated after they have been updated.
Problems Experienced
The harvesting tool processed pages on the UKOLN Web site, which included
the QA Focus area. When we examined the automated glossary which had
been produced [2] we noticed there were a number of errors in the definitions
of abbreviations and acronyms, which were due to errors in the definition of
terms on the QA Focus Web site.
Although these errors were quickly fixed, we recognised that such errors were
likely to reoccur. We recognised the need to implement systematic quality
assurance procedures, especially since such errors would not only give
incorrect information to end users viewing the definitions, but also any
automated glossary created for the Web site would be incorrect.
In addition, when we read the definitions of the <abbr> and <acronym>
elements we realised that there were differences between W3C's definitions of
these terms and Oxford English Dictionaries of these terms in English usage.
We also recognised that, even allowing for cultural variations, some terms
could be classed either as acronyms or abbreviations. For example the term
"FAQ" can either be classed as an acronym and pronounced "fack" or an
abbreviation with the individual letters pronounced - "eff-ay-queue".
A summary of these ambiguities is available [3].
We recognised that the <abbr> and <acronym> elements could be used in a
number of ways. A formally dictionary definition could be used or an informal
explanation could be provided, possible giving some cultural context. For
example the name of the FAILTE project could be formally defined as
standing for "Facilitating Access to Information on Learning Technology for
Engineers". Alternatively we could say that "Facilitating Access to
Information on Learning Technology for Engineers. FAILTE is the Gaelic
word for 'Welcome', and is pronounced something like 'fawl-sha'.".
We realised that there may be common variations for certain abbreviations
(e.g. US and USA). Indeed with such terms (and others such as UK) there is
an argument that the meaning of such terms is widely known and so there is
no need to explicitly define them. However this then raises the issue of
agreeing on terms which do not need to be defined.
105
4 Case Studies On Web/Access
We also realised that there will be cases in which words which would appear
to be acronyms or abbreviations may not in fact be. For example UKOLN,
which at one stage stood for 'UK Office For Library And Information
Networking' is now no longer an acronym. An increasing number of
organisations appear to be no longer expanding their acronym or abbreviation,
often as a result of it no longer giving a true reflection of their activities.
Finally we realised that we need to define how the <abbr> and <acronym>
elements should be used if the terms are used in a plural form or contain
punctuation e.g.: in the sentence:
JISC's view of ...
do we use:
<acronym title="Joint Information Systems
Committee">JISC's<acronym> …
or:
<acronym title="Joint Information Systems
Committee">JISC<acronym>'s ...
Our Solutions
Policies
We recognised that we need to develop a policy on our definition or acronyms
or abbreviations and QA procedures for ensuring the quality.
The policies we have developed are:
We will seek to make use of the <acronym> and <abbr> elements on the
QA Focus Web site in order to provide an explanation of acronyms and
abbreviations used on the Web site and to have the potential for this
structured information to be re-purposed for the creation of an automated
glossary for the Web site.
We will use the Oxford English Dictionary's definition of the terms
acronyms and abbreviations. We treat acronyms as abbreviations which
are normally pronounced in standard UK English usage as words (e.g.
radar, JISC, etc.); with abbreviations the individual letters are normally
pronounced (e.g. HTML, HE, etc.). In cases of uncertainty the project
manager will adjudicate.
The elements will be used with the formal name of the acronyms and
abbreviations and will not include any punctuation.
We will give a formal definition. Any additional information should be
defined in the normal text.
We will not define acronyms or abbreviations if they are no longer to be
treated as acronyms or abbreviations.
Procedures
Implementing QA procedures is more difficult. Ideally acronyms and
abbreviations would be defined once within a Content Management System
and implemented from that single source. However as we do not have a CMS,
this is not possible.
106
4 Case Studies On Web/Access
One aspect of QA is staff development. We will ensure that authors of
resources on the QA Web site are aware of how these elements may be
repurposed, and thus the importance of using correct definitions.
Future Developments
We will liaise with Tom Heath, developer of the acronym and abbreviation
harvester to explore the possibilities of this tool being used to display usage of
<abbr> and <acronym> elements on the QA Focus Web site.
Although the issues explored in this case study are not necessarily significant
ones the general issue being addressed is quality of metadata. This is an
important issue, as in many cases, metadata will provide the 'glue' for
interoperable services. We hope that the approaches described in this case
study will inform the work in developing QA procedures for other types of
metadata.
References
1. Exploiting ACRONYM And ABBR HTML Elements, QA Focus. UKOLN,
<http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-29/>
2. Abbreviations and Acronyms related to Materials, Higher Education and
Computing, UK Centre for Materials Education,
<http://www.materials.ac.uk/acronyms/>
3. Abbreviations, Acronyms, Initialisms, larsholst.info/blog,
<http://larsholst.info/blog/index.php?p=14&more=1#more14>
Contact Details
Brian Kelly
UKOLN
University of Bath
BATH, BA1 3LY
Email: B.Kelly@ukoln.ac.uk
107
4 Case Studies On Web/Access
Providing Access To An EU-funded Project Web Site
After Completion of Funding
About This Document
This case study describes how the Exploit Interactive project Web site was ‘mothballed’ after
the project funding had ceased.
Citation Details
Providing Access to an EU-funded Project Web Site after Completion of Funding, QA Focus,
UKOLN, <http http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-17/>
Keywords: Web. Web site, preservation, long term access, Exploit Interactive, case study
Background
Exploit Interactive [1] was a pan-European Web magazine, which was funded
by the European Commission's Telematics for Libraries programme. The
magazine was one of the project deliverable of the EXPLOIT project, which
aimed to promote the results of EU library projects and to facilitate their takeup by the market of library and information systems. The magazine ran for
seven issues between May 1999 and October 2000. During its lifetime the
magazine developed and maintained a strong and involved community of
Exploit Interactive readers, authors, project partners and information providers
and provided a forum for discussion within the EU Telematics for Libraries
community.
Problem Being Addressed
Prior to the last issue being published it was recognised that maintaining the
site could possibly be a problem. Funding would cease and there would no
longer be a member of staff working on the site.
Note that this case study does not address the wider long-term preservation
issues. In particular it does not address:

The formats of the resources: if the file formats used (mainly HTML,
CSS JPEG and GIF) become obsolete, we do not address how access
can be obtained.

The functionality of the service provided: if the service becomes
unavailable (e.g. due to an operating system upgrade) we do not
guarantee that the service will be restored.

Access to resources if the host institution ceased to exist: we do not
guarantee to provide access if our organisation ceases to exist.

Access to resources due to catastrophe: we do not guarantee to provide
access in the event of catastrophes, such as a fire which destroys the
server and backups.
The case study provides a pragmatic approach to access to the Web site after
the project funding has finished.
108
4 Case Studies On Web/Access
The Approach Taken
It was decided to agree on a short-medium term access strategy for the Exploit
Interactive Web site. This strategy would list policies and procedures for
maintenance of the site for the next 10 years. It would also allow us to allocate
money to certain activities.
10 years was decided upon primarily because the preservation industry rule of
thumb is that data should be migrated every 10 years. It is unlikely that we
will have the resources to migrate the Exploit Interactive Web site.
Short-Medium Term Access Strategy
The Web site's domain name will be kept for at least 3 years after the end of
funding.
We will seek to ensure the Web site continues for at least 10 years after the
end of funding.
We will seek to ensure that the Web site continues to function, although we
cannot give an absolute commitment to this.
We will not commit to fixing broken links to external resources.
We will not commit to fixing non-compliant HTML resources.
We will use the following procedures:
We will have internal administrative procedures to ensure that the domain
name bill is paid (even if current staff leave).
We will record the disk space usage of the Web site and provide an estimate of
the cost of providing this disk space (in order to monitor the disk space usage
costs).
We will run a link checker at least annually and record the number of internal
broken links. We will keep an audit trail so that we can see if internal links
start breaking.
We will use the UKOLN online calendar to remind staff when to rerun the
check.
Any changes to the policy which would result in the Web site being removed
need to be agreed by an appropriate management group. This would not be
done for purely technical reasons.
The area on which Exploit Interactive is held was measured:
Disk Size: 3.92 Gb (3920 Mb)
Exploit Interactive live site: 62.9 Mb
Exploit Interactive development site: 70.3 Mb
Exploit Interactive log files: 292 Mb
Exploit Interactive currently takes up 425.4 Mg of disk space.
The cost of this space is negligible bearing in mind you can purchase 30 Gb
disk drives for about £40.
We have established that the domain name has been paid for until 23rd
October 2008. We feel this is a sufficiently long period of time.
109
4 Case Studies On Web/Access
Problems Experienced
Two years on from the end of funding there have been very few problems
adhering to the access strategy. The domain name has been held and a regular
link checking audit has been initiated [2] Time spent on the maintenance of
the site, such as link checking, has been minimal (about 30 minutes per year to
run a link check and provide links to the results).
There are a number of potential problems which we could face:

The Web site could stop working due to technical difficulties (for
example, if the operating system was upgraded it might be necessary to
upgrade the backend scripting software.

The Web site may fail WAI Web accessibility guidelines and there
could be legal liabilities in continuing to host the Web site.

The Web site may be too search-engine friendly and searches from
Google, etc. may find out-of-date resources from the Exploit
Interactive Web site rather than more up-to-date resources provided by
UKOLN.
However in practice we think such possibilities are unlikely.
We are confident that we will be able to continue to host this resource for at
least 3 years and for a period of up to 10 years. However this is, of course,
dependent on our organisation continuing to exist during this period.
References
1. Exploit Interactive,<http://www.exploit-lib.org/>
2. Exploit Interactive Link Check,
<http://www.exploit-lib.org/link-check/>
Contact Details
Brian Kelly
UKOLN
University of Bath
BATH
UK
Email: B.Kelly@ukoln.ac.uk
110
5 Web Toolkit
5
Web Toolkit
Web Toolkit
The Web toolkit provides a checklist which is intended to ensure that projects address key
areas when planning the deployment of metadata.
Note that an online version of this toolkit is available from <http://www.ukoln.ac.uk/qafocus/toolkit/>. The online version provides links to relevant QA Focus resources.
1. Purpose Of Your Web Site
Have you identified the purpose of your
Web site? Has the purpose been agreed by
all partners?
If so, please give details.
2. Standards For Your Web Site
Have you chosen the standards to be used on
your Web site? Have you identified
permissible exceptions? Have you
documented your decisions?
If so, please give details.
3 Technical Architecture
Have you defined the technical architecture
for your Web site?
Does the chosen architecture allow you to
implement your chosen standards?
If so, please give details.
4 Usability And Accessibility
Have you defined usability and accessibility
policies?
If so, please give details.
5 Checking Procedures
Have you defined procedures which will
ensure that your policies are complied with?
If so, please give details.
111
5 Web Toolkit
6. Interoperability Issues
Will your Web site be interoperable with
other services? If so have you addressed any
interoperability issues?
If so, please give details.
7. Life After Project Funding
Have you developed plans which will
address the status of your Web site after the
project funding has finished?
If so, please give details.
8. Legal Issues
Have you ensured that the content of your
Web sites is legal and that there are issues
concerning copyright, IPR, acceptable
content, accessibility, freedom of
information, data protection, etc.
If so, please give details.
9. Training And Staff Development
Do you have a training strategy which will
ensure that staff involved in developing and
managing your Web site have received
appropriate training?
If so, please give details.
10. Resourcing Issues
Have you the resources needed to implement
the above?
If so, please give details.
Use Of This Toolkit
It is envisaged that this toolkit will be used to support the planning processes at the early
stages of the development of your project Web site.
The issues covered in the toolkit are intended to help in the technical and managerial
discussions which projects will be involved in.
112
6 Web Policies and Procedures
6
Web Policies and Procedures
This section provides a number of examples of QA policies and procedures which
can help to ensure that Web sites are functional, widely accessible and interoperable.
Web Policy
About This Policy
This document describes the policies and procedures for Web standards for the QA Focus
Web site.
Citation Details
Policy on Web Standards, QA Focus, UKOLN,
<http://www.ukoln.ac.uk/qa-focus/qa/policies/web/>
Procedures For Web Standards, QA Focus, UKOLN,
http://www.ukoln.ac.uk/qa-focus/qa/procedures/web/>
Keywords: Web. QA, policy
Area:
Web Standards
Policy:
QA Focus Web pages will be based primarily on XHTML 1.0 Transitional and
Cascading Stylesheets (CSS). Resources should comply fully with the appropriate
standards.
We will use the following DOCTYPE declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The following xmlns declaration will be used for the XHTML namespace:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
Justification:
Compliance with appropriate standards should ensure that access to Web resources is
maximised and that resources can be repurposed using tools such as XSLT.
Responsibilities:
The QA Focus project manager is responsible for this policy. The QA Focus Web editor
is responsible for ensuring that appropriate procedures are deployed.
Exceptions:
Resources which are derived automatically from other formats (such as MS
PowerPoint) need not comply with standards. In cases where compliance with this
policy is felt to be difficult to implement the policy may be broken. However in such
cases the project manager must give agreement and the reasons for the decision must be
documented.
Compliance measures:
When new resources are added to the Web site or existing resources updated QA Focus
will check XHTML validation using ,validate after each page is created. QA Focus will
run a monthly batch validation check on the whole site using ,rvalidate. All
113
6 Web Policies and Procedures
manually created pages will be checked. QA Focus is not responsible for pages created
externally.
When new stylesheets are added to the Web site or existing stylesheets updated QA
Focus will check Cascading Stylesheets (CSS) validation using ,cssvalidate after
each page is created. QA Focus will run a monthly batch validation check on the whole
site.
Audit trail:
Reports from the monthly audit will be published on the Web site. The QA Focus Blog
will be used to link to the audit.
114
6 Web Policies and Procedures
Links Policy
About This Policy
This document gives the policies & procedures for link checking on the QA Focus Web site.
Citation Details
Policy on Link Checking, QA Focus, UKOLN, <http://www.ukoln.ac.uk/qa-focus/qa/policies
links/>
Procedures For Link Checking, QA Focus, UKOLN, <http://www.ukoln.ac.uk/qafocus/qa/procedures/links/>
Keywords: Web. QA, links, link checking, policy
Area:
Link Checking
Policy On Links To QA Focus Web Site:
It is acceptable for other Web sites to link to the QA Focus Web site or documents
within the QA Focus Web site without seeking permission. They should give
comprehensive citation details. QA Focus will seek to ensure that URLs remain stable.
Policy On Links From QA Focus Web Site:
QA Focus will not seek permission for linking to external Web sites. If it is requested
by an external organisation that a link to their Web site is removed QA Focus will do
so.
Policy On Broken Links:
QA Focus will seek to ensure that internal links within the site are not broken.
QA Focus will seek to ensure that links within the site to external resources are not
broken.
Justification:
It is important to avoid broken links on the Web for usability.
Responsibilities:
The QA Focus project manager is responsible for this policy. The QA Focus Web editor
is responsible for ensuring that appropriate procedures are deployed.
Exceptions:
Links in "publications" (e.g. papers which are formally published) which become
broken may not be fixed.
If there are large numbers of broken links which would be time-consuming to fix we
may not fix them.
We make no commitment to fix broken links once the QA Focus funding finishes.
Compliance Measures:
QA Focus will check links using ,linkcheck after each page is created. QA Focus
will run a monthly link check on the whole site. Internal broken links will be corrected.
If possible external broken links will be corrected.
For further information see Approaches To Link Checking Briefing Paper.
Audit trail:
Reports from the quarterly audit will be published on the Web site.
115
7 Further Information
7
Further Information
We hope that the QA For Web Handbook provides useful advice to projects
and services which are engaged in digital library development work.
In addition to this handbook there are other sources of information funded by
the JISC which provide useful advice.
UKOLN
UKOLN is funded by the JISC
and the MLA (Museums,
Libraries and Archives Council)
to provide advice and support on
digital management issues to the
further and higher education and
cultural heritage communities.
Further information on UKOLN
is available on the Web site
which is available at
<http://www.ukoln.ac.uk/>. The
UKOLN Web site is illustrated.
The UKOLN Web Site
Netskills
Netskills is supported by the
JISC to provide quality Internet
training services to facilitate the
effective use of Internet and
Intranet technologies for teaching
and learning, research,
administration, marketing and
other business activities.
Further information on Netskills
is available on the Web site
which is available at
The Netskills Web Site
<http://www.netskills.ac.uk/>.
The Netskills Web site is illustrated.
116
Acknowledgements
Acknowledgements
We are grateful to the following for contributing to the work of the QA Focus
project:
Members of the JISC including Caroline Ingram our initial point of
contact in JISC and Rachel Bruce and Balviar Notay, who provided
valuable advice and support to the QA Focus team following Caroline’s
departure from JISC.
The contributors to the case studies included in the handbook: Steve
Scott (University of Edinburgh), Rod Ward (Queen's Medical Centre,
Nottingham), Jenny Craven (CERLIM, Manchester Metropolitan
University), Anne McCombe (MIMAS), Phil Barker (ICBL, Heriot-Watt
University), Iris Manfold and Tom Heath (UK Centre for Materials
Education, University of Liverpool).
Colleagues at UKOLN and the AHDS who provided valuable input to
the work of the QA Focus project.
Karla Youngs and Ed Bremner, TASI, for their contributions to the work
of QA Focus in its early days.
Others involved in JISC and related work who, knowingly or
unknowingly, contributed to our work.
117