This website is run by City, University of London. We want as many people as possible to be able to use this website. For example, that means you should be able to:
- change colours, contrast levels and fonts
- zoom 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 most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)
We’ve also made the website text 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:
- Embedded videos do not have captions or audio description.
- PDFs do not meet accessibility standards.
- Embedded third-party widgets do not meet accessibility standards.
What to do if you can’t access parts of this website
If you need information on this website in a different format like accessible PDF, large print, easy read, audio recording or braille, please raise a request with the IT Service Desk.
We’ll consider your request and get back to you in 3-5 working days.
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 the Web Development team via the IT Service Desk.
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
City, University of London is committed to making its website accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
This website is partially compliant with the Web Content Accessibility Guidelines version 2.1 AA standard, due to the non-compliances listed below.
The content listed below is non-accessible for the following reasons.
Non-compliance with the accessibility regulations
- Embedded videos, for example the IT induction video, do not have captions or audio description. This fails WCAG success criteria 1.2.2 (captions (prerecorded)) and 1.2.5 (audio description (prerecorded)).
- PDFs published since 23 September 2018 do not meet accessibility standards.
- Embedded third-party widgets do not meet accessibility standards. We are in the process of removing them.
- Some elements of embedded online forms have insufficient colour contrast. This fails WCAG 2.1 success criterion 1.4.3 (contrast (minimum)).
“AdviseABot” by Gecko Labs Limited
The GeckoEngage software is used on our student adviser page. GeckoEngage fails to comply with WCAG 2.1 in at least the following ways:
- The relationship between the button to open the live chat window and the live chat window itself cannot be programmatically determined. This fails WCAG success criterion 1.3.1 (info and relationships).
- Navigating messages in the live chat window with keyboard after sending a message takes the user through the response in reverse order. This fails WCAG success criteria 1.3.2 (meaningful sequence) and 2.4.3 (focus order)
- Controls such as the close button on small screens have no meaningful text or label explaining their purpose. This fails WCAG success criterion 2.4.6 (headings and labels).
- There are focusable elements in the GeckoEngage widget that do not have a visible focus state. This fails WCAG success criterion 2.4.7 (focus visible).
- The software offers no instructions to users of assistive technologies on how to interact with it, and that interaction is non-standard and not intuitive. This fails WCAG success criterion 3.3.2 (labels or instructions).
- Controls such as the close button on small screens are not implemented as appropriate elements, nor do they have ARIA roles indicating their purpose, so assistive technologies such as screen readers cannot interact with them properly. This fails WCAG success criterion 4.1.2 (name, role, value).
- Responses from the bot are not announced by screen readers, nor is there is any way to quickly access the response. This fails WCAG success criterion 4.1.3 (status messages).
- The text of some elements have insufficient colour contrast with their background, and some elements have insufficient colour contrast with adjacent elements. This fails WCAG 2.1 success criterion 1.4.3 (contrast (minimum)) and 1.4.11 (non-text contrast).
We have given feedback on these issues to the vendor and requested that they provide a road map for fixing them.
Content that’s not within the scope of the accessibility regulations
PDFs and other documents
Many of our older PDFs 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.1 success criterion 4.1.2 (name, role, value).
Some of our PDFs are essential to providing our services. For example, we have PDFs with information on how users can access our services. By September 2020, we plan to either fix these or replace them with accessible HTML pages.
The accessibility regulations do not require us to fix PDFs or other documents published before 23 September 2018 if they’re not essential to providing our services.
Any new PDFs we publish will meet accessibility standards.
How we tested this website
This website was last tested on 18th September 2019 by the Web Development team at City.
The team incorporate the WCAG 2.1 AA standard into every stage of development when designing and building new pages. We employ two qualified, full-time user experience professionals, who advise on usability best practice and conduct expert reviews and accessibility tests on every new page template. We test pages macOS, Windows, iOS and Android, with and without screen reader software.
We run user testing sessions online and in-person at the City Interaction Lab.
We subject every page of the Student Hub to automated testing with the axe accessibility checker, and we fixed every issue it identified in code we control.
We use site governance software to track accessibility issues across every page of the site.
What we’re doing to improve accessibility
We are in the process of removing non-compliant third-party widgets.
City is working with third-party providers to improve the accessibility of embedded content displayed on this website.
We are currently looking at some of the other platforms used for teaching and learning such as lecture capture (Echo360), video (Kaltura Mediaspace) and polling (PollEverywhere) – links will be shown on the list to the left.
We have also set up a working group – the Digital Accessibility Working group (DAWG) which has met in Feb 2020 and will meet monthly.
This statement was prepared on . It was last updated on .