Accessibility

Ensuring that everyone has equal access to RSpace is important to us, and to that end we have been working to improve the accessibility of the product. This document provides a brief overview of accessibility in web design, to what degree the RSpace product meets the industry standards, and what we are doing to continually improve. 

The main standard for accessible web design is WCAG 2.1, which we aim to be fully compliant with, especially with all new development. The twelve guidelines are wide-reaching and when adhered to ensure that a software product is fully perceivable to all, is operable, is understandable, and is robust. Furthermore, we are aiming to be compliant with EN 301 549 ahead of the June 2025 deadline, which has become the standard in not just the EU but also Canada and Australia. On top of all of the same rules as WCAG 2.1, it also requires that the users have ability to customise the interface to their needs (on what we support is discussed below), and that the product encourages the creation of accessible user generated content, such as by encouraging the use of alt-text alongside any uploaded images.  

How compliant is RSpace, currently? 

Alongside all new development from mid-2023, we are also in the process of going back and improving the general user experience, and especially the accessibility, of the older parts of the product. To that end, the parts of the product that fully meet the WCAG 2.1 standard include 

  • The apps page 
  • The DMP import dialogs 
  • The export-to-iRODS dialog 
  • Soon too the gallery 

Inventory is also partially compliant, with only some known issues. As for the rest of the product, we’re working hard to migrate it to a more modern tech stack which in addition to meeting the accessibility standards will also make the product mobile friendly and allow us to iterate faster on additional features and integrations in the future. All of this takes time, however. 

To identify which parts of the product, meet the guidelines as we continue to work on all aspects of the product, keep an eye out for the accessibility icon. Wherever it is shown, tapping it will display a list of additional accessibility functionality that can be enabled which is discussed below. 

Circular icon with silhouette of outstretched person indicating accessibility compliance.

Noteworthy functionality

There are some aspects of the interface that we’ve been particularly focused on, having identified them as being key to the efficient use of the product, which is largely concerned with data entry and retrieval, and less about multimedia. As such, many of these aspects focus on the visual parts of the interface and input devices. There are four aspects of the design that do not require opting-in and are changes that we’re making that will simply be how the product is presented. There are then an additional few features that are opt-in for those who would like to use them. 

  1. To aid those with colour blindness, we are ensuring that no information is solely conveyed with colour alone: there will always been a textual label or an icon. Where we are using colour, it is simply for stylistic effect or to convey information that is still presented in other ways. Thus far, it has not proved necessary to provide a colour-blind-friendly theme but is something we would consider if simply tweaking the design proves insufficient. 
  2. In a similar vein, we have also been making sure that all interface elements have sufficient contrast, in particular where small text sits atop a similarly-coloured background. The WCAG standard provides numeric bounds that can be easily computed so this has been part of our effort to automate our compliance with the standards. 
  3. When it comes to input, we are adding more keyboard controls to the interface, which is also of benefit to all power users. It is also vital that the standard browser controls, like tab, space, enter, and the arrow keys work as expected in all scenarios. 
  4. Lastly, wherever possible we’re also aiming to provide full compatibility with accessibility technologies such as screen readers and braille keyboards. This is achieved by providing alt-text for images, meaningfully link text, and correct cascading headings. This will require some of the most substantial changes as files, thumbnails, and other images that are uploaded or edited within RSpace will all need to be annotated accordingly by the colleagues of the users of such tools. 

As for the feature that requires opting-in, look out for the accessibility icon shown above and the information provided by the pop-up that opens when it is tapped. These features adjust the interface based on browser or device settings. 

The accessibility tips menu, showing three tips: high contrast mode, reduced animations, and zoom level.
  1. High contrast mode removes the superfluous colour from the interface, increasing the contrast between text and its background, and between adjacent elements. This is to the benefit of those with poor eyesight, but also for anyone who finds themselves in a situation where glare from excess lighting makes using the product difficult. To enable, simply turn on a high contrast mode in your device’s settings and RSpace will pick up that request on the next page load. 
The export to iRODS dialog with high contrast mode enabled
  1. Reduced animation mode turns off all animations. All animations in RSpace are superficial and are not necessary for the operability of the product and so if they prove distracting or trigger any impairments then they can be turned off in your device’s settings. 
  2. Zoom level. The parts of the product that meet the accessibility standard provide a high variability in supported zoom levels, allowing those with poor eyesight to expand the size of the interface. This is provided in concert with mobile-friendly views. 

Finally, if you ever experience any issues with using the RSpace product, please don’t hesitate to reach out to support or to raise an issue on GitHub. We are committed to improving the accessibility of the product and the more information we have about how these changes impact on those who rely on them then the better we can make the software. 

 


How did we do?


Powered by HelpDocs (opens in a new tab)