Copy and paste, click and go, swipe right, drag and drop – these computer UI actions are so ubiquitous that they can be heard in everyday conversations. Yet for some people, these actions may be difficult or impossible to perform because of their diverse physical, sensory, or cognitive abilities, causing computers to become barriers to accessing, communicating, or creating information and content rather than open portals. Ensuring digital accessibility is a crucial consideration in our software product development process. This perspective becomes especially important with products that rely on heavy interaction through the user interface, a perfect example being a canvas-based application such as a chemical drawing tool. The following article outlines the importance of digital accessibility and explores its implications on software development.
Ensuring that software applications are accessible to disabled people requires software developers to provide and build in usability tools and features that overcome these barriers. Examples of assistive technologies include screen readers, voice recognition systems and alternative input devices, coupled with interface changes to enhance accessibility such as high contrast, keyboard navigation, and clear and informative labels and buttons. These adaptations can also benefit people inconvenienced by a temporary disability such as an arm in a sling or a lost or broken pair of glasses.
Some 15-20% of the population have some form of disability1 – including speech, visual, auditory, cognitive, neurological, and physical – which can limit their ability to make effective use of software applications. There are many ongoing voluntary initiatives to enhance accessibility by individual software companies, and standards have been developed to ensure that any accessibility features are perceivable, operable, understandable, and robust, with the Web Content Accessibility Guidelines2 (WCAG) being a leading example.
In Europe it is estimated that there are 87M people with disabilities in the 27 EU member states, and the EU is introducing legislation that will ensure that accessibility is built into all core processes and products. The European Accessibility Act3 (EAA) comes into force on 28th June 2025, and from that date, any new products and services (including computers and operating systems) to be sold or licensed in the EU will have to be accessible on launch, while pre-existing products will have three years to reach compliance.
Demonstrating compliance with the WCAG accessibility guidelines is typically achieved by engaging the services of a third party which offers auditing of software applications, certification, and ongoing compliance checking and management of post-audit updates. The most comprehensive auditing methods will combine software automation to check for code-level conformance, coupled with skilled human auditors for detailed manual review. Fully compliant applications will then be issued with a time-stamped certificate of compliance.
Within the scientific community, efforts have been made to assess how many scientific staff are disabled, and the Royal Society of Chemistry (RSC) in the UK regularly surveys its members and includes such an assessment. Recent surveys4 suggest that while 4% of respondents self-identify as disabled in some way, 10% report that they "experience barriers or limitations in their day-to-day activities relating to a form of disability, long-term health condition or impairment", with the barriers including inadequate digital accessibility5. The RSC also has a strong advocacy programme6 for disabled chemists with staff7 devoted to disability and accessibility, as does the American Chemical Society.8
So what does this mean for scientific software developers, and how have their practices evolved to address the accessibility challenges? A review of the literature9 indicates that the number of publications on software engineering and accessibility is significant, with many studies on software testing and accessibility, and that process establishment and accessibility started to be investigated from 2011.
A key finding was that accessibility needs to be built into the software design process as early as possible rather than treated as a later change or add-on. And while this design imperative is broadly accepted, another study10 suggests that there is still work to be done, with a number of areas for attention:
With these caveats in mind, Chemaxon is committed to ensure that its products fully comply with the requirements of the EAA, with a particular focus on the accessibility aspects of Marvin. We have worked together with Ability, Inc.11 and have received a certification indicating a partial conformance with WCAG 2.2 Level A and AA. Accessibility is an ongoing process, and we are continuously working to improve the user experience and ensure accessibility for everyone.
(1) https://www.who.int/news-room/fact-sheets/detail/disability-and-health
(2) Web Content Accessibility Guidelines (WCAG) international standard, WCAG 2.0, WCAG 2.1, and WCAG 2.2 documentation, https://www.w3.org/WAI/standards-guidelines/wcag/
(7) https://www.rsc.org/news-events/opinions/2024/feb/approaching-accessibility-from-the-outside-in/
(8) https://www.acs.org/about/inclusion/inclusivity-style-guide/accessibility.html
(9) Accessibility and Software Engineering Processes: A Systematic Literature Review; Journal of Systems and Software, Volume 171, January 2021, 110819. https://www.sciencedirect.com/science/article/abs/pii/S0164121220302168
(10) Accessibility in Software Practice: A Practitioner's Perspective, Tingting Bi, Xin Xia, David Lo, John Grundy, Thomas Zimmermann, Denae Ford, https://doi.org/10.48550/arXiv.2103.08778