Editor’s note: When we changed the 2020 Library Publishing Forum to a virtual conference format, we gave presenters the option of converting their presentations into blog posts. This is a guest post in that series.
By Israel Cefrin, PKP
Background
Improving the usability of Open Journal Systems (OJS) is a current concern and goal of the Public Knowledge Project (PKP). Since the OJS3 release in 2016, PKP has undergone usability testing to assess current and new features. Likewise, this version was the first to include a better approach to navigate in the Dashboard using the keyboard to manage submissions. For accessibility purposes, the interaction with a website must include keyboard navigation, since it is considered a basic concept of input. Hence, any interface needs to allow users to interact with it using a keyboard only rather than a mouse.
Since this initial effort in 2016, PKP is aware of accessibility issues in OJS that could prevent the use of the software by people with disabilities (PWD). These issues are related either to the dashboard or user interface and the public reader interface which is managed by themes.Currently, OJS themes that PKP shares to the community are responsive. These themes are templates that adapt the look and feel of journals. They can be used with small screens like smartphones or tablets, but are not fully accessible for desktop users.
The first step to Accessibility – Themes
Motivated by the Accessibility for Ontarians with Disabilities Act (AODA) (legislation in the Canadian province of Ontario) an Accessibility Working Group (AWG) was formed at the PKP sprint during the 2019 Library Publishing Forum in Vancouver, Canada. The initial task for this working group was to state the implications to the community and Canadian institutions that use OJS regarding the AODA and accessibility for their journals’ websites. At this time, a roadmap was devised to guide related work.
Group members agreed, as the first practical in software development terms, that tackling accessibility issues for the OJS Default Theme should be the main task to pursue. Moreover, it would require an assessment of the current state and a trackable action plan to turn it fully or, at least the most compliant to, accessibility guidelines and standards.
Accessibility assessment and Web standards
Moving forward, it was decided that evaluating the OJS interface would require an external expert. Even though the internal development team was working with designers, developers, and researchers, it was clear that the workload for auditing would demand a seasoned professional in the accessibility field.
We had a broad idea that the assessment would cover automatic and manual test validation, and we were pretty sure that achieving Web Content Access Guideline (WCAG) compliance with level AA ought to be our success indicator. In fact, the most automatic accessibility validation tools usually report results comparing to the WCAG compliance level. Our external vendor for accessibility auditing, however, brought us a different but complementary understanding: that the compliance level to Web Standards can not be the final goal, but rather a way to achieve a more accessible website.
It turned out that for comprehensive accessibility auditing, we should go through the same path that we used to follow for usability testing sessions. OJS3 was released after testing and feedback from users, i.e. authors and editors that were final users of it. Our vendor would provide an audit report based on testing by people with disabilities (PWD) using their own devices enabled with assistive technology (AT).
In fact, we wouldn’t ignore WCAG but go further in the user experience (UX) evaluation. Even though it is possible, and reasonably straight forward to enable screen readers apps on macOS, Windows or Linux desktop, it is not easy for an ordinary or a heavy user to emulate a PWD user behaviour as long they are navigating with AT aid. The same applies to smartphones and tablets. For example, It is possible to enable VoiceOver in iOS devices, however, using it to navigate and run into the issues that a real PWD does, is much different.
The auditing process resulted in a better understanding of an inclusive design process. We have received feedback from people that rely on AT to access the internet. Furthermore, improvements that can be implemented from their report will also benefit every user, including those that don’t rely on any AT.
Outcomes from the auditing
The audit report from this initial work is under a non-disclosure and confidentiality agreement with our external vendor. We can, however, share that, this document helped us to file issues in an Accessibility project in Github. It is helpingPKP to manage issues and for our community members to track, collaborate, and verify the work that it is already done.
Currently, the OJS Default Theme is being adjusted and tested internally. Every issue, when moved to the “Ready for Review/Testing” card is tested against a set of operational system (OS) and browsers with AT enabled. Even though we can not emulate a PWD user, it is possible to make quick checks and testings. This accessible theme is planned to be released with OJS 3.3 version. The release candidate should be available to the public in 2020. Before the final release, this theme will be assessed once more by our external vendor. From this final assessment, we will generate an Accessibility Statement or a related Voluntary Product Accessibility Template (VPAT) document for the theme. This document will state possible existing hurdles and workarounds for remaining issues. More than reports or compliance documents, the main goal is to achieve a high level of true accessibility in the public reader interface. That way, we will be going towards tackling the second part of this initiative: making the OJS Dashboard accessible as well.