This accessibility statement applies to the Echo360 platform as used by King’s College London, encompassing its web interface, multimedia content delivery, and interactive features. This includes all aspects of the application accessible to students, faculty, and staff for educational purposes.

Echo360 is a third-party application.

Echo360 is provided by Echo360 to King’s College London to provide lecture capture tool for video capture in classroom across King’s. It serves as a comprehensive platform for digital learning and classroom engagement, offering tools for video hosting, lecture capture, and analytics. This application is integral for supporting remote and hybrid learning models, enabling students and educators to access course materials, participate in classes, and collaborate effectively, regardless of their physical location.

Echo360 Lecture Capture organisational launch date September 2016

Using the application

We want as many people as possible to be able to use, read and understand the content of Echo360

This means that you should be able to:

• change colours, contrast levels and fonts;
• zoom in up to 300% without the text spilling off the screen;
• navigate the application using just a keyboard;
• navigate the application using speech recognition software;
• listen to most of the application using a screen reader.

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

How accessible this application is

We know some parts of Echo360 are not fully accessible:

Echo360 Accessibility Overview - Key Points for Users:

• Partial Support for Accessibility Features: Echo360 has made efforts in supporting accessibility, but there are significant areas needing improvement.
• Buttons and images often lack descriptive names or alternative text, making them difficult to understand for screen reader users.
• The application's structure, including form controls, labels, and dialog titles, is not always clear or accessible programmatically.
• Generally adequate for conveying information, but relies solely on colour for some error messages, which may not be distinguishable for colour-blind users.
• Problems with text resizing, reflow, non-text contrast, and language indication.
• Challenges with focus management and accessing interactive content using a keyboard.
• Some content that moves or updates cannot be paused or hidden, potentially causing distractions or discomfort.
• Occasional content flashes more than three times per second, which can be problematic for users with photosensitive epilepsy.
• Lack of skip links and non-unique or descriptive page titles, making navigation harder.
• Users might find the logical order of focus and content updates confusing.
• Screen reader users may not receive important status messages.
• Some elements lack proper ARIA (Accessible Rich Internet Applications) attributes or have invalid values. This technical issue means that the application might not communicate effectively with assistive technologies, impacting user experience.

Note to Users: This list highlights where Echo360's accessibility stands in relation to standard requirements. The aim is to inform you about potential accessibility barriers you might encounter, saving you time and effort. More technical details on non-compliance with WCAG (Web Content Accessibility Guidelines) are available further in the document.

For more detailed information the accessibility of Echo360 lecture capture, see the Voluntary Product Template (VPAT) dated March 2022 on the Accessibility Conformance Report webpage (Accessed 6^th of Dec 2023, 16:00).

Feedback and contact information

If you find any problems not listed in this statement or think we’re not meeting accessibility requirements, email diversity@kcl.ac.uk.

If you need information on this application in a different format like accessible PDF, large print, easy read, audio recording or braille, email diversity@kcl.ac.uk.

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

If you need to escalate your issue further, contact Lorraine Kelly, Director of Culture and Talent, via diversity@kcl.ac.uk. You can expect an acknowledgement of your issue within 7 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 this application’s accessibility

King’s College London is committed to making this application accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Compliance status

This application is partially compliant with the Web Content Accessibility Guidelines version 2.2 AA standard, due to the following non-compliances listed below.

Non-accessible content

Echo360 is provided by a third-party supplier which means that some aspects of accessibility are outside our immediate control.

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

Non-compliance with the accessibility regulations

In an Audit performed by King’s College London in November 2023, the following features have been flagged as non-compliant:

• 1.1 Non-Text Content: Buttons and images often lack descriptive names or alternative text, making them difficult to understand for screen reader users.
• 3.1 Info and relationships: ​The application's structure, including form controls, labels, and dialog titles, is not always clear or accessible programmatically.
• 4.1 Use of colour: ​Generally adequate for conveying information, but relies solely on colour for some error messages, which may not be distinguishable for colour-blind users.
• 4.4 Resize text: Problems with text resizing, reflow, non-text contrast, and language indication.
• 4.13 Content on hover or focus: ​Challenges with focus management and accessing interactive content using a keyboard.
• 3.1 Three flashes or below threshold: ​Some content that moves or updates cannot be paused or hidden, potentially causing distractions or discomfort.​Occasional content flashes more than three times per second, which can be problematic for users with photosensitive epilepsy.
• 1.3 Status Messages: Screen reader users may not receive important status messages.
• 1.2 Name, role, value: Some elements lack proper ARIA (Accessible Rich Internet Applications) attributes or have invalid values. This technical issue means that the application might not communicate effectively with assistive technologies, impacting user experience.

