Building and testing an accessible video clipping component for people with disabilities

Reading time: estimated 7 minutes

On This Page

At Fable, we focus on product usability over accessibility compliance. After all, technical accessibility isn’t a guarantee that your product is usable by people with disabilities. In this post, we’ll talk about how we built and tested an accessible video clipping feature. We’ll also touch on our plans to iterate on it in the future, with a focus on making the experience easier for all users. 

Introduction

After a video session with Fable, like a User Interview, you can view the recording on the platform. This means you can focus your attention on the session while it’s happening, then review and take notes after. We recently upgraded our video player with brand new features to make it easy to share key moments. These features include video clipping and an interactive UI for viewing transcripts.

Screenshot of Fable's accessible video clipping component. A segment of the video (featuring a school of fish) is highlighted, for trimming.

Establishing a baseline

Before starting development, we reviewed similar experiences from products that we’ve used before. We looked at Loom’s video clipping UI and similar Video.js plugins for annotation. This gave us the framework for how to build video clipping into our video player. For conventions around working with timelines and by recommendation from Samuel Proulx, our Accessibility Evangelist and a blind screen reader user, we referenced common audio editing software. From here, we noted the use of custom keyboard shortcuts for important functionality.  

We also took some cues from WCAG (Web Content Accessibility Guidelines). Specifically, Success Criterion 2.4.5: Multiple Ways. For our case, we knew it would be important to have multiple ways to set the start and end points of a video clip. Though 2.4.5 doesn’t apply in this context, it does provide good insight into why it’s helpful to give users options. 

The intent of this Success Criterion is to make it possible for users to locate content in a manner that best meets their needs. Users may find one technique easier or more comprehensible to use than another.

– From Web Content Accessibility Guidelines, Section Criterion 2.4.5: Mutiple Ways

Now, our 3 biggest development considerations were: 

  • Managing keyboard focus between video player features and video clipping features
  • Implementing drag and drop functionality on the video timeline 
  • Adding custom keyboard shortcuts 

Testing Plan

Here at Fable, we work in 2-week sprints and often take an MVP approach to planning features. For major features like this one, we release to employees first so that we can gather feedback. For our MVP, we ensured that all users could create a video clip end-to-end in at least one way. From there, we would do usability testing with Fable’s community of accessibility testers. 

Our user testing plan started with Compatibility Tests with mixed assistive technology users: 

  • 3 screen readers 
  • 1 alternative navigation 
  • 1 screen magnification 

These tests would help verify that core functionality is working as expected across devices. They may also hint at assistive technologies to follow up on with User Interviews. 

Our Compatibility Test results showed the on-screen keyboard experience as the most challenging. To dig deeper, we planned a User Interview with another alternative navigation user. This time, we spoke with a user of Dragon NaturallySpeaking. We wanted to see if the experience was like the on-screen keyboard experience and observe problem areas in real time. 

In the future, once we action the feedback from our first round of testing, we can run follow up Compatibility Tests. This will help us to track accessibility over time. And of course, User Interviews with more types of assistive technology will help to enhance the overall user experience. 

Creating a clip and managing focus

Our video clipping functionality has 2 main UI states: playing and editing. Once a user interacts with the “Create clip” button, a visible clip range displays on the timeline and new actions are available below the player. To make sure users can seamlessly start interacting with these new actions, keyboard focus is automatically set to the container of the action buttons using JavaScript. 

screenshot of Fable's accessible video clipping component. Zoomed in, the play function icon is visible, along with the video title, duration, and file size.

For screen magnification users, our “Create clip” button ended up being difficult to find. This is because it’s placed on the right side of the video player instead of the left. Users are more likely to scan down a page first, instead of left to right and then down. Because of this, important actions or content should always be placed on the left. 

Below the video player is a table containing all videos and clips associated with a request. Selecting a video from this table updates the video player and moves the focus to the play button. Usually, setting the focus to an element on a different part of a page will automatically scroll the page to show that element in view. If you have a sticky navigation, it’s important to consider how it might cover important content when this happens.  

After selecting a video to play, our Dragon NaturallySpeaking user had to manually scroll the page up to see the full player again. To avoid this, we can add some buffer space any time we set focus somewhere further on a page.  

Selecting a clip range

When it came time to start building our clipping feature, we took a progressive approach to setting the start and end points. First, we started with setting a single point with a keyboard shortcut. From there, we allowed for refinement with textboxes, and then added drag-and-drop for more precise control while reviewing a video frame-by-frame. 

Custom keyboard shortcuts

Custom keyboard shortcuts are a great way to add convenience to common tasks for power users. However, it’s important to ensure they don’t interfere with a user’s assistive technology. To help with this, WCAG provides three options as part of