Top of page

Orange graphics related to each of the technical guidelines, with black text listing each of the technical guidelines

FADGI Report on Software Accessibility for Open-Source Digital Preservation Applications

Share this post:

Today’s guest post is from Joan Hua, Consultant at AVP, and Kate Murray, Digital Projects Coordinator in Digital Collections Management and Services at the Library of Congress.


As first discussed in a previous blog post, the Federal Agencies Digital Guidelines Initiative (FADGI) AudioVisual Working Group partnered with consultants at AVP to spearhead a project aimed at enhancing accessibility in open-source desktop applications for the digital preservation community. FADGI has produced free and open-source desktop tools for years and is committed to being a responsible steward regarding accessibility.

In spring and summer 2023, FADGI engaged AVP and selected three open-source desktop software applications for evaluations. They collaborated to develop UX scenarios that represent the most common uses of these applications. AVP then brought in the accessibility firm Tech for All (TFA) to conduct detailed accessibility testing. The selection criteria was that the applications be open-source, free, with a GUI (although CLI versions were also tested), in active development and widely used based on download statistics.

The selected applications are:

While open-source systems are meant to lower the barriers for access in one sense, because both the source code and software are freely available, this does not mean they are inherently accessible. The project’s final report goes into detail about accessibility guidelines (especially Web Content Accessibility Guidelines [WCAG] and Section 508) as well as designing inclusive and accessible digital applications. We’ll summarize accessible in this context to mean usable by people with or without disabilities.

In practical terms, this means the applications were tested for accessibility needs including but not limited to: alternate text for images, responsive text size, color contrast, defined code structure for adaptive technology, multimodal cues for encoding structure, navigation including scrolling, tables, clear error messages and more.

Application Testing Results

Screenshot of chart that lists "Problem Spots in Application" for embARC, Handbrake, and BWF MetaEdit

According to TFA’s evaluation, all three applications had serious usage barriers for people who are blind or have mobility impairment (determined by relying on keyboard control). None of them conform with the standards overall. Some cases were so severe that the applications were rendered unusable. So that’s the bad news. But it’s not surprising honestly, because accessibility needs just weren’t on the radar when these applications were first designed and developed.

Before we go into resolutions, let’s look at a few specific examples of issues. The full report goes into much more detail.

Example Issue 1: Data Tables

Screenshot of table with columns for Row number, Filename, and File Path

Because many digital preservation applications are working with bulk data, data tables are an integral component. However, they are navigable with neither a screen reader nor a keyboard. It is not possible to traverse between columns to get header information, and no announcements are made when the user selects or deselects a row from the table. Buttons launched from the sidebar, such as “pop-out” and download buttons are not exposed to screen readers.

Example Issue 2: Color Contrast

Screenshot demonstrating color contrast in an application. At the top there is a light blue button with darker blue "Write Files" text and graphic overlaid. In the center there is a darker blue background with a pink button with dark blue "Stop Editing" text and a green button with dark blue "Apply Changes" text. At the bottom of the image there is a gray bar with white text indicating files imported, selected, links to select or deselect files and a Errors Only checkbox.

Another common issue is color contrast. To conform with the WCAG 1.4.3 Contrast (Minimum) recommendation, the ratio for text in a colored box should be 4.5:1. The 4.5 number in the ratio refers to the relative luminance of the lighter of the colors and the 1 refers to the relative luminance of the darker of the colors. In plain English, this means that there needs to be a great contrast or distinction between the specified background over which the text is rendered in normal usage.

Technical Guidelines and Community Recommendations

Orange graphics related to each of the technical guidelines, with black text listing each of the technical guidelines

The outcome of the application testing led to two sets of good practice suggestions: Technical Guidelines and Community Recommendations (see the project’s final report for more information about these guidelines and recommendations).

The Technical Guidelines include:

  • Make use of keyboard control and navigation: Applications must create logical tab order, or focus order, so that the keyboard user can properly move around the applications and complete tasks.
  • Describe and label interactive elements: To make an application understandable and allow users to easily operate it, the tool should provide input assistance, making it clear how controls are supposed to be used. Best practice is to identify and describe interactive elements, such as buttons, pop-up windows, and check boxes, to allow them to be accessible to screen readers.
  • Check for color contrast, and avoid relying on color to convey meaning: Color contrast affects readability and usability, especially in keyboard focus or when an element changes dynamically based on user input.
  • Structure content and create semantic relationships: It is a recommended practice to programmatically code the roles of interactive elements, and make explicit relationships between elements to allow assistive technology to access the interface.
  • Consider digital preservation use cases: Commonly used elements in digital preservation applications including pop-out windows, data tables, and access to local environments to retrieve or store data, as well the specialized technical needs of digital preservation users, should be assessed for their impact on accessibility.

The Community Guidelines are process-oriented and conceptual. They provide broader, more general guidance for readers who are not directly working on an application but may be making decisions about processes—from usability testing to resource allocation. They spotlight the areas that warrant special attention when it comes to digital preservation tools.

  1. Defined purpose: Clarify principles, goals, and purpose of the application.
  2. Actual users: Conduct usability testing with a diverse user base, including users with various disabilities.
  3. Realistic user stories: Create realistic use cases that are not abstract, and use these as the basis for the requirements of the application.
  4. Continuous feedback: Create a mechanism to collect direct feedback on the tools’ accessibility; remediate accessibility issues when found.
  5. Standardized specifications: Follow design systems and coding standards.
  6. Tiered prioritization: Prioritize accessibility issues to fix based on how prevalent an issue is and how much redesign (of color scheme, layout, user journey/interactions, and so on) is involved.
  7. Wide impact: Make improvements that have a positive impact universally on various groups of users, regardless of whether they are using a piece of assistive technology or experiencing an impairment.
Next Steps and Remediation Actions

Because FADGI helps to support embARC and BWF MetaEdit, the developers for both projects graciously agreed to use the testing results to make the suggested accessibility improvements on the applications. Caroline Shea from PortalMedia, one of the developers of embARC, emphasized that it is professionally rewarding to update the UX design to be more streamlined for all users, including people with disabilities.

Before and After Examples

Screenshot of application with poor color contrast. A table on the right side of the image shows light gray text listing file information over a similar colored background.

In this “before” example, notice the button labels (such as “Write Files” against the medium blue background) are quite subtle. In addition, data in the table on the right is not clearly visible because editing was disabled in this view.

Screenshot of an application with good color contrast. Buttons in the screenshot are shaded with light gray, with dark gray text overlaid. The table on the right of the image clearly shows file information displayed at dark gray text over a white or light gray background.

In this “after” example, the text color in the button labels have much higher contrast against the background color and all the table fields are viewable. Also note that each field name on the left side of the screen has a self-describing information option for screen readers to access.

Track the remediation actions for embARC and BWF MetaEdit in real time at their respective GitHub Issue trackers.

The detailed project report, Accessibility Evaluation Report: Research and Improvements for FADGI Open-Source Software Applications, is available at no cost on the FADGI website.

This project parallels other work undertaken by the FADGI Audiovisual Accessibility subgroup.

By collaborating on this project, FADGI, AVP, and Tech for All aim to contribute to the development and implementation of accessibility best practices in the digital preservation community. By creating an inclusive environment, we can ensure that digital preservation tools and resources are accessible to everyone, promoting a more equitable and diverse field.

Add a Comment

Your email address will not be published. Required fields are marked *