Improving accessibility in a pre-CSS product

Problem

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.

Key challenges

C3 was built before CSS was standard practice. Because it used HTML for its layout and visual styling, accessibility problems were baked into the document structure.

Process

Evaluating against WCAG

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).

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.

Triaging issues

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 solution 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

I delivered a public report with annotated findings and proposed solutions and an internal accessibility QA checklist for future releases, and led a workshop to review the findings and demonstrate how assistive technologies actually interpret and navigate the software. Screen reader navigation improved across high-traffic user journeys following implementation of the recommended short-term fixes.

Reflections & learnings

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 balance what should ideally be fixed against what was realistic to fix given constraints, so I delivered fixes that would work well enough in the short term, documented the long-term work clearly enough that it could be picked up later, and gave the team a framework to prevent the same issues from accumulating in future releases.