​In addition to these features that were found as non-compliant in our audit, Echo360 mentions the following list of features as ‘Partially Supports’ or ‘Doesn’t Support’. While not found in our audit, they may still appear for certain users:

Does not support

• 3.1. Three Flashes or Below Threshold

Web: The product contains content that flashes more than three times a second.

• 4.1. Bypass Blocks

Web: The product does not provide skip links and other mechanisms to bypass blocks of content that are on multiple Web pages.

Partially supports

• 1.1. Non-text Content

Web: Some non-text content in the product presented to the user has a text alternative that serves the equivalent purpose.

Exceptions include:

• • Some buttons do not provide a descriptive accessible name.
  • Several images do not provide meaningful alterative text.
  • The "Video" elements do not provide an accessible name.
  • Several controls do not provide name, state, and role information.
  • Some accordion controls do not provide role information. Custom comboboxes do not provide role and state information.

• 3.1. Info and Relationships

Web: The product does not always ensure that information, structure, and relationships conveyed through presentation can also be determined programmatically or through text.

Examples include:

• • Some form controls do not provide grouping information.
  • Several form elements do not provide programmatically associated labels.
  • Some dialogs do not provide a descriptive title.
  • Dynamically updated information is not being conveyed to assistive technologies in several instances.
  • Some list elements are not implemented correctly.
  • The layout tables do not indicate their use for presentation purposes.
  • In several instances, the headings do not match their visual importance.
  • Some inline error messages are not programmatically associated with the input fields.
  • In some instances, the dialog boundaries are not being communicated to assistive technologies.
  • Some data tables contain empty header cells.
  • Some data tables do not use table markup.
  • In several instances, the focus does not move to the updated content.
  • Some headings are implicit.

• 4.1. Use of Color

Web: Most of the elements in the product do not use color as the only visual means of conveying information.

Exceptions include:

• • In rare instances, the error messages are conveyed using color alone.
  • Tabs do not provide valid state information.

• 2.1.1. Keyboard

Web: Some interactive content within the product is accessible from the keyboard.

Exceptions include:

• • Some scrollable content is not accessible via the keyboard.
  • Several custom controls do not receive focus via the keyboard.
  • Several custom controls are not accessible via keyboard.
  • In some instances, the inactive elements receive the focus.

• 2.1.2. No Keyboard Trap

Web: Where keyboard focus can be moved to a component the product mostly allows the focus to be moved away using only a keyboard interface.

Exceptions include:

• • In some instances, the focus gets trapped and users cannot move the focus out of the element/region.

• 2.2.2. Pause, Stop, Hide

Web: The allows users to pause, stop, or hide moving, blinking, scrolling, and auto-updating information in most instances.

Exceptions include:

• • Some dynamic contents cannot be stopped, paused, or hidden.

• 2.4.2. Page Titled

Web: The product mostly provides a suitable title for each page.

Exceptions include:

• • In some instances, the pages do not provide unique/descriptive page titles.
  • Some dialogs do not provide a descriptive title.

• 2.4.3. Focus Order

Web: The product can mostly be navigated sequentially in a focus order which matches the logical reading order.

Exceptions include:

• • The focus order of some elements in the product is not logical.
  • The focus does not move to the dialog when it opens.
  • In some instances, the focus does not remain with the
  • In several instances, the focus does not move to the updated content.

• 2.4.4. Link Purpose (In Context)

Web: The product contains some links whose purpose can be determined from the link text alone or from the link text together with its programmatically determined link context.

Exceptions include:

• • Several links in the do not provide meaningful link text.

• 2.5.3. Label in Name

Web: The product mostly ensures that when the user interface components with labels that include text or images of text, the accessible name contains the text presented visually.

Exceptions include:

• • Several form elements do not provide programmatically associated labels.
  • For some elements, the programmatic labels do not match with the visible text label.

• 3.2.2. On Input

Web: In most cases, the product does not initiate a change in context when the setting of a user interface component is changed.

Exceptions include:

• • The focus moves to the top of the page when a user changes the value for the lesson dropdown.

• 3.3.1. Error Identification

Web: In most cases, the product does not initiate a change in context when the setting of a user interface component is changed.

Exceptions include:

• • The focus moves to the top of the page when a user changes the value for the lesson dropdown.

• 3.3.2. Labels or Instructions

Web: The product provides programmatically identifiable labels and instructions for most user input fields.

Exceptions include:

• • Some inline error messages are not programmatically associated with the input fields.
  • Some form controls do not provide grouping information.

• 4.1.1. Parsing

Web: The product uses HTML and ARIA, which is mostly compliant with the relevant specifications.

Exceptions include:

