Accessibility

Find out how to navigate the ßÏßÏÊÓƵ website and see our accessibility statement.

Accessibility statement for the ßÏßÏÊÓƵ

The ßÏßÏÊÓƵ is committed to making its website accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

This accessibility statement applies to the ßÏßÏÊÓƵ website, , ,  and mobile applications.

We want as many people as possible to be able to use this website. That means you should be able to:

  • access most of the information found on the site
  • zoom most pages in up to 300% 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, and navigate, most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)
  • access all video content, either visually, or through accessible technology.

We’ve also made the website text as simple as possible to understand. Within our content management system (CMS), we have a built in readability score tool. This generates a score which tells us how readable our content is.

How accessible this website is

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

  • pages with navigation blocks and Broadcast feeds do not follow a hierarchical heading structure
  • video content does not have captions
  • video content does have captions but the colour contrast does not meet accessibility standards
  • video content does not have a transcript
  • PDFs are not accessible to screen reader software
  • user interface elements do not meet colour contrast standards
  • of our third party applications, such as our chatbots, may not meet Web Content Accessibility Guidelines (WCAG) (these are currently being audited).

Further detail on our compliance status and non-accessible content is set out below.

Feedback and contact information

If you are having trouble accessing content on this site, need content in a different format, or wish to provide feedback, contact us at: web-accessibility@sussex.ac.uk.

Reporting accessibility problems with this website

We’re always looking to improve the accessibility of this website. If you find any problems not listed on this page or think we’re not meeting accessibility requirements, contact: web-accessibility@sussex.ac.uk.

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, .

Technical information about this website

The ßÏßÏÊÓƵ 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 , due to the non-compliances and the exceptions listed below. Some areas of the website which were developed before September 2018 may not meet the AA accessibility standard.

Non-accessible content

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

Non-compliance with the accessibility regulations 

  • Some images do not have alt tags. This means users of assistive technologies may not have access to information conveyed in images. This fails WCAG 2.2 success criterion 1.1.1 (Non-text Content).
  • Some video embeds may not have captions. This fails WCAG 2.2 success criterion 1.2.2: Captions (Prerecorded).
  • Some video embeds have captions that do meet colour contrast standards. This fails WCAG 2.2 success criterion 1.4.3: Contrast (Minimum).
  • Some video embeds do not have transcripts. This fails WCAG 2.2 success criterion 1.2.8: Media Alternative (Prerecorded).
  • Some video embeds do not have an audio described option. This fails WCAG 2.2 success criterion 1.2.5: Audio Description (Prerecorded).
  • Some video embeds do not have a title. This fails WCAG 2.2 success criterion 4.1.2: Name, Role, Value.
  • Some user interface elements do not have sufficient colour contrast. This fails WCAG 2.2 success criterion 1.4.3: Contrast (Minimum).
  • Many of the pages in the older templates do not meet accessibility standards, particularly around colour contrast and the use of some web components, including video embeds. This fails WCAG 2.2 success criterion 1.4.3: Contrast (Minimum), 1.2.2: Captions (Prerecorded), 1.2.8: Media Alternative (Prerecorded), 1.2.5: Audio Description (Prerecorded) and 4.1.2: Name, Role, Value. An example of this is the School of Engineering and Informatics website. Work is underway to move all pages and sites out of this template, for example the School of Media, Arts and Humanities now use the newer, more accessible, template.
  • Many of the internal focussed staff pages do not meet accessibility standards, particularly around colour contrast. This fails WCAG 2.2 success criterion 1.4.3: Contrast (Minimum). We have a new, accessible, template and are starting to migrate content to this template starting with the staff homepage.
  • Some of the pages with navigation blocks or Broadcast feeds do not follow a hierarchical heading structure. We plan to address this issue, starting with the Student and Staff Hubs. This fails WCAG 2.2 success criterion 1.3.1: Info and Relationships.
  • Our forms are not created using semantic elements and therefore may be difficult to navigate for some screen readers. We have tested in house using VoiceOver and NVDA and found the forms to be usable in their current state. We will be looking to improve this code in the future. This fails WCAG 2.2 success criterion 1.3.1: Info and Relationships.
  • We use CAPTCHA elements on the website. These fail WCAG 2.2 success criterion 3.3.8: Accessible Authentication (Minimum)
  • Our library advanced search system does not completely meet WCAG accessibility standards. This system is provided by an external supplier. We have been in discussion with their development team and they have worked to resolve some areas of non-compliance. The teams are aware of the outstanding items and these should be addressed in future updates to their user interface.
  • Our postgraduate application form does not meet accessibility standards. We are currently working to aquire a new system. In the meantime we are working to improve this service so that it meets the requirements.
  • ßÏßÏÊÓƵ Direct does not meet accessibility standards. We are currently working to aquire a new system. In the meantime we are working to improve this service so that it meets the requirements.
  • ßÏßÏÊÓƵ profiles do not meet all accessibility standards. This system is provided by an external supplier. We are currently working with them to improve the service so that it meets the requirements.
  • Our virtual tour does not meet accessibility standards. We have provided a text version of the tour that is accessible and meets most standards. It is not currently possible to launch video content or navigate 360 images using keyboard in the text version of the virtual tour.
  • Our study online pages do not meet accessibility standards. These pages are provided by an external supplier. We are currently working with them to improve the pages so that they meets the requirements.
  • Our chatbots, that are supplied by third parties, may not meet WCAG standards. We are currently undertaking an audit with  to investigate the accessibility of these.
  • The ßÏßÏÊÓƵsport app and online booking system does not meet accessibility standards. We are currently working with a third party provider to resolve some areas of non compliance with the ßÏßÏÊÓƵsport app and online booking system. 
  • The campus map is a pdf file and is not screen reader friendly – we do have an alternative with  and a page on how to travel to the University.
  • The self-guided tour app does not meet accessibility standards. These pages are still being audited. We plan to work with the external supplier to resolve some areas of non compliance with the self-guided tour app. 
  • The Staff Welcome Handbook does not meet accessibility standards. We are currently working to resolve the areas of non-compliance. 
  • Our Open Day booking forms are not fully compliant. We are currently working to resolve the areas of non-compliance. 

