XClose

Accessibility

Menu

Studiosity accessibility statement

This accessibility statement applies to Studiosity.

The Studiosity services are run by Studiosity. We want as many people as possible to be able to use this website and service, which means that you should be able to:

  • change colours, contrast levels and fonts
  • zoom in up to 200% 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

There are a number of customisation options for your browser and device that could help you use this website and other websites more effectively. AbilityNet has advice on making your device easier to use if you have a disability.

Feedback and contact information

Please contact us if you have an accessibility query including:

  • If you are experiencing issues with accessing information or using the website
  • If you find an accessibility problem not listed on this statement
  • If you have positive feedback on the accessibility considerations made. 

When you contact us there is a process in place that will acknowledge your contact, tell you who is dealing with it and give you a timescale by which you can expect a reply:

The IT (Information Technology) Services Service desk aims to respond to emails within one business day.

Reporting accessibility problems with this website

We formally test the accessibility of key user journeys that represent the breadth of content across our website on a regular basis against WCAG 2.2 AA standards. 

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, please contact us:

Read tips on contacting organisations about inaccessible websites.

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

University College London is committed to making this 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 (WCAG) 2.2 AA standards, due to the non-compliances and exemptions listed below.

Non-accessible content

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

Non-compliance with the accessibility regulations

Site-wide

There is no function to skip navigation menus. This fails WCAG 2.4.1 Bypass Blocks (A).

The contrast on keyboard-focused link text against the footer background is very low; if you hover over a link in the footer, it becomes virtually invisible. This fails WCAG 1.4.3 Contrast (Minimum) (AA).

WCAG requires a contrast ratio of 3:1 or higher for non-text contrast. The logo with a green/yellow “B” on a white circle has a contrast ratio of 1.3:1. This fails WCAG 1.4.11 Non-text Contrast (AA).

When the floating chatbot toggle button (lime green circle) is floating over a lime triangle at the right-hand side of the page, the button is too low in contrast to be distinguishable from the triangle. This fails WCAG 1.4.11 Non-text Contrast (AA).

Across all pages, headings are not consistent and may not begin at H1. This fails WCAG 1.3.1 Info and Relationships (A).

For some pages there is no language set. For others it is set as html lang=”en-AU”. This fails WCAG 3.1.1 Language of Page (A).

Login page

Screen readers correctly identify the progress indicator/progress bar, but they read the progress as “indeterminate”. This fails WCAG 1.1.1 Non-text Content (A).

The button with a lime green "M" in a white circle with shadow at the top right of the page does not have good keyboard focus visibility. The focus indicator around some buttons is low in contrast (for those with a dark blue border for focus on a dark grey button). This fails WCAG 2.4.7 Focus Visible (AA).

The confirmation page reached after logging in does not immediately trap the keyboard focus in the “Welcome” modal, and so keyboard focus remains on the page underneath until the modal is reached, at which point it becomes a closed loop as it should be. The same again occurs for the “About you” and “Before you start” modals. This fails WCAG 2.4.11 Focus Not Obscured (Minimum) (AA).

In modals with a back button, the button is not labelled. This fails WCAG 1.3.1 Info and Relationships (A).

The “Done” buttons in modals cannot be reached by keyboard navigation. This fails WCAG 2.1.1 Keyboard (A).

There is also no visible keyboard focus indicator on any interactive elements in the modals. This fails WCAG 2.4.7 Focus Visible (AA).

Many modals contain images without alt text, which are not marked as decorative when they should be. This fails WCAG 1.1.1 Non-text Content (A).

Modal items are skipped by keyboard when a tour is in progress, e.g. “Skip tour” cannot be reached by keyboard. This fails WCAG 2.1.1 Keyboard (A).

Home page

Text such as “feedback” in the tiles on the dashboard are potentially low in contrast depending on how it is rendered on different browsers/operating systems. It is flagged as low in contrast on a Windows computer but not on a MacOS computer. This fails WCAG 1.4.3 Contrast (Minimum) (AA).

Error messages are only communicated visually and there is no non-visual alternative. This fails WCAG 3.3.1 Error Identification (A).

The checkmarks to e.g. “Sign up for Studiosity and log in” are low contrast when checked (white tick on a lime green circle). This fails WCAG 1.4.3 Contrast (Minimum) (A).

