Skip to main content

Accessibility statement for King’s College London website

This accessibility statement applies to the King's College London website (www.kcl.ac.uk).

Please note: the content of this document is limited to the main corporate website hosted on the Contensis CMS platform and accessed via www.kcl.ac.uk. Other websites and portals have their own accessibility statements.

Using this website

This website is run by King’s College London and we want as many people as possible to be able to use, read and understand its content.

This means that on pages in the new templates you should be able to:

  • Zoom in up to 300% without the text spilling off the screen
  • Set the font size and preference within your browser (except for section headings)
  • Navigate most of the website using just a keyboard
  • Skip to main content using keyboard navigation
  • Navigate most of the website using speech recognition software
  • Listen to most of the website using a screen reader.

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 the King's College London website are not fully accessible.

The website includes three different website templates. This means that some pages are not as accessible as others. The lists below show the different types of pages and the ones that may not be fully accessible to website users.

Legacy pages (created before September 2019)

These pages are being rebuilt and this work will be completed by December 2026. These pages are not yet compliant with accessibility regulations and users may have issues accessing them. These pages include:

Current pages (pages built with the latest template)

These pages are being updated to implement a new styling and to ensure these pages comply with the accessibility regulations. This work will be completed by August 2025. Users may have issues accessing some of these pages. These pages include:

New pages

All new pages are WCAG 2.2 compliant and therefore should be accessible to users.

Feedback and contact information 

Please email diversity@kcl.ac.uk if:

  • You find any problems not listed in this statement or think we’re not meeting accessibility requirements, or
  • You need information on this website in a different format like accessible PDF, large print, easy read, audio recording or braille

We will consider your request and get back to you in seven days.

If you need to escalate your issue further, contact the Director of Culture & Talent via diversity@kcl.ac.uk.

You can expect an acknowledgement of your issue within seven days and a full reply within 14 days. If your complaint raises complex issues that cannot be answered within 14 days, we will keep you informed of progress until we can fully respond.

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 the website accessibility

King’s College London 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 below.

Non-accessible content

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

Non-compliance with the accessibility regulations

The number of pages impacted by these issues and the WCAG criteria they relate to are included below. Issues of accessibility identified are being addressed through coding updates or training for content editors.

Focus order (2.4.3)

In the legacy codebase, including the homepage and faculties, if the user has zoomed the page above 200% and activates the menu, the focus order fails to take the open menu into account and is "trapped" inside the page.

Not clear which page element has focus from the keyboard – 768 pages (2.4.7)

Some internet users are physically unable to use a mouse; others may find it easier to navigate with a keyboard or keyboard alternative.Focus indicators help keyboard users tell which item on a page is receiving input from the keyboard. It appears as a visual marker — like an outline or a highlight — that moves with the keyboard focus. This means that some carousels, for example on the homepage, have elements that don't show a focus with keyboard.

Role with implied hidden content has keyboard focus – 2 pages (1.3.1, 4.1.2)

Screen readers will ignore any content with a presentation role. If this includes focusable sub-elements, these will not be announced to the user, who might miss out on important information.  An example is the homepage carousel where the mobile and desktop views are conflicting causing users with screen readers and keyboard navigators to incorrectly focus on them.

Images missing text alternative – 46 pages (WCAG 1.1.1)

This means that some images have not got the alternative descriptions correctly added meaning screen readers are unable to relay the information to users. 

Empty headings – 387 pages (1.3.1)

A heading is considered "empty" if there is no text for a screen reader to relay to the user.

No data cells assigned to table header – 73 pages (1.3.1)

In certain page templates, users can create tables to show tabular data. Users should merge cells to avoid empty headings.While sighted visitors may be able to use visual cues to scan tables for information, people using screen readers can only do this if cells and headers are marked up correctly in the code. Many of these issues are caused by a legacy calendar plugin on events pages. This code is being phased out to remove the issue.

Container element is empty – 2,475 pages (1.3.1)

Some legacy elements, such as the accommodation pages, use buttons to sort the lists. These have not been correctly coded, which means screen readers are unable to relay context to the user.

Role not inside the required context – 1,590 pages (1.3.1)

Some legacy elements, such as accommodation pages, use buttons to sort the lists. These have not been correctly coded, which means screen readers are unable to relay context to the user.

Hidden element has focusable content – 5 pages (1.3.1, 4.1.2)