Jobs portal

Our  does not completely meet WCAG 2.1 and 2.2 accessibility standards. This system is provided by an external supplier. We are currently working with the external supplier to resolve these issues. You can find out more about the content which is not compliant with the accessibility regulations below.

  • Non-accessible content in the Jobs Portal

    We audited our jobs pages in May 2024 and found they are only partially compliant with WCAG 2.1 and 2.2. We are working with our external supplier to address these issues, however until they are remedied the content listed below is non-accessible for the following reason(s):

    Keyboard-only issues

    • On the jobs portal homepage the dropdown menus for 'Role type' and 'Department' cannot be accessed using the keyboard, there is also no mechanism to dismiss the additional content triggered without moving pointer hover or keyboard focus. This fails WCAG 2.2 success criterion 2.1. Keyboard Accessible and WCAG 1.4.13 Content on Hover or Focus. This is planned to be resolved by September 2025.
    • The keyboard tabs into the cookie banner at the bottom of the webpage after tabbing from the 'Skip to main content' option in the jobs portal. This does not follow a logical focus order for users. This fails WCAG 2.2 success criterion 2.4.3 Focus Order. This is planned to be fixed by end of December 2024.
    • Within the application form, the cookie banner obscures content on the page with focus moving behind it. The focus order is also not logical with the cookie banner receiving focus last. This fails WCAG 2.2 success criterion 2.4.3 Focus Order and 2.4.11: Focus Not Obscured (Minimum). This is planned to be resolved by September 2025.
    • Within the application form, the toggle switch next to 'Additional cookies' within the cookie banner is not accessible using the keyboard. This fails WCAG 2.2 success criterion 2.1.1 Keyboard. This is planned to be resolved by September 2025.
    • Within the job application form the keyboard focus is not visible after tabbing from the start of the page from the URL for two keyboard tabs. This fails WCAG 2.2 success criterion 2.4.3 Focus Order. This is planned to be resolved by September 2025.
    • On the application form, the text entry boxes for 'personal statement' and 'flexible working' are not interactable with a screen reader. These boxes do not work after navigating to them using the tab key on keyboard. This fails WCAG 2.2 success criterion 2.1.1 Keyboard. This is planned to be resolved by September 2025.

    Colour contrast issues

    • The links for the 'cookies page' and 'hireful' within the cookie banner on the application form do not have sufficient colour contrast. This fails WCAG 2.2 success criterion 1.4.3 Contrast (minimum). This is planned to be resolved by September 2025.

    Link text issues

    There are issues with link text such as: non descriptive links being used for files/file names, social media links, and links in the cookie banner in the application form. This fails WCAG 2.2 success criterion 1.3.1 Info and Relationships. We are working to fix  descriptive link text issues by December 2024.

    There are also issues with some text links not showing any indication of focus – the cursor is not changing to the hand or arrow pointer (or any other symbol or indication) to show it is a clickable link. We are currently working with the third party organisation to resolve this by December 2024.

    On the jobs portal landing page, each job has link text which reads 'View job'. There is currently no way in the third party providers system to make this text unique to each vacancy. The third party provider is looking to update their system and this should be resolved by September 2025.

    Some links are underlined in the html using <u>Link</u>. This should be styled using CSS. We are currently working to resolve this issue with our third party provider by December 2024.

    Zoom issues

    At 400% zoom, the 'Select language' box and other page elements do not reflow to fit the webpage. This fails WCAG 2.2 success criterion 1.4.10 Reflow. This will be resolved by end of December 2024.

    Accessibility labels

    • Under 'how did you hear about this role?' on the application form some required ARIA attributes are not present such as aria-expanded and aria-controls. This fails WCAG 2.2 success criterion 4.1.2 Name, Role, Value. This is planned to be resolved by September 2025.
    • On the application form, some form fields are not labelled correctly or correctly associated to the form control and some of the options in the drop down menus are not read out by a screenreader. This fails WCAG 2.2 success criterion 1.3.1 Info and Relationships, 2.4.6 Headings and Labels and 3.3.2 Labels or Instructions. This is planned to be resolved by September 2025.
    • Some of the logos (specifically the ßÏßÏÊÓƵ logo on the application forms) used do not have meaningful alt-descriptions. This fails WCAG 2.2 success criterion 1.1.1 Non-text Content. This is planned to be fixed by September 2025.
    • The pages are lacking ARIA landmarks. This is planned to be fixed by September 2025.
    • When using a screen reader, it is reading out the chevrons used to divide links in the breadcrumb as text: 'greater than'. These should be elements coded correctly using ARIA. This fails WCAG 2.2 success criterion 1.3.1 Info and Relationships, 2.4.6 Headings and Labels and 3.3.2 Labels or Instructions. This is planned to be resolved by September 2025.

    • The search field does not have a properly associated label. This fails WCAG 2.2 success criterion 1.3.1 Info and Relationships, 2.4.6 Headings and Labels and 3.3.2 Labels or Instructions. This is planned to be resolved by December 2024.

    Header issues 

    Heading levels are not always being used and if they are, they are not in a logical order. Some pages have more than one H1 header. This fails WCAG 2.2 success criterion 1.3.1 Info and Relationships and 2.4.6 Headings and Labels. This is planned to be fixed by end of December 2024.

    Written content and language

    We are working to web best practice guidelines so that language is readable, perceivable and understandable. 

    The cookie banner is using a sentence in capital letters. There are also instances where different font sizes are being used on the job adverts. We are currently working to resolve this by December 2024.

    CV uploader tool

    The CV uploader does not always import information into the correct fields of the application form. This is planned to be fixed by end of December 2024.

    PDFs

    Some of the job description PDFs do not meet accessibility requirements. This is because of issues with header levels, colour contrast and images and logos not having alt-tags. We are currently working to make the PDF templates accessible. This is planned to be fixed by end of December 2024.

