Accessibility improvements to upgrade an existing feature
Custom ordering in the JSTOR Workspace
On JSTOR, a cloud-based digital library with millions of texts and images, the Workspace is a place where users can save and organize content into folders for later review, among other things. As a senior product designer, my goal is to make the Workspace and other aspects of the JSTOR experience as user-friendly as possible.
Faculty, including those who teach with images, are frequent Workspace users and often need to present their folders or to share them with students. It’s critical for these items to appear in a user-defined order. To meet this need, we created a “custom ordering” workflow in the Workspace that relies on drag-and-drop functionality. Our solution allowed users to drag and drop items into any order and automatically saved their changes. We also enabled keyboard controls for accessibility. We included directions for primary keyboard users and a “skip to items” link to take them straight to the section in Workspace where they could begin reordering.
Uncovering Accessibility and Functionality Issues
We first heard from one of our Partner and User Support colleagues that the custom ordering functionality wasn’t working as expected on Firefox. When the user dropped an item, whether via keyboard controls or drag and drop, the item page would open and the custom ordering failed.
We later learned about several more accessibility issues when a new Accessibility Lead, Mat Harris, joined our ITHAKA squad. He pointed out that the custom sort functionality turned the entire item in the Workspace into a button. Even an accidental click would select this button and “pick it up,” leaving it attached to the user’s cursor. This issue was even more pronounced on mobile devices, where users attempting to tap to navigate to an item would inadvertently activate the drag-and-drop functionality instead. This made for a distracting and sometimes confusing experience.
While testing different assistive technologies, Mat also noticed that the VoiceOver screen reader on MacOS would repeat the instructions “Rearrange items in any order with manual drag and drop” every time a user used the Enter key to pick up an item. We initially thought these would be helpful instructions for assistive technology users, but they were actually a nuisance and overly verbose.
Additionally, the custom order functionality did not work as expected for users of two common Windows screen readers, NVDA (Nonvisual Desktop Access) and JAWS (Job Access with Speech). These users could not tell where the custom order control boundaries were, and when they tried to activate the control they checked the checkbox instead of picking up the item.
For users with low vision, it was also hard to tell when they had dropped an item, because the selected and focus states looked very similar.
We realized that our earnest efforts to create an accessible solution had fallen short. We needed to go back to the drawing board.
Fortunately, at ITHAKA, we believe that product development is an ongoing process — learn, build, measure, and repeat. We also know that when we take a collaborative approach to a problem, we’ll design better solutions.
As a team, we put our heads together to come up with an accessible solution that met the needs of our users.
Embracing Teamwork: Collaborative Solutions in Action
Mat started by demonstrating the experience while using different assistive technologies so Maria Devadoss, our UI Engineer, and I could understand the difference between the expected and actual experiences. He then shared a few examples of drag-and-drop solutions that worked well when using only keyboard controls.
We considered the desired behavior from the user’s perspective and decided that it would be more accessible to have an explicit button control for reordering. This would give users a single control to operate the custom sort functionality. Sighted users using a mouse could click and drag an item, while sighted primary keyboard users could tab to an item, activate the control to select it, and then use the arrow keys to reorder. When assistive technology users discover and activate the “reorder” button, they are made aware of the item’s selected state and of its position in the full list of items. They can then use the arrow keys to move the item and press Enter to drop the item in its new position.
Maria noted that a Vue library, VueDraggable, offers the capability to integrate a handle icon into a draggable item. This is useful when we have complex draggable items with multiple interactive elements (buttons, inputs, etc.). This feature seemed to align perfectly with our needs. Maria implemented this approach and made sure the drag-and-drop action could only be started by clicking the designated handle. Then she ensured that these changes delivered consistent outcomes for users who primarily rely on keyboard input.
While Maria was implementing that feature, we collaborated to be sure that items in different states were visually distinct, which improved the overall user experience. Items that were selected or “picked up” looked different from items that were focused or that weren’t selected. We also removed the focus state from the full item. This removed a noninteractive element from the tab order so primary keyboard users had only one tab stop per item.
Outcome and Lessons: Advancing Accessibility Together
Our solution is now accessible for MacOS users on Firefox and works well with VoiceOver. We have a few additional improvements to work out for users on mobile devices who use screen readers (such as TalkBack & VoiceOver) and for NVDA and JAWS users on Windows.
We learned that moving forward we need even more collaboration between development and design on accessibility features, and we need to start earlier in the design process. We are working on moving our consideration of accessibility earlier in the design and discovery process. We are also using accessibility annotations to help developers with notes on heading levels, landmarks, and regions, and we ensure each interactive element has an accessible name, an explicit role, and a defined value or state. Designers are studying accessibility and learning collaboratively alongside Mat and our front-end engineers.
By being more proactive and less reactive with regard to accessibility, we know that we are doing better by our users and making JSTOR a more inclusive and welcoming place to learn and do research.
Interested in learning more about working at ITHAKA? Contact recruiting to learn more about ITHAKA tech jobs.