Content has been set to 'hidden' to hide from screen readers but is still available via focus order, which means users of pages with legacy carousels, such as the homepage, are confused by links they are unable to see or hear.

Table cell missing context – 4 pages (1.3.1)

Some tables added by users have cells incorrectly labelled for content or headings, which will result in a confusing experience for users who are unable to make a visual association between the cells.

Contrast ratio between text and background – 7,557 pages (1.4.3)

Colour contrast on text to background is not sufficient for users with sight impairments to view the content.

Colour contrast does not meet minimum requirement – 9,268 pages (1.4.3)

Colour contrast on text to background is not sufficient for users with sight impairments to view the content.

Text is clipped when resized – 323 pages (1.4.4)

Visitors with low vision may not be able to access information if text is clipped (cut off) when scaled up to 200% or higher.

Scrollable element is not keyboard accessible – 459 pages (2.1.1)

This relates to some scrollable controls such as "quick links" that are not accessible to users without a mouse to navigate.

Links in the same context going to the same page 3,332 pages (2.4.4)

If two or more links on a page have the same link text but go to different locations, this can be a problem for users who are unable to see the visual context of the link.

Link missing in alternative text – 839 pages (2.4.4, 2.4.9, 4.1.2)

Links should always have a text alternative in order to support users who are blind or have low vision accessing the content.

Visible label and accessible name do not match – 4 pages (2.5.3)

The accessible name of any interactive element should contain its visible text label. Using two different names for a single page element can create a confusing user experience for assistive technology users.

Interactive element does not meet minimum size or spacing – 171 pages (2.5.8)

Interactive elements, like buttons or links, should be large enough or be positioned so they can easily be clicked or tapped by users. This error could mean that some users may be unable to select specific content as there isn't enough space around them.

Inline frame missing a text alternative – 38 pages (4.1.2)

Inline or iframes should have a title that summarises the visual content to help screen reader users understand the frame's purpose on the page.

Button missing a text alternative – 64 pages (4.1.2)

Buttons should have a text label to support visitors using assistive technology understand the role the button performs.

Form field missing a label – 101 pages (4.1.2)

Every form element should have a descriptive text label. A label may already be visible on the page but to be accessible, that label needs to be associated with the form element in the HTML. This helps visitors using screen readers to understand what information is required, while also making it easier for speech-input users to control the form element.  King's uses a lot of third party forms that require the university to speak to the vendor to upgrade their package or move away to a new service.

Inline frames not identical – 174 pages (4.1.2)

If there are two or more inline frames or iframes added to a page, they should all have unique descriptions to help users understand the content if they are unable to visually identify this. A number of iframes, such as embedded video, may have the same generic title, which needs localising to the content.

Disproportionate burden

At this time, we have not made any disproportionate burden claims.

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

PDFs and other documents

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 PDFs or Word documents that are essential to providing our services are being checked to ensure they meet accessibility regulations. Any new PDFs or Word documents we publish will meet accessibility standards.

Live video

We do not 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

King’s College London is committed to fixing or providing alternatives for all issues that we are made aware of or are identified by our internal testing and auditing processes.

Activities to improve the accessibility of this website are as follows:

  • Legacy pages are being rebuilt to meet accessibility requirements – this work will be completed by December 2026.
  • Current pages are being updated to implement a new styling and meet accessibility regulations – this work will be completed by the August 2025.
  • All new web templates are being fully tested to ensure they are compliant.
  • All web editors have access to a tool that scans all pages on the site and reports on accessibility to allow users to identify and correct errors.
  • All web editors have access to free online training, a content editors toolkit, and new training is being developed to ensure all website editors meet accessibility standards.
  • Comprehensive guidance on creating accessible content has been created and disseminated to all content creators.

Preparation of this accessibility statement

This statement was prepared on 3 September 2019. It was last reviewed on 8 July 2024.

This website was last tested on 26 June 2024 against WCAG 2.2 AA standard.

The test was carried out by King's IT directorate using the Siteimprove accessibility checker, Lighthouse, BrowserStack accessibility, and local tools such as operating system accessibility tools.

We tested:

  • Siteimprove is a scanning tool so will scan all pages under the domain it can find. The report is then filtered by URL to departments and faculties. Individual templates and elements are tested by the development team during build or editing.

 

 

Contact Equality, Diversity and Inclusion

For more information or assistance, please contact Equality, Diversity & Inclusion via our email address or our enquiry form.