Sharepoint sites 

Our ßÏßÏÊÓƵ Projects Knowledge Hub (which uses Sharepoint) does not completely meet WCAG 2.1 and 2.2 accessibility standards. This system is provided by an external supplier. We are currently working to resolve these issues. You can find out more about the content which is not compliant with the accessibility regulations below.

  • Non-accessible content for the ßÏßÏÊÓƵ Projects Knowledge Hub (Sharepoint)

    ARIA labels: some elements have an aria-labelled by or aria-describedby value that does not match the ID attribute value of another element in the page. This fails WCAG 2.2 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value. We are working to resolve this by April 2025.

    Videos: some videos (particularly in the training section) do not have transcripts. This fails WCAG 2.2 1.2.1 Audio only and video only. We are working to add these by April 2025.

    Access key: Some of the pages have an accesskey attribute. An accesskey provides a way to define shortcut keys for web page elements but they can conflict with assistive technology. This fails WCAG 2.2 2.4.1 Bypass Blocks. We are working to resolve this by April 2025.

    Heading levels: There are no H1s on the pages. This does not meet WCAG 2.2 1.3.1 Info and Relationships. This is because of a hardcoded rule in the system itself. ARIA labels have been used to correctly tag H1 headers.

    Headers, paragraphs and written content: Some of the headings and paragraphs have been numbered. Some of these paragraphs are also spread across two columns rather than one single column. Some of the words used are also bolded. This fails WCAG 2.2 3.1.1 Language of Parts. We are working to resolve this by April 2025.

    Skip to main content: This link exists on every page but it fails to always link the user to the main content of the page. This fails WCAG 2.2 2.4.1 Bypass Blocks. We are working to resolve this by April 2025.

    Redundant title text: Some of the content (links, headers, buttons) have redundant title text in place. This can be difficult for people using assistive technology because link names are being read out more than once. We are working to resolve this by April 2025.

    Redundant links and link names: Some pages have adjacent links going to same location. There are also some links for things like files (PDF and Word Documents), which are not descriptive or include file size. This fails WCAG 2.2 2.4.4 Link Purpose. We are working to combine the redundant links into one link, remove any redundant text and ensure all links are descriptive by April 2025.

    Colour contrast: There are some instances where colour contrast does not meet the WCAG requirement. For example, grey text being used on the table within the Glossary. This fails WCAG 2.2 1.4.3 Contrast Minimum. We are working to resolve this by April 2025.

    Text on images: There is a large use of images depicting diagrams and other essential information. This fails WCAG 2.2 1.4.5 Images of text. We are working towards providing a text alternative for these images in the interim while we plan how to create these using semantic html.

    Menu list expanding on hover: Currently the menu opens upon hovering and is dismissed when focus is removed. This can be difficult for people to use. This only partially meets WCAG 2.2 1.4.13 Content on Hover or Focus. We looking to make the menu list appear upon click.

    Text spacing: The user is unable to increase text spacing. This fails WCAG 2.2 1.4.12 text spacing.

    Reflow: When zooming into the pages from 200% to 400%, some text does not reflow. This fails WCAG 2.2 1.4.10 Reflow.

    Focus indicator: This does not always meet colour contrast requirements or fulfil the criteria for pixels size. This makes it difficult for users using keyboard only to see where they are in the page. This fails WCAG 2.2 2.4.7 Focus Visible.