The checkmarks are graphics, and are not described as checked or unchecked in a non-visual way. This fails WCAG 1.1.1 Non-text Content (A).

The progress bar in the bottom-left of the screen is not labelled. This fails WCAG 4.1.2 Name, Role, Value (A) and WCAG 1.3.1 Info and Relationships (A).

The navigation links "Home" and "My recent activity" are listed as a list of two items, but only one ("My recent activity") can be navigated to by keyboard. If the "Home" link is inactive because the Home page is currently loaded in the browser, this is not communicated to the user. This fails WCAG 2.1.1 Keyboard (A).

The social media icons in the footer are smaller than the minimum requirements, at 14x14 pixels. This fails WCAG 2.5.8 Target Size (Minimum) (AA).

The social media icons in the footer also change colour when focused by keyboard, which makes them low in contrast (although contrast is good when unfocused). This fails WCAG 1.4.3 Contrast (Minimum) (A).

Some links visually appear to be buttons but are still marked up as links, and other identical elements are correctly marked up as buttons. This fails WCAG 3.2.4 Consistent Identification (AA).

Some links are missing sufficient descriptive link text to be clear of their purpose non-visually. This fails WCAG 2.4.4 Link Purpose (In Context) (A).

My Recent Activity page

The “Filter Submissions” search field contains placeholder text which is used as the visual label but is lost when the user begins typing. This fails WCAG 3.3.2 Labels or Instructions (A).

Intercom Messenger Chat function

Once the chat modal is expanded, it is possible to navigate beyond it to the site behind but the modal does not collapse when no longer receiving focus, so it obscures active navigation. This fails WCAG 2.4.11 Focus Not Obscured (Minimum) (AA).

Link text is low in contrast (ratio 2:1). This fails WCAG 1.4.3 Contrast (Minimum) (AA).

Some link text is also non-descriptive (e.g. "here"). This fails WCAG 2.4.4 Link Purpose (In Context) (A).

The emojis (marked up as radio buttons) used to respond to "Did this answer your question?" are not easily navigable by screen readers, as the instructions given do not match the actual requirements for navigation (e.g. arrow vs. tab keys). This fails WCAG 1.3.1 Info and Relationships (A).

Download and social media links

The icons for downloading the app for iOS and Android devices have unclear or explicitly unhelpful alt/link text. This fails WCAG 2.4.4 Link Purpose (In Context) (A).

The social media icons do not have clear alt/link text either. This fails WCAG 2.4.4 Link Purpose (In Context) (A).

Android application

The sign in button is unhelpfully labelled. There are no spaces in the button name so it reads as one long word by screen reader. This fails WCAG 4.1.2 Name, Role, Value (A).

Some links are read as text and not marked up as links. This fails WCAG 1.3.1 Info and Relationships (A).

Authorisation of mobile applications

Advisory: There is a timer to submit a number given on the desktop version to link the mobile application, which could cause issues for many assistive technology users. The alert does not announce itself when nearing the end of the countdown, at which point the code expires and the process must be restarted.

Writing Feedback and submissions

Colour is the only means to identify links such as “Privacy Policy”. This fails WCAG 1.4.1 Use of Colour (A).

Errors are not communicated effectively to assistive technologies beyond a visual indication. This fails WCAG 3.3.1 Error Identification (A).

The "Browse files to upload" link has no visible keyboard focus indicator. This fails WCAG 2.4.7 Focus Visible (AA).

The options in the drop-down ("Business report", "Case study", etc.) are not announced at all to screen readers. This fails WCAG 1.3.1 Info and Relationships (A).

When navigating to the "Document type" field by keyboard, an action is activated without a user executing a control to expand it. This fails WCAG 3.2.1 On Focus (A).

The selection options in the "Document progress" section are marked up as radio buttons where they do not appear to be visually. This fails WCAG 1.3.1 Info and Relationships (A).

In the "Document upload" section, the progress of the uploading process is shown by a coloured marker on the left-hand side and no other way. There are also cross and tick icons to indicate progress, but these are also visual-only indicators, and do not give meaningful infomation to screen readers. This fails WCAG 1.3.3 Sensory Characteristics (A).

Study Assist

Links are only distinguishable from body text by colour. This fails WCAG 1.4.1 Use of Colour (A).

The "Try it now" image does not have a non-visual alternative. This fails WCAG 1.1.1 Non-text Content (A).

