Legal statements

PeopleXD accessibility statement

The University of Glasgow is committed to making its website accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

This accessibility statement applies to the PeopleXD system used by staff to access their personal details, view payslips and manage leave requests, etc. Internally, this is often referred to as the ‘Employee Dashboard’.

It also includes Volcanic, the e-recruitment portal website that allows applicants to apply for vacancies via the Volcanic module, part of the PeopleXD system. This website is used by both internal staff members and external candidates to apply for vacancies at the University of Glasgow. An account is required to submit an application, which anyone can create. This website is administered by the University of Glasgow; however, the module is a third party solution owned by the Access Group, with minimal customisations available applicable to the University of Glasgow’s usage.

Using the PeopleXD system and PeopleXDRecruit e-recruitment services

The PeopleXD system for managing HR and Payroll data and processes, as well as the PeopleXDRecruit e-recruitment portal website, is run by the University of Glasgow and developed and hosted off-site by the Access Group.

We want as many people as possible to be able to use this service. For example, that means you should be able to:

  • change colours, contrast levels and fonts. The contrast ratio between text and background is at least 4.5:1
  • zoom in up to 300% without the text spilling off the screen
  • navigate most of the service using just a keyboard and use menus consistently
  • navigate most of the service using speech recognition software
  • listen to most of the service using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)

We’ve also made the 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 aren’t fully accessible:

  • the text won’t reflow in a single column when you change the size of the browser window
  • you can’t modify the line height or spacing of text
  • most older PDF documents aren’t fully accessible to screen reader software
  • some of our online forms are difficult to navigate using just a keyboard
  • you can’t skip to the main content when using a screen reader

Feedback and contact information

If you need information on this website in a different format like accessible PDF, large print, easy read, audio recording, or braille:

If you need information on this website in a different format like accessible PDF, large print, easy read, audio recording or braille, contact:

We’ll consider your request and get back to you in 5 days.

British Sign Language

BSL users can contact us via contactSCOTLAND-BSL, the online British Sign Language interpreting video relay service.

Find out more about BSL assistance: contactSCOTLAND

Enforcement procedure

The Equality and Human Rights Commission (EHRC) is responsible for enforcing 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

Our third party supplier for the PeopleXD system and Volcanic e-recruitment portal website, the Access Group, is committed to making its websites and mobile applications accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Compliance status - PeopleXD system

Our supplier, the Access Group, has confirmed that the PeopleXD software is not fully compliant with the Web Content Accessibility Guidelines version 2.2 AA standard.

Non-accessible content

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

Non-compliance with the accessibility regulations

  • Some roles are invalid. Roles make it easier for assistive technology users to identify user interface elements and navigate the page. Examples of widget roles are button, checkbox, and progress bar. Non-standard, capitalised, or misspelled ARIA attributes will not deliver the intended user experience and may even break the usability of your site. This does not meet WCAG 2.1: Understanding Success Criterion 1.3.1: Info and Relationships.
  • Visible label and accessible name do not match. Using two different names for a single page element can create a confusing user experience for assistive technology users. For example, speech-input users may have difficulty activating a control if the label displayed on-screen does not match its accessible name. This does not meet WCAG 2.1: Understanding Success Criterion 2.5.3: Label in Name.
  • Container element is empty. Roles provide information about content structure and how page elements fit together. Some roles depend on other roles for context. For example, the role list item can only really be meaningful in the context of a list or group. This does not meet WAI-ARIA 1.1: 5.2.5 Required Owned Elements.
  • Form field is not labeled. Unclear labels make form-filling harder for everyone. 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. This does not meet WCAG 2.1: Understanding WCAG Success Criterion 3.3.2: Labels or Instructions.
  • Text is clipped when resized. Visitors with low vision may not be able to access information if text is clipped (cut off) when scaled up. You can test this issue by:
    • zooming in on the page
    • increasing the font size in your browser settings
  • The options available for increasing the text size depend on your browser. This does not meet WCAG 2.1: Understanding Success Criterion 1.4.4: Resize text.
  • Element IDs are not unique. Sometimes it's important to know how different page elements fit together. Whereas sighted visitors may be able to get this information from the visual layout, visitors using screen readers rely on page elements being marked up correctly in the HTML. This does not meet WCAG 2.1: Understanding Success Criterion 4.1.1: Parsing.
  • Color contrast does not meet minimum requirement. Text that is too faint can cause problems for users who are color blind or have low vision. WCAG requires a minimum color contrast ratio of at least 4.5:1 for normal text, and 3:1 for large text (18pt and above, or 14pt bold). This does not meet WCAG 2.1: Understanding Success Criterion 1.4.3: Contrast (Minimum).
  • Hidden element has focusable content. The aria-hidden attribute is used to hide decorative parts of a page from assistive technology. "Focusable" page elements are those that visitors can interact with using a keyboard or other device - such as links, checkboxes, buttons, and form fields. In this case, the element has been removed from the reading order, but not from the focus order — which could result in a confusing experience for screen-reader users. This does not meet WCAG 2.1: Understanding Success Criterion 1.3.1: Info and Relationships.
  • Table headers aren't referenced correctly. Data tables can present a challenge to people who are blind or have low vision - especially if the table contains a lot of information. 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. This does not meet WCAG 2.1: Understanding Success Criterion 1.3.1: Information and relationships. This does not meet WCAG 2.1: Technique H43: Using id and headers attributes to associate data cells with header cells in data tables.
  • Scrollable element is not keyboard accessible. Keyboard accessibility is an essential component of an accessible website. Visitors who can't easily use a mouse may instead use a keyboard (or keyboard alternative) for navigation. This includes people who are blind and people with motor disabilities. This does not meet WCAG 2.1: Understanding Success Criterion 2.1.1: Keyboard.
  • Role not inside the required context. Roles provide information about content structure and how page elements fit together. Some roles depend on other roles for context. For example, the role list item can only really be meaningful in the context of a list or group. This does not meet ARIA 1.1: 5.2.6 Required Context Role.
  • Page language has not been identified. Language tags tell screen readers how to pronounce the text on a page. If language tags are missing or mistyped, the screen reader will revert to its default pronunciation settings. This could result in a strange or confusing experience for users who access content in more than one language. This does not meet WCAG 2.1: Understanding Success Criterion 3.1.1: Language of Page.
  • Name, Role, Value. Providing role, state, and value information on all user interface components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by people with disabilities. This does not meet WCAG 2.1: Understanding Success Criterion 4.1.2: Name, Role, Value.

What we’re doing to improve accessibility

The PeopleXD software provider, the Access Group has confirmed that they are working towards all new software development meeting accessibility standards, and we will liaise with the supplier to ensure we take advantage of alterations/improvements which are made available by them.

The Access Group use the following approaches to assess the accessibility of Access Workspace:

  • Continuous manual self-evaluation
  • Use a variety of tools to help test for accessibility, including WAVE, Sim Daltonism (for colour blindness simulation), CC Checker, Stark WCAG Contrast checker, Axe Accessibility, JAWS and Lighthouse
  • Test the software with the NVDA and Voiceover screen readers, as well as for keyboard navigation

Preparation of this accessibility statement

This statement was prepared on 10 August 2022. It was last reviewed on 22 January 2026.

This website was last tested 24 October 2025. The test was carried out by The Access Group. 

This page was last updated 27 January 2026.