Tackling accessibility in OJS 3.0 beta

November 30th, 2015 by  | No Comments

We’ve worked hard to address accessibility concerns in the new OJS 3.0 beta. When we overhauled the design, we were able to address a number of basic issues. In this post, I’ll detail some of the things we did to solve existing problems and some of the problems we plan to tackle going forward.

What is accessibility?

When we aim to make OJS 3.0 “accessible”, we are trying to ensure that as many members of society can access and use our software as possible. In web design, this is often thought of in relation to the blind or those with visual impairments who must use a screen reader to access the internet.

It can also refer to a much wider cohort of users who face permanent or temporary impediments to their ability to use the web. It may include those who have difficulty reading text due to colour blindness, blurry vision or other problems. It would include those who can’t use a mouse — either because of a permanent disability or temporary injury. It can even include contextual impairments, such as viewing a website on a reflective device when the sun is shining on it, or a parent trying to use the web one-handed because they have a newborn cradled in the other arm.

Accessibility means dispensing with the traditional paradigm of the web: a bright desktop monitor with a large visual display controlled by a mouse and keyboard. Instead we must think about using our interfaces with a variety of tools and techniques.

Colour contrast

When we redesigned the backend, we made careful use of colour contrast to increase focus. We also took into account the importance of using colour in combination with other visual cues to designate visual states, such as currently selected items and clickable elements.

In the image below, the navigation elements change colour when being hovered. Notice we’ve also added a distinct line to accompany the colour shift. On the primary menu a bright line appears on the left and on the tab set there is a dark line below the tab label.


These lines provide additional visual cues for those who have trouble distinguishing between certain colours, so that it’s clear to all users which element is in focus.

Font legibility and internationalization

An often underlooked part of accessibility is ensuring that the typography is clearly legible and supports a wide variety of languages. We’ve used the Noto Sans font, designed for the web with wide language support, and increased the font size considerably.

Every year device manufacturers are packing more pixels into smaller screens. That includes your mobile phone as well as your desktop monitor. For that reason, the old paradigm of 10pt Verdana font sizes is no longer legible on many devices.

OJS 3.0 will use a larger base font size, which will no doubt cause some discomfort for users accustomed to the use of tiny font sizes in traditional academic software. But it aligns with modern trends toward larger content sizes, which cater well to the rise of both tiny devices and large, widescreen monitors which can be viewed at a distance more comfortably over long work sessions.

Keyboard navigation and sane document structure

OJS 3.0’s backend structure is very friendly to keyboard navigation, employing sensible document structure, focusable navigation menus and keyboard control for the tabbed content used throughout the workflow.

Keyboard navigation is one of the biggest and easiest ways to increase accessibility. It improves things for all kinds of users — including a bunch of those on the “temporary disability” spectrum who struggle to use a mouse for a variety of reasons.

As a general rule, it also makes things a lot easier for those who use a screen reader, because efficiently navigating a document with the keyboard requires sane document structure which is also read by screen readers. This includes using appropriate heading and link markup, which provide structure to the document which helps screen readers navigate the content.

One of my favorite accessibility improvements we’ve made is to the way focus is handled in our modals. When a user opens a modal, the keyboard’s current location and screen reader focus is automatically shifted to the modal. When the modal is closed, the focus is shifted back to where it was before the modal was opened.

Sighted, mouse-using users do fine with the visual cues. But other users can easily be left stranded with modals.

This is a quick demonstration showing that feature. Look closely to see the focus outline before and after the modal is displayed.

Unfortunately, we still have a few areas where we need to improve keyboard accessibility. Right now our grid components have a critical accessibility issue when opening contextual menus in the rows. We’re going to get it sorted out for OJS 3.0’s production release.

Frontend reader interface

I’ll talk about our new reader frontend in another blog post. But rest assured we’ve got a good focus on accessibility there as well.

Improvements to make before the big 3.0

It can be challenging to build a modern, accessible application, even for well-intentioned developers. Take a look at these disastrous testing results when the WordPress development team considered using a popular component that helps users select from large lists.

We’re always trying to improve our accessibility and I’m proud of what we’ve done with OJS 3.0. But I’m sure we’re going to find ways that we’re falling short.

We’ve already identified several improvements we can make. Here’s a quick run-down of what we hope to accomplish in time for OJS 3.0’s production release:

  • Through the backend we’ve minimized excessive page loads by pulling content in live as and when needed. However, this can be confusing for those who use screen readers. We need to add specific aria-live markup to make this easier to understand and use in such circumstances.
  • We could make better use of aria-regions and landmark roles to describe our content. This is not a difficult task and will help those who use screen readers.
  • Skip-to-content links are very useful for people who use keyboard navigation. Especially in the backend, for people who will be using the service daily, this can be a big help.

Here's your chance to leave a comment!