• • Several ID attributes in the product do not contain unique values.
  • Some attributes do not contain valid values.
  • Some elements in the product are incorrectly nested.

• 4.1.2. Name, Role, Value

Web: The product mostly consists of user interface components which indicate their name, role, and values programmatically.

Exceptions include:

• • Several images do not provide meaningful alternative text.
  • Several form elements do not provide programmatically associated labels.
  • Tabs do not provide valid state information.
  • Some error messages disappear when the user navigates to a different control.
  • Some inline error messages are not programmatically associated with the input fields. The "Video" elements do not provide an accessible name.
  • In some instances, the dialog boundaries are not being communicated to assistive technologies.
  • Some buttons do not provide a descriptive accessible name.
  • Several controls do not provide name, state, and role information.
  • Some accordion controls do not provide role information.
  • Custom comboboxes do not provide role and state information.
  • The grid tables do not provide an accessible name.
  • Several media player controls do not provide valid role and/or state information.
  • Some elements contain invalid ARIA attributes.

• 1.4.3. Contrast (Minimum)

Web: The product provides sufficient contrast between most text and backgrounds.

Exceptions include:

• • Several elements in the product do not meet the color contrast requirement.

• 1.4.4. Resize Text

Web: The product allows text to be resized without assistive technology up to 200 percent without loss of content or functionality for most of the site.

Exceptions include:

• • Some content cutoffs when the user increases the browser zoom to 200%.

• 1.4.10. Reflow

Web: The product mostly allows for content to be presented without loss of information or functionality, and without requiring scrolling in two dimensions.

Exceptions include:

• • Some content is not available when the horizontal width is 320 CSS pixels/vertical height is 256 CSS pixels.

• 1.4.11. Non-text Contrast

Web: The visual presentation of non-text content has a contrast ratio of at least in most instances. Exceptions include:

• • Some elements do not provide sufficient color contrast and do not meet the requirement.

• 2.4.6. Headings and Labels

Web: The product uses headings and labels that their topic or purpose in most instances.

Exceptions include:

• • Some controls do not provide descriptive labels.
  • Headings are not descriptive in some instances.

• 2.4.7. Focus Visible

Web: The provides a visible indication of keyboard focus for most elements on pages.

Exceptions include:

• • Some elements do not provide a visual indication of keyboard focus when it receives the focus.

• 3.1.2. Language of Parts

Web: The product indicates the human language and programmatically indicates parts that are in a different human language in some instances.

Exceptions include:

• • For some elements, changes in the language cannot be determined programmatically.

• 4.1.3. Status Messages

Web: When most status messages in the product do not receive focus, they can be programmatically determined through role or properties and are presented to users of assistive technology without receiving focus.

Exceptions include:

• • Some status messages are not being conveyed to the screen reader users.

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 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 are doing to improve accessibility

King’s College London are working with Echo360 to fix or provide alternatives for all issues that are we are made aware of or are identified by our internal testing and auditing processes.

• Regular Audits and Reviews: Conducting periodic accessibility audits of Echo360 to identify any new or unresolved issues. This includes both automated testing and manual reviews to ensure a comprehensive understanding of the accessibility challenges faced by users.
• Collaborative Problem-Solving: Engaging in a collaborative process with Echo360, where we discuss potential solutions and timelines for addressing the identified issues. This partnership aims to ensure that improvements are made in a timely and effective manner.
• Implementing Alternatives: Where immediate resolution is not possible, we are committed to providing alternative ways to access the content or functionality that is not fully accessible. This ensures that all users have equal access to the educational resources available on Echo360.
• Training and Awareness: Increasing awareness and training among our staff and faculty on the importance of digital accessibility. This includes understanding how to create and disseminate accessible content and how to use Echo360's features to their fullest potential in an accessible manner.
• Feedback Mechanism: Encouraging feedback from users regarding accessibility issues. This feedback is invaluable in identifying areas that need improvement and in assessing the effectiveness of the changes we implement.
• Updating Our Accessibility Statement: Regularly updating this accessibility statement to reflect the changes and improvements made, as well as to provide a transparent account of our ongoing efforts to improve accessibility.
• Echo 360 closed captions (ASR) and transcription are now enabled to automatically create machine generated transcripts for any captures published to a course.

Through these measures, King’s College London is committed to continually enhancing the accessibility of Echo360, ensuring that all students and faculty have equal access to its educational benefits.

Preparation of this accessibility statement

This statement was prepared on 12^th of February 2021. It was last reviewed on 7^th of December 2023.

This application was last tested on 10^th of November 2023.

The test was carried out by King’s College London Education Applications team in Information Technology. The test was carried using SiteImprove accessibility checker.

We tested:

• King’s Lecture Capture service: org.uk