01 · Overview

The short version

Federal rules under ADA Title II require government web content to meet WCAG 2.1 AA. In Columbus, the people actually publishing that content are non-technical staff and outside vendors who were never given a way to know whether their work complies. Every publish decision was a guess.

My capstone treats that gap as a design problem rather than a technical one. The deliverable is a three-part answer: a six-stage decision framework, a live calculator called the Accessibility Compliance Quick Check that walks an editor through the framework in about three minutes, and a measurement standard so the city can eventually know whether any of it worked.

The research produced four findings that reshaped the tool, and the most important one had nothing to do with accessibility. It was about what people do with ambiguity.

02 · The Problem

I was the compliance process

The email that started this project was not unusual, which is exactly the point. A department editor forwarded me a PDF and asked, “Can you check this before I post it?” I had answered some version of that message hundreds of times over my years as Citywide Web Administrator. On that particular afternoon it finally registered as a system failure instead of a favor. The city’s accessibility compliance process was a person. It was me, answering emails one at a time, and everything I did not happen to see went out the door unchecked.

The stakes were about to rise. The Department of Justice rule under ADA Title II gives the city an April 2026 deadline: web content and documents must meet WCAG 2.1 AA. That standard is written for people who know what a contrast ratio is. The people publishing city content are administrative assistants, program coordinators, and outside vendors submitting deliverables from firms that have never heard of a tagged PDF.

Two populations, two versions of the same gap. Internal editors make publication decisions every week with no structured way to evaluate what they are publishing. External vendors submit documents with no awareness that accessibility requirements exist, and often no contractual language telling them. Both groups fail the same standard for different reasons, and neither failure is about willingness.

Constraints

This was a real project with real limits, not a portfolio exercise designed in a vacuum. There was no budget and no development team beyond me. Whatever I built had to live on the city’s existing web infrastructure, survive procurement rules I could not change, and work for someone with zero accessibility training under deadline pressure. The constraint that mattered most was cognitive, not technical: if the tool required expertise to use, it would fail the exact people it existed for.

03 · Research

Eight sessions, six patterns

I ran eight semi-structured research sessions: six with internal city roles across five departments, two with external vendor roles. Each session combined interview questions with a think-aloud walkthrough of a real publish-or-submit decision. I wanted to watch the moment of decision, not just hear it described afterward, because what people report and what people do under deadline pressure are rarely the same thing.

Six distinct behavior patterns emerged, and they mattered more than any demographic split. The pattern predicts what a person does when the tool gives them an answer they do not like, which turned out to be the design problem underneath the design problem.

What existing tools miss

I evaluated the automated checkers most organizations reach for, WAVE and axe among them, along with government checklist resources. They share a shape: they diagnose, in expert vocabulary, and then stop. An automated scan can tell a developer that a contrast ratio fails. It cannot tell Jasmine whether she is allowed to publish the flyer, who to call if she is not, or what happens to the record of that decision. The gap in the market is not detection. It is the decision layer between detection and a non-expert who has to act in the next ten minutes. That gap is where this project lives.

04 · What I Found

Four findings that rebuilt the tool

That explanation landed.

Vendor session, the moment one sentence outperformed years of training

05 · The Framework

Six stages, three outcomes, no dead ends

The framework is a decision sequence, not a checklist. Every stage exists to answer a question the research surfaced, and every outcome connects to a specific next action, because a status label with no pathway is exactly the failure the research documented.

1. Intake

   The user identifies the content type and declares the context: internal publication or external vendor submission. Routing starts here, because a Revit-exported PDF and a web page are different problems wearing the same deadline.

2. Check Sequence

   Six structured questions in plain language covering tagging, reading order, alt text, color contrast, form labels, and captions. “I’m not sure” is an accepted answer and raises a confidence flag instead of forcing a guess.

3. Outcome Logic

   PASS when every check is satisfied. CONDITIONAL when a non-critical check fails but remediation fits the deadline. FAIL when a critical check fails or the fix cannot happen in time.

4. Escalation Routing

   FAIL and CONDITIONAL results produce document-type-aware guidance and a named escalation contact with an expected response time. “Contact the appropriate department” is where compliance goes to die, so no result ever says that.

5. Exception Pathway

   When a good-faith effort still cannot reach compliance by the deadline, the situation gets documented and reviewed instead of hidden. A timestamped exception record exists whether the request is granted or denied.

6. Documentation

   Smartsheet captures the result, content type, user, timestamp, and exception status automatically at the point of decision. There is no separate logging step to skip.

The calculator, annotated

Below is the result screen an editor sees at the end of the sequence, with the design decisions that came directly out of research marked alongside it.

07 · Measuring Success

A standard to measure against

The project delivers a working calculator, a framework a committee member can interrogate, and an evaluation standard. These four targets are not measured within the capstone; that requires a longitudinal study. But deploying the calculator without a measurement plan would mean having no way to know whether it worked, so the standard is part of the deliverable.

Targets defined by research, not results achieved. Measured at 90 days post-deployment.

09 · What’s Next

The unfinished half

The diagnostic half of this system works. The treatment half is where the next year of work lives, and I would rather name that honestly than pad the outcomes section.

First, the remediation loop. The post-result gap is documented but not closed; the next version needs guidance deep enough that a CONDITIONAL owner can actually complete the fix without leaving the tool. Second, the vendor problem class. Priya N.’s Revit exports represent a category where good faith meets a tooling wall, and no calculator solves that. It needs procurement language, source-file requirements, and probably a conversation with the software vendors themselves. Third, measurement. The four targets exist so that ninety days after deployment, someone can pull the Smartsheet data and say whether this worked, in numbers, to a committee.

This started because I was tired of being the compliance process. If it ends with a system that makes the honest decision the easy one, the project did its job. The lessons are already in my professional work either way: I write escalation contacts into everything now, I distrust any workflow step that depends on someone’s initiative, and I have never looked at an ambiguous status label the same way again.