Project Overview

CivicActions - OpenACR

Section 508 requires that the federal government procure, create, use, and maintain information communications technology that is accessible to people with disabilities, regardless of whether or not they work for the federal government.

Currently, accessibility is assessed during procurement using outdated Microsoft Word Conformance Templates and PDFs, leading to an inefficient process. Different agencies use different methods, resulting in inconsistent accessibility evaluations. The absence of a standardized, machine-readable format complicates comparisons for procurement officers, slowing the process and increasing the risk of non-compliance.

OpenACR aims to eliminate these issues with:

• Automation: Streamlines the creation and maintenance of ACRs.
• Comparison Tool: Enables procurement officers to easily compare the accessibility of different products.
• Central Repository: Prevents duplication of effort across agencies by providing access to previously completed ACRs.

Impact

Update: In July 2024, the GSA released OpenACR for full adoption and it won a Gaady (Global Accessibility Awareness Day Award). 

Based on the design and development work, the General Services Administration (GSA) decided to:

• Integrate OpenACR more fully into the Section 508 and GSA websites.
• Develop the comparison tool I had begun researching and prototyping before we hit our budget limit.

Role

UX Designer
UX Researcher

Team

Back-end Developer
Back-end Developer
Product Manager

Content Designer*
Front-end Developer*

Deliverables

Competitive Analysis
Service Design Map
Visual Mocks
Wireframes

* The content designer and front-end developer joined the team temporarily while in between projects for 2 to 3 weeks. When they weren't on the project, I did content design and front-end.

Insights

How can we revolutionize federal procurement and persuade both procurement officers and vendors to embrace a new format?

Discussions with procurement officers in certification training, an in-depth interview with an experienced federal procurement officer, and conversations with accessibility stakeholders, revealed: 

Variation and Ambiguity
There is a lot of variability in the procurement process across different agencies and individual offices. 

Design for Collaboration
There are several points where vendors collaborate with internal departments or external accessibility experts. 

Education
We overestimated procurement officers' knowledge of accessibility and needed to educate them to ensure adoption.

Design

Final Design

When I started the project, an OpenACR website and an OpenACR web app tool existed. Content was split between the two, but both could be improved:

• Information was repeated on the web app and the website. Having similar information in two places made it difficult to maintain, update and stay in sync.
• Some information on the web app was better suited for the website's audience or vice versa.

I collaborated with a content designer to change the information architecture and provide clear paths for users. We also added a glossary and edited the content to be plain language, split into sections, and sequenced to not overwhelm the reader.

Before and after. The existing format for a Voluntary Product Accessibility Template (VPAT®) (background) compared with the new OpenACR format (foreground).

Define and Ideate

Key Solutions

Understand the variation and ambiguity. Procurement varies widely across agencies and offices, complicating our efforts to design a user flow that would work for most procurement officers and to communicate OpenACR’s benefits.

To address these issues, I created a service map and stakeholder map to help the team identify opportunities and enable new team members to quickly understand the complex process.

Design for collaboration. The service map showed multiple points where vendors collaborate with internal teams or external experts, and procurement officers collaborate with contracting officers at various stages.

Since OpenACR stores information locally, complicating collaboration, we included instructions on loading files for collaborators when creating the zip file.

Focus on education by role. We provided all necessary accessibility compliance information on the website and web app, instead of assuming procurement officers knew it. Collaborating with a content designer, I conducted a content audit and organized the information into general background and role-specific details. We also added a glossary to ensure the content was easy to read.

Outcome

Learnings

Before this project, my experience with accessibility implementation was limited. At Formstack, I led the design effort for WCAG compliance but mainly worked from third-party reports. For OpenACR, I interacted with accessibility experts weekly, providing a crash course in accessibility best practices.

This was my first work-related open-source project, and receiving continuous feedback from the accessibility community was helpful and allowed quck iterations.
 

Outcome

Metrics

We simplified the language, removed unfamiliar acronyms, and implemented clearly defined role-based user flows on the OpenACR website and web tool to make it more user-friendly. Although federal adoption isn't mandatory yet, we've received positive feedback from the US Access Board, accessibility experts, and advocacy groups who have used the tool.

Outcome

Success

The project was going so well that the client has decided to expand the project to incorporate more parts of Section508.gov and to include the optional comparison tool. 

In July 2024, OpenACR was released for use across the federal government and in November 2024 OpenACR was awarded an accessibility award.