This accessibility statement applies to Lancaster University’s core external website.

This website is run by Lancaster University. We want as many people as possible to be able to use this website. For example, that means you should be able to:

• zoom in up to 400% without the text spilling off the screen
• navigate most of the website using just a keyboard
• navigate most of the website using speech recognition software
• listen to most of the website using a screen reader

We also try to make the content as simple as possible to understand.

AbilityNet has advice on making your device easier to use if you have a disability.

How accessible this website is

We know some parts of this website are not fully accessible:

• Some links do not make sense when read out of context with a screen reader (for example “Read more”).
• Some pages have multiple links with the same text (e.g. “Read more”) but different destinations.
• Most older PDF documents aren’t fully accessible to a screen reader.
• Some virtual tours and interactive videos can’t be used with a keyboard.
• Some videos don’t have captions.
• Some audio files don’t have transcripts.
• Some images don’t have alternative text.
• Some form labels don’t have sufficient contrast.

Feedback and contact information

If you need information on this website in a different format like accessible PDF, large print, easy read, audio recording or Braille, email webmaster@lancaster.ac.uk. We’ll consider your request and get back to you as soon as possible.

Reporting accessibility problems with this website

We’re always looking to improve the accessibility of this website. If you find any problems that aren’t listed on this page or think we’re not meeting the requirements of the accessibility regulations, please email webmaster@lancaster.ac.uk.

What to do if your problem isn’t dealt with satisfactorily

If you have contacted us about an accessibility problem (e.g. because you needed information in a different format, or you think we're not meeting the requirements of the accessibility regulations) but you feel that this has not been dealt with satisfactorily we want to know.

The first stage would be to raise your concern informally. The aim of this stage is to achieve a quick and easy solution for you. It would be appropriate to take the concern through the relevant contact listed above for reporting an accessibility problem.

But if we do not deal with your concern satisfactorily you can take it through to a formal complaint. See our Concerns, complaints and enforcement information.

Enforcement procedure

The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’). If you’re not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS)

Technical information about this website’s accessibility

Lancaster University is committed to making its website accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Compliance status

This website is partially compliant with the Web Content Accessibility Guidelines version 2.2 AA standard, due to the non-compliances listed on this page.

Non-accessible content

The content listed below is non-accessible for the following reasons.

Non-compliance with the accessibility regulations

Links

