C3 accessibility audit

Overview

C3 is customer-facing shareholder accounting software built by Integrated Software Solutions, Inc. As a software engineering intern with a developing interest in accessibility, I proposed and led an accessibility and inclusive design audit of the product, evaluating it against WCAG 2.1 AA standards and delivering a structured report of findings, recommendations, and annotated examples.

Goal

Identify content and design barriers that could exclude users with disabilities and deliver actionable recommendations.

Process

Evaluation

I evaluated C3 against WCAG 2.1 AA standards across four dimensions: assistive technology compatibility, keyboard navigability, language clarity, and semantic structure. I divided issues into general problems (page structure, heading structure, forms, wording, timing) and component-level problems (buttons, images, submenu navigation).

The audit was designed as an educational tool. Rather than cataloguing every instance of every issue, I documented patterns — what the problem was, why it mattered, and how to fix it — so the team could apply fixes systematically.

Findings

Some issues had clear, immediate solutions. For example, buttons throughout C3 were implemented as <input type="image">, styled to look like buttons but identified in the markup as images. They had no accessible label, weren’t always keyboard operable, and weren’t announced correctly by screen readers. The fix was straightforward — replace them with native <button> elements.

Other issues required more lift. C3 lacked semantic HTML markup — it used <table> elements for visual presentation and used <span> elements as headings, form labels, etc. Fixing these violations properly would mean rebuilding the page structure from scratch with semantic HTML — which would be a long-term redesign effort. I documented both the long-term recommendations and stop-gap solutions so the team had somewhere to start.

Results

The audit produced three deliverables: the public report with annotated findings and proposed solutions, an internal accessibility QA checklist for future releases, and a workshop to review the findings and demonstrate how assistive technologies actually interpret and navigate the software. Following implementation of the recommended short-term fixes, screen reader navigation improved across high-traffic user journeys.

Challenges

The central tension in any accessibility evaluation is the gap between what should be fixed and what is realistic to fix given constraints. C3 had issues that couldn’t be addressed without redesigning the UI and refactoring the underlying code, and that work wasn’t scoped alongside other projects in flight.

I had to deliver fixes that would work well enough in the short term, document the long-term work clearly enough that it could be picked up later, and give the team a framework to prevent the same issues from accumulating in future releases.