Documents

Many documents are in non-HTML formats, for example PDF. Some of these PDFs and other files may not be optimised for screen readers. Some of our PDFs and Word documents are essential to providing our services. For example, we have PDFs with information on how users can access our services, and forms published as Word documents. Some are pre-2018 and some are in the Archive. We plan to either fix post 2018 ones or replace them with accessible HTML pages. This is an ongoing process, we have created accessibility guides for staff and we are raising awareness across the University.

If you require access to a PDF that does not meet accessibility standards email web-accessibility@sussex.ac.uk and we will provide an accessible version to you.

Video

We are currently working to audit the video content on our site. We are currently focused on auditing our undergraduate content and hope to have this complete by Summer 2024.

Disproportionate Burden

We believe that fixing some of the accessibility issues found in our jobs portal would place a disproportionate burden on the University. We believe the cost and resources needed to fix the issues outweighs the benefits for users. We have therefore submitted a Disproportionate Burden Claim for the following issues related to our jobs portal. If granted, we are committed to resolving the issues either by December 2024 or September 2025.

  • On the jobs portal homepage the dropdown menus for 'Role type' and 'Department' cannot be accessed using the keyboard, there is also no mechanism to dismiss the additional content triggered without moving pointer hover or keyboard focus. This fails WCAG 2.2 success criterion 2.1. Keyboard Accessible and WCAG 1.4.13 Content on Hover or Focus. This is planned to be resolved by September 2025.
  • The keyboard tabs into the cookie banner at the bottom of the webpage after tabbing from the 'Skip to main content' option in the jobs portal. This does not follow a logical focus order for users. This fails WCAG 2.2 success criterion 2.4.3 Focus Order. This is planned to be fixed by end of December 2024.
  • Within the application form, the cookie banner obscures content on the page with focus moving behind it. The focus order is also not logical with the cookie banner receiving focus last. This fails WCAG 2.2 success criterion 2.4.3 Focus Order and 2.4.11: Focus Not Obscured (Minimum). This is planned to be resolved by September 2025.
  • Within the application form, the toggle switch next to 'Additional cookies' within the cookie banner is not accessible using the keyboard. This fails WCAG 2.2 success criterion 2.1.1 Keyboard. This is planned to be resolved by September 2025.
  • Within the job application form the keyboard focus is not visible after tabbing from the start of the page from the URL for two keyboard tabs. This fails WCAG 2.2 success criterion 2.4.3 Focus Order. This is planned to be resolved by September 2025.
  • The links for the 'cookies page' and 'hireful' within the cookie banner on the application form do not have sufficient colour contrast. This fails WCAG 2.2 success criterion 1.4.3 Contrast (minimum). This is planned to be resolved by September 2025.
  • At 400% zoom, the 'Select language' box and other page elements do not reflow to fit the webpage. This fails WCAG 2.2 success criterion 1.4.10 Reflow. This will be resolved by end of December 2024
  • Under 'how did you hear about this role?' on the application form some required ARIA attributes are not present such as aria-expanded and aria-controls. This fails WCAG 2.2 success criterion 4.1.2 Name, Role, Value. This is planned to be resolved by September 2025.

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

