XClose

Accessibility

Home
Menu

Moodle accessibility statement

This accessibility statement applies to University College London (UCL) Moodle 4.2

UCL Moodle (https://moodle.ucl.ac.uk/) is run by University College London (UCL). It is designed in line with recognised good practice, and training in creating accessible content is provided to all site owners and editors. We want as many people as possible to be able to use this website, which 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 website using just a keyboard
  • navigate 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

 Moodle is an open-source Virtual Learning Environment. This means that certain aspects of its design are not under UCL’s control. 

    We know some parts of this website are not fully accessible. You can see a full list of issues we currently know about in the non-accessible content section of this statement.

    • Some elements are not keyboard accessible.
    • Some elements do not receive focus visibility.
    • Some video and audio content may not have captions, transcriptions, or audio descriptions.
    • Some images do not have meaningful alternative text.
    • Some pages do not have sufficient colour contrast.
    • Some elements do not have accessible names.
    • PDFs (Portable Document Formats) and other documents are not fully compatible with screen readers.
    • Links are not always clearly described.

    We provide a facility within Moodle whereby resources can be downloaded in a range of alternative formats via Blackboard Ally or you can use Sensus Access for content outside of Moodle.  

    Feedback and contact information

    Should you find that some course materials are still inaccessible, you should contact the module lead in the first instance. 

    If you require technical support with UCL Moodle please contact the IT Service Helpdesk. See our Service Desk Help and Support pages for details about visiting in person.

    Resources and practical support with digital accessibility for students are available through the Digital Accessibility Hub.

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

    Contacting us by phone or visiting us in person

    Resources and practical support with digital accessibility for students are available through the Digital Accessibility Hub.

    Technical information about this website’s accessibility

    University College London is committed to making its websites 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.1 AA standard, 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

    This section covers issues that we need to fix and are working to do so. The issues listed in this section refer to both the UCL Moodle platform and the content hosted in Moodle. 

    Moodle is an Open Source Virtual Learning Environment (VLE) which means that some aspects of its accessibility are outside of our immediate control.  

    The core Moodle accessibility conformance report (VPAT® Version 2.4 ) is based on an audit of Moodle version 4.0. The audit was completed by Web Key IT in May 2022. In May 2023, Moodle 4.0 received the WCAG 2.1 Level AA accreditation. The conformance report is based on the results of an accessibility audit conducted by Web Key IT on a sample of 20 key pages. These pages were selected and agreed on by Moodle and Web Key IT as representative of the overall accessibility and functionality of the Moodle learning management system (LMS). The evaluation was completed following the WCAG Evaluation Methodology (WCAG-EM). The pages were audited manually and cross-checked using a team of website evaluators to ensure that the results and comments presented are valid and comprehensive. Separate and external testing of these pages has been conducted by a group of trained testers, all with disabilities. 

    We list below further areas within UCL’s implementation of Moodle (theme) that we know are not fully accessible. We plan to fix or provide alternatives for all issues that we are made aware of alongside our periodic internal testing and auditing processes. 

    Platform (UCL Moodle theme)

    The progress bar does not have an accessible name for screen reader users. This fails WCAG 1.3.1 Info and Relationships (A).

    Some pages do not have an effective sequential heading structure. This fails WCAG 1.3.1 Info and Relationships (A). 

    Footer links are not presented as lists to associate them as grouped items. This fails WCAG 1.3.1 Info and Relationships (A).

    Some focus states do not have a high enough contrast. This fails WCAG 1.4.3 Contrast (Minimum level) (AA).

    At 300%+ half the screen estate is lost due to the UCL banner, making it hard to see some of the words if they scroll up the screen. This fails WCAG 1.4.10 Reflow (AA). 

    There are 3 skip to links on the page. Skip to main Content, Skip Carousel, and show all Carousel content. We don’t think Skip to Carousel is working as it moved me to Online Learning for you section. This fails WCAG 2.4.1 Bypass Blocks (A).

    Page titles are not always clearly descriptive of the site that they are attached to. This fails WCAG 2.4.2 Page Titled (A).

    Cookies preferences is the last item in the tab order on the login page. This does not give keyboard users an opportunity to inform their browsing choices at the beginning of their journey. This fails WCAG 2.4.3 Focus Order (A).

    When zoomed to 175% a burger menu takes the place of the main navigation. Although keyboard accessible once activated it is difficult to cancel this menu as the close symbol disappears after the first tab stroke. In addition, the keyboard user is then able to navigate the entire underlying site behind the opened drawer before arriving back at the Close Drawer control. This fails WCAG 2.4.3 Focus Order (A).  

    If a page error occurs it is not communicated effectively to screen reader users. This fails WCAG 3.3.1 Error Identification (A).

    Alerts and Messages

    It is not possible to activate the Messages panel using keyboard alone. If clicked in with a mouse it is possible to navigate it, but this cannot be done purely by keyboard tabbing alone. You can keyboard navigate to the Message icon but interacting with it does not enable you to move into the opened dialogue. This fails WCAG 2.1.1 Keyboard (A). 

    There is an issue with both the Alerts and Messages panel where, once activated they visually obscure the Block Drawer which continues to be keyboard navigable. The 'Close block drawer' option is presented although this content is already hidden by the activated messages panel.  The block drawer content remains navigable and keyboard users must cycle through it to carry on their visible tab journey. This fails WCAG 2.4.3 Focus Order (A) and 2.4.7 Focus Visible (AA).

    Calendar

    Using tab to move through the calendar view, as mentioned above, only hit the days with events on them. Once you are on the day a screen reader announces ‘Day and events link’ there is no mention of how many events that day, and you cannot move to those events on this part of the screen, so it is confusing. This fails WCAG 1.3.1 Info and Relationships (A). 

    Calendar links are not differentiated from surrounding text other than by colour alone. This fails WCAG 1.4.1 Use of Colour (A).

    The user can view the upcoming events by tabbing past the calendar and moving to upcoming events, but this is not obvious. The right-hand arrow link is just described as link 'view.php'. This fails WCAG 2.4.4 Link Purpose (A). In addition, the time text is low contrast. This fails WCAG 1.4.3 Contrast Minimum (A).

    It is not possible to navigate through the Calendar with keyboard. Dates that have linked events can be tabbed to but whereas with a mouse you can individually navigate dates and select them to add new events this action is not possible with keyboard alone. This fails WCAG 2.1.1 Keyboard (A). 

    The calendar link icon in the main menu does not have an effective link description. It is just described to screen reader uses as 'button menu'. This fails WCAG 2.4.4 Link Purpose (In Context) (A). 

    At the bottom of the Calendar panel there is a link that will take you to the calendar view for that course – as shown below in the picture. This is one of 3 views that you can choose from – Upcoming events / Day / Month view.  When using a screen reader, it is difficult to select the view, as you are not locked into the selections of that menu only, you can arrow up and move out of it, making it confusing for users, for screen reader users, the form element is not working correctly, so the blue highlight does not move, when you arrow up or down. Also, the element 'Upcoming Events’ is classed as button so should be changed to the correct element; they are form elements. This fails WCAG 2.1.1 Keyboard (A), 1.3.3 Sensory characteristics (A) and 4.1.2 Name Role Value (A).

    Course formats Onetopic/Tabs contrast

    We are aware of some colour contrast issues with Onetopic/Tabs. This is covered in the Moodle 4 – Quick tips for updating your course post. We will be addressing this as part of our specific course format work. My Computer My Way offers suggestions on how to adapt colour and display settings on your device. You can also change colours and contrast to your preference by using a variety of third party tools such as Colour Enhancer for Chrome or Colour Changer for Firefox. Alternatively, a high contrast viewer such as High Contrast for Chrome may make your viewing experience easier. Pixie Reader offers a range of alternative means of presentation for web content.
    This issue fails WCAG 1.4.3 Contrast Minimum (AA).  

    Content

    In this section we have highlighted the most frequent issues reflected in UCL document content (by Blackboard Ally) contained in Moodle.

    Contrast - some documents contain text with low contrast between the text and its background. This can cause the text to be difficult to read, especially for those with low vision, poor eyesight, or colour blindness.  

    Images without a description - some documents contain images that don’t have a description or alternative text. People with screen readers or other assistive devices rely on these descriptions to understand the image content and purpose.  

    Document does not have a language set - some documents do not specify the language in which they have been created. Certain technologies, such as screen readers, rely on the specified language to determine how to process the content or pronounce the text inside of the document. 

    Documents untagged - Portable Document Format (PDF) tags are hidden labels that clarify the structure of the document and define what’s a heading, paragraph, table, list, etc.  

    Document is a missing a title - some PDF documents are missing a title. PDF titles are used as the document title for a PDF window or tab, making it easier to navigate to the PDF and understand the purpose of the PDF. 

    Headings - some documents may not contain marked-up headings providing structure to a document.  

    Tables - some documents contain tables that don't have or properly specify a header structure. People with screen readers or other assistive devices rely on a semantically meaningful and correct heading structure to help them navigate the table and understand the meaning of every cell, but it can be beneficial to everyone to have a clear structure in the table. 

    If you find an issue that we have yet to identify, please contact us using one of the routes described in the ‘Reporting accessibility problems with this website’ section of this statement. 

    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

    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. We are currently working on fixing these essential documents or replacing them with accessible html web 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 or Word documents we publish will meet accessibility standards.

    Video content

    We do not plan to add captions to live video streams because live video is exempt from meeting the accessibility regulations. We also have some existing pre-recorded video content that was published before the 23rd of September 2020. This content is also exempt from the regulations. All new video content we produce will have appropriate captions, audio descriptions and transcripts, as necessary.

    Online maps

    Our service includes the use of online maps to show certain geographical information. These are not used for navigational purposes and are exempt under the regulations. If you require the information presented in an online map in a different format, please contact us to discuss reasonable adjustments.

    Third-party content

    Moodle acts as a gateway for several third-party services over which UCL has no direct control e.g. Turnitin, Lecturecast, the Talis reading list service. Where accessibility issues arise in relation to third-party services and these issues are not already noted in those service’s Accessibility Statement(s), UCL will liaise with suppliers and encourage them to take remedial action.   

    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

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

    The following third-party services are integrated with UCL Moodle:   

    Our testing processes

    We referred to the Moodle accessibility conformance report (VPAT® Version 2.4 ) and selected a prioritised sample of UCL Moodle based on usage, criticality to the user experience and how representative it was of other pages using similar templates or covering related processes. 

    For third-party applications we have sourced accessibility statements from suppliers directly (wherever possible) and added these to searchBOX (a centralised, independent directory of third-party accessibility information) and documented this in our accessibility statements.

    What we’re doing to improve accessibility

    UCL has created a Digital Accessibility Policy to help us embed accessible by design approaches to our own development as well as externally procured digital systems and we are actively engaged in processes to assess and prioritise remediation of existing systems.

    In addition, accessibility is at the heart of our new Design System that will underpin all future digital system development. 

    Preparation of this accessibility statement

    This statement was prepared on 20 July 2023. It was last reviewed on 20 July 2023.
    This website was last tested on 10 July 2023. The test was carried out by UCL.