Skip to main content
Back to King's College London homepage

King's College London

Accessibility Statement for People XD

This accessibility statement applies to People XD which is KCL’s HR & Payroll system.

People XD is a third-party application.

People XD is provided by The Access Group to King’s College London for our HR & Payroll System.

Version 28. Publication Date - February 2020.

Using the application

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

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 People XD are not fully accessible:

  • Web browsers older than 3 major versions can have trouble interpreting modern accessibility techniques.
  • Markdown is a lightweight markup language for creating formatted text using a plain-text editor. Markdown Editors can contain content which does not meet the accepted criteria. A markup language is a text-encoding system which specifies the structure and formatting of a document and potentially the relationship between its parts.
  • User defined colours may not meet the required contrast ration specified in the WCAG 2.1 level AA guidelines. Users are allowed to choose colours at their own discretion and may not always make choices which meet the WCAG 2.1 level AA guidelines.
  • Img elements missing an alt attribute. Alt attributes should be used to specify a short text alternative. Users may provide images with numerical or non-descriptive names which causes an issue for a screen reader specifically.
  • Captions On External Videos are available when the external video includes it. Some third-party video libraries do not always include closed captions. A user may upload such a video without closed captions.

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 non-compliances listed below.

Non-accessible content

People XD 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

  • 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, capitalized, 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.

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 The Access Group 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.

People XD takes the following measures to ensure the accessibility of the application:

  • They scan our application at least weekly using pa11y accessibility tool.
  • Employ formal accessibility quality assurance methods.
  • Include people with disabilities in the planning and execution of our software.
  • A User Interface which supports native browser zoom.
  • A commitment to continually monitoring and upgrading out accessibility support.
  • They have regular interaction with clients for whom accessibility is a priority.
  • They ensure that external video content is captioned.

People XD welcome your feedback on the accessibility of People XD. Please let us know if you encounter accessibility barriers on People XD:

  • If you feel that we can do better, please raise a customer support and case we will

strive make every iteration of the application more inclusive & accessible.

Preparation of this accessibility statement

This statement was published on 23 January 2024. 

This application was last tested on 08 January 2024.

The test was carried out by Charlotte Tolson, Senior Enterprise Systems Analyst, KCL with Siteimprove.

We tested:

  • Page Structure and navigation
  • Readability and colour contrast
  • Internal and external links
  • Alt text and anchor texts
  • PDF accessibility
  • Checking buttons
  • Reviewing HTML and CSS
  • WCAG compliance