PDFs and other documents

Many of our older PDFs and Word documents do not meet accessibility standards – for example, they may not be structured so they’re accessible to a screen reader. This does not meet WCAG 2.2 success criterion 4.1.2 (name, role value).

The accessibility regulations  if they’re not essential to providing our services. For example, we do not plan to fix old pdfs which are in our .

Video and audio content

Video and audio content from before 23rd September 2020 is exempt from meeting these standards. We are doing our best to replace older video content and replace it with content that meets standards.

Live video

Live video streams do not have captions. This fails WCAG 2.2 success criterion 1.2.4 (captions - live).

We do not plan to add captions to live video streams because live video is .

Maps

Maps fall outside of current accessibility standards. Our university maps are not accessible by screen readers. All addresses highlighted on our maps are available elsewhere on the website. We are looking into an accessible solution to our maps.

What we're doing to improve accessibility

  • We are currently working on improving the accessibility of our core templates and our components library. We are training our devolved editors to use the new components and create accessible web content whilst raising awareness across the University on the importance of accessibility.  
  • We are training staff to create accessible documents, including PDF files, and produce video with appropriate captions, transcripts and audio descriptions where necessary. We have created how to guides to be used for training and the creation of content.
  • We have recently worked with  to audit our site and provide guidance on accessibility. We have updated this statement in accordance with their findings and are currently working through a series of fixes to the outstanding areas of non compliance. 
  • We are carrying out accessibility checks and audits for parts of the site on a continual basis and update this statement in accordance with our findings. Our testing methodology includes using tools such as AXE and WAVE Web Evaluation Tool. We also carry out manual checks using keyboard only, screenreaders, voice control, zoom test and colour contrast test. Find out more about what we use to test this site. Areas of the site are selected to be tested by assessing user need (popular pages), or if they are newly created (primarily new apps and systems). You can find out more about recent audits and our findings below.

Recent audits

See our recent audits below, the issues identified and the timescale for fixing them. 

  • ßÏßÏÊÓƵsport app and booking system

    We audited our ßÏßÏÊÓƵsport app and booking system in April 2024 and found it is only partially compliant with WCAG 2.2 because of some of the following top level issues. We are now working with a third party provider to address these issues.

    • Some elements do not have sufficient colour contrast. This fails WCAG 2.2 success criterion 1.4.3 Contrast (minimum).
    • Some page elements including buttons, links, tables and form fields do not have accessibility labels. This fails WCAG 2.2 success criterion 1.3.1: Info and Relationships.
    • Some images do not have alt descriptions. This fails WCAG 2.2 success criterion 1.1.1: Non-text Content. 
    • The app uses pop up boxes without the user interacting with an element and without warning. This fails WCAG 2.2 success criterion 3.2.2 On input. 
    • Videos do not have text alternatives such as captions and transcripts. This fails WCAG 2.2 success criterion 1.2.2: Captions (Prerecorded) and 1.2.8: Media Alternative (Prerecorded).
  • Campus and Brighton (self-guided) tour app

    We audited our self-guided tour app in May 2024 and found it is only partially compliant with WCAG 2.2 because of some of the following top level issues.

    • Some elements do not have sufficient colour contrast. This fails WCAG 2.2 success criterion 1.4.3 Contrast (minimum).
    • Some page elements including buttons, links, tables and form fields do not have accessibility labels, or if they do these are not unique which could be confusing for people using assistive technology. This fails WCAG 2.2 success criterion 1.3.1: Info and Relationships.
    • Some elements within the app do not receive focus. This fails WCAG 2.2 success criterion 2.4.13: Focus Appearance.
    • Headers are not used in the correct hierarchical order. This fails WCAG 2.2 success criterion 1.3.1: Info and Relationships.
    • Some of the button sizes do not meet sizing requirements. This fails WCAG 2.2 success criterion 2.5.8: Target Size (Minimum).
    • Some images do not have alt descriptions. This fails WCAG 2.2 success criterion 1.1.1: Non-text Content.
    • A map is being used that does not have a text alternative for screen readers. This fails WCAG 2.2 success criterion 1.2.8: Media Alternative (Prerecorded).
    • When being used on an iPad the display is only set to landscape orientation and the user has no option to change this. This fails WCAG 2.2 success criterion 1.3. 4 Orientation.