At 200% magnification, there is significant text clipping and overlapping in the navigation bar on the left-hand side. This fails WCAG 1.4.4 Resize Text (AA).

At higher levels of magnification, the main navigation menu is converted into a hamburger menu. Focus is not fixed to this menu, so users can navigate via keyboard to the page underneath, which then leads to the page underneath being obscured. This fails WCAG 2.4.11 Focus Not Obscured (AA).

The "Help us improve" hovering message can only be triggered by mouse, not by keyboard. This fails WCAG 2.1.1 Keyboard (A).

 Assignment Calculator

Items in the calendar have different types of status, which is communicated by colour alone. This fails WCAG 1.4.1 Use of Colour (A).

The calendar does not reflow well, and introduces clipping at higher levels of magnification. This fails WCAG 1.4.10 Reflow (A).

Some elements do not respond to browser-based text size adjustments. This fails WCAG 1.4.4 Resize Text (A).

There are several elements with low contrast on the assignment calculator landing page. This fails WCAG 1.4.3 Contrast (Minimum) (A).

The social media links do not have accessible names. This fails WCAG 2.4.4 Link Purpose (A) and WCAG 4.1.2 Name, Role, Value (A).

Some links do not have descriptive text, e.g. "Read more about how we help students every day," where "Read more" is the only part of the sentence that is a link. This fails WCAG 2.4.4 Link Purpose (A).

Disproportionate burden

This section covers issues that Studiosity cannot fix right now, according to the current Studiosity accessibility statement. They have assessed the cost of fixing these issues but believe that doing so would be a disproportionate burden within the meaning of the law.

Equation editor

Keyboard focus does not behave as expected and is not always visible in the equation editor. This fails WCAG 2.1.1 Keyboard (A) and WCAG 2.4.7 Focus Visible (AA).

The equation editor in the classroom uses an external software library that does not allow overriding the keyboard focus behaviour or visibility.

Studiosity have assessed the cost of building a new equation editor within the online classroom or integrating a different software library. Doing so at this time would be a disproportionate burden within the meaning of the accessibility regulations. Studiosity will make another assessment in 2026.

Audio descriptions on existing videos

There are several videos on the site that do not have audio descriptions. This fails WCAG 1.2.5 Audio Description (prerecorded) (AA).

These videos were produced with help from an external agency that did not provide an alternative audio track with audio descriptions.

Studiosity have assessed the cost of having audio descriptions recorded and edited into an alternative audio track for all the existing videos. Doing so at this time would be a disproportionate burden within the meaning of the accessibility regulations. Studiosity will make another assessment in 2026.

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

This section covers issues that we do not need to fix right now. The law calls these exemptions.

Third-party content

UCL

Our websites contain third-party content. We do not have control over and are not responsible for the accessibility of this content, but we make best endeavours to work with the third-party to improve its accessibility. This may include:

  • links to non-UCL websites
  • content/functionality on our website
  • content hosted on other websites, such as social media sites.

To help accessibility compliance across the sector, University College London supports searchBOX, a centralised, independent directory of third-party accessibility information. 

searchBOX catalogues the contact information and accessibility statements of third-party suppliers, enables the sharing of community-generated accessibility statements, and allows users to map their supplier ecosystem. 

Users can access third-party accessibility statements using the free searchBOX Finder service. 

University College London encourages all our partners and suppliers to support this effort by ensuring that their accessibility information is included in the searchBOX directory.

Studiosity

The whiteboard on the question create page and in the classroom can only be drawn on using a touch or pointer device.

Because the whiteboard is a path-based editor, the accessibility regulations do not require it to be operable with a keyboard or screen reader.

Students can use the question textbox, text chat and file upload as alternative means to communicate their questions to the specialist.

What we're doing to improve accessibility

Studiosity have committed to improvements focusing on accessibility through 2026 as listed in the current Studiosity accessibility statement.

Our testing processes

We tested the website using a combination of manual and automated checks alongside reference to the existing accessibility reports provided by the third party systems that make up parts of the process. If you find an issue we have not yet identified, you can report it to us. We’ll pass this information to Studiosity, who will review the issue, make sure it is included in their plan to fix issues and add it into the accessibility statement when it is next updated.

Preparation of this accessibility statement

This statement was prepared on 5 June 2026. This website was last tested on 20 March 2026. The test was carried out by UCL. Information from Studiosity's accessibility statement was also included in this statement.