• You may find link text that doesn’t make sense when read on its own (e.g. 'Read more').
• On some pages there are multiple links with the same link text but different destinations on one page.
• Some links don’t provide text describing their purpose (e.g. content is an image, the link triggers a Javascript function, or link is generated automatically even when there's no content).
• Some links have an empty or missing 'href' attribute.
• Some visible labels do not match the accessible name

This doesn't meet WCAG success criterion 2.4.4 Link Purpose (In Context), 2.5.3: Label in Name and 2.1.1 Keyboard.

We scan the site weekly for the issues listed above, and aim to fix them as soon as they are identified.

Some link text is automatically generated and we are updating these to provide more context.

Images

You may find images that don’t have a text alternative, so the information in them isn’t available to people using a screen reader.

This doesn't meet WCAG success criterion 1.1.1 Non-text Content.

We scan the site weekly for this issue, and aim to fix it as soon as it is identified.

When we publish new content, we make sure our use of images meets accessibility standards.

Videos

• Some of our videos may not provide captions, so they are not accessible to people with impaired hearing.
• Some videos use automated captions that are sometimes inaccurate.

This doesn't meet WCAG success criterion 1.2.1 Audio-only and Video-only (Prerecorded) and 1.2.2 Captions (Prerecorded).

As videos without captions are identified they are removed or updated. When we publish new videos, we make sure that captions have been added, and that automatically-generated captions have been checked for mistakes.

Live video

Most of our live video streams (e.g. graduation ceremonies) will not have captions.

Where possible we will encourage presenters to use live captions and subtitles, but we don’t intend to enforce the addition of captions to all live video streams at this stage.

Adding captions to live video is exempt from the accessibility regulations.

PDFs and other documents

We have a large number (around 650) of non-compliant PDF files, and have instigated a project to address this. This project began in the autumn of 2022 and is ongoing. This project includes the update or removal of problem files, and a programme of education for web content creators.

PDF titles

• Some PDF documents do not have descriptive titles.
• This does not meet WCAG success criterion 2.4.2 Page Titled.
• Where the PDF is current, we aim to update or remove it as soon as possible We do not intend to update older PDFs.

PDF language settings

• Some PDF documents do not specify the default language of the document.
• This does not meet WCAG success criterion 3.1.1 Language of Page.
• Where the PDF is current, we aim to update or remove it as soon as possible. We do not intend to update older PDFs.

PDF Bookmarks

• Some PDF documents do not provide bookmarks within the document.
• This does not meet WCAG success criterion 2.4.5 Multiple Ways.
• Where the PDF is current, we aim to update or remove it as soon as possible. We do not intend to update older PDFs.

Text and content

Styles and structure

• In some places it is possible for content to be added to our website that includes inline styles, combining presentation and structure. Alternatively, some non-tabular content uses tables for layout.
• This doesn’t meet WCAG success criterion 1.3.1 Info and Relationships, 1.4.5 Images of Text, and 1.4.3 Contrast (Minimum).
• We use automated checks to identify and fix these issues as they occur.
• Where content is historical, no longer maintained or kept online for historical or reference reasons, we do not intend to go back and improve it.

Navigation

• Some historical pages do not include links to skip repeated content such as navigation, or don’t identify regions of the page.
• We have completed a project to migrate active pages to accessible page templates. We don’t intend to update archive content that is no longer maintained and will either remove such pages or clearly mark them as archived.

Headings

• HTML headings are used inconsistently on our web pages, and our content is not always organised into well-defined sections. This makes it harder for users to get an overview of our content and how it is organised.
• This doesn’t meet WCAG success criterion 2.4.6 Headings and Labels.
• We use automated checks to identify and fix this issue. We are also improving training for content authors.
• Where content is historical, no longer maintained or kept online for historical or reference reasons, we do not intend to go back and improve it.

Interactive tools

Forms

several forms are provided by external third-party systems. We are working with providers of third-party systems to ensure forms provided by their systems are accessible.

• Some forms have element id attributes that are not unique. This doesn’t meet WCAG 2.1 success criterion 4.1.1 Parsing. This criterion is obsolete in WCAG 2.2.
• Some form fields are not labelled. This doesn’t meet WCAG success criterion 4.1.2: Name, Role, Value.
• Some forms have text that doesn’t provide sufficient contrast. This doesn’t meet WCAG success criterion 1.4.3: Contrast (Minimum).
• Some forms contain images without text alternatives. This doesn’t meet WCAG success criterion 1.1.1: Non-text Content.

Google Maps

Some pages use Google Maps. These are not accessible to users of assistive technology such as screen readers. Not all maps are accompanied by text-based directions to the marked location.

Where a map is being used, we will add a description of the location for the landmark in question.

360 interactive panoramas (virtual tours)

We have three instances of 360-degree interactive panoramas which are linked to from our business web pages and which can’t be used with a keyboard. These features don’t meet WCAG success criterion 2.1.1 Keyboard, and in some cases also fail to meet 2.1.2 No Keyboard Trap.

We will review the need to retain these features. Similar new features that are added to our web pages will be keyboard-operable and offer an accessible alternative.

Tableau embedded data visualisations

When more than one Tableau data visualisation is on the page, each iframe has the same title. This doesn't meet success criterion 4.1.2 Name, Role, Value. We have sought to mitigate this by adding descriptive text and a heading before each instance and will investigate the feasibility of adding individual titles to each iframe.

Content that’s not within the scope of the accessibility regulations

PDFs and other documents

The accessibility regulations don’t require us to fix PDFs or other documents published before 23 September 2018 if they’re not essential to providing our services.

Live video

Live video streams don’t have captions. This doesn’t meet WCAG 2.2 success criterion 1.2.4 (captions - live).

We don’t plan to add captions to live video streams because live video is exempt from meeting the accessibility regulations.

What we’re doing to improve accessibility

All of our CMS-managed ‘core content’ has been migrated to accessible content styles. We will continue to revise our page templates to comply with accessibility best practice.

Where inaccessible content has been produced outside of the CMS system, we will encourage content owners to migrate to accessible page templates.

To reinforce awareness of accessibility best practice and to guard against common errors we provide guidance and training for our web editors. We intend to make accessibility training mandatory for university content creators.

Preparation of this accessibility statement

This statement was prepared on 10 September 2019. It was last reviewed on 18 March 2024.

The website was last tested on 18 March 2024. The test was carried out by Lancaster University.

We used this approach to test our website:

• We test our core website regularly using automated tools that scan every page for problems: Funnelback (nightly) and Siteimprove (weekly).
• The reports are checked at least weekly by the website development and content teams to identify areas for improvement and monitor site trends.
• We aim to fix high priority issues within two weeks of identification.

Our core website is produced by a Content Management System (CMS) that enables content editors to create pages based on building blocks.

We test each individual building block to ensure it meets accessibility requirements in isolation using a variety of techniques including automated tools and manual testing using keyboard and screen readers.

We also test the empty page container within which these building blocks are placed. This enables us to test every page generated by the CMS for accessibility by ensuring the individual components are accessible.