Preparation of this statement

This statement was prepared on 20 September 2019. It was reviewed on 26 June 2024 and will be updated regularly as we move forward with our actions and research.

This website was tested in-house in 2020 and had a further in-house audit in May 2022. It was audited by AbilityNet in July 2022 and reaudited by AbilityNet in March 2024.

Further information about our website

  • Finding your way around

    There are a variety of techniques you can use to navigate our site.

    You can use the top-level drop-down navigation and the site search, both of which give you access across our website and resources contained within. On most sections of the site you can use the page navigation (which appears to the left of this content) and the breadcrumb trail (which appears just above this content).

  • Text resizing and page zooming

    Most modern browsers support some form of built-in text resizing or page zooming. Changing the text size or zoom varies depending on the browser you are using.

    Resizing a page depends on the browser you are using:

    • PC / Internet Explorer 11

      From the 'Tools' cog icon in the top right corner, select 'Zoom' and then choose your setting

    • PC / other browsers

      Hold down the CTRL key and press + to increase the text/zoom
      Hold down the CTRL key and press - to decrease the text/zoom

    • Mac / all browsers

      Hold down the Command key and press + to increase the text/zoom
      Hold down the Command key and press - to decrease the text/zoom

  • Known browser support for the site

    Our site supports:

    • Internet Explorer 11 and above
    • Firefox – latest version
    • Safari – latest version
    • Chrome – latest version
  • Get advice

    Refer to the following websites to get information relating to accessibility matters such as how to adjust your browser, computer, keyboard and mouse settings to suit your individual needs

  • How accessible is this website?

    The website has been developed following guidelines which are aimed at achieving a good level of accessibility – we endeavour to meet with .

    We have taken the following accessibility and usability guidelines into consideration when developing the site:

    • providing simple, consistent operable site navigation.
    • providing easy to percieve and understand content.
    • using style sheets for visual layout, the content can still be read with style sheets turned off or with a different style applied by your own browser set-up.
    • using an easy-to-read font type.
    • endeavouring to provide suitable foreground and background colour contrast.
    • providing text equivalents for images, where appropriate.
    • using semantic HTML to improve readability by screen readers.
    • ensuring javascript degrades gracefully, so content is accessible without javascript wherever possible.
    • using accessible alternatives where necessary to ensure the website is robust - such as with the modified html version of the virtual campus tour.
  • Staff training

    We have delivered training on accessibility to a number of our devolved web editors. This is an ongoing task.

    We have developed our accessible web components library and are in the process of training all web editors to use these.

    We have develped a series of "How to" pages for creating accessible documents and are currently preparing to deliver a series of training sessions for all staff who produce online documents.

  • How we tested this website

    This website is tested for accessibility whenever we develop new web conponents. We also crawl the site regularly to find issues such as where images without alt tags are located. Tests are carried out with users and via automated software.

    We have tested the website using the following methods so far:

    • colour contrast checker
    • web accessibility evaluation tool
    • VoiceOver, ChromeVox and NVDA screen readers for desktop
    • Chrome plugin to simulate colour blindness, tunnel vision and myopia
    • extension for Chrome

    The pages the components library cover and the ones we have tested are:

    How we tested PDFs:

    • All PDFs are tested for accessibility using
    • All PDFs are checked for colour contrast using
    • Some advice from on making documents more accessible
  • What else are we doing to improve accessibility

    We have set up an accessibility working group which will oversee digital accessibility improvements. The group will form part of wider accessibility group within the University. 

    Members of our development team have taken training courses provided by W3 and WebAIM to enable them to provide a more accessible experience for our visitors.