Reducing Accessibility Uncertainty
Federal rules gave the City of Columbus a deadline for accessible web content. Nobody gave the people publishing that content a way to know whether their work complies. I designed the decision framework they were missing.
CONDITIONAL
FAIL
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.
The reframe that shaped everything: this is not an expertise gap that training can close. It is a decision infrastructure gap. People were not failing to learn accessibility. They were being asked to make compliance decisions with no decision-making structure at all.
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.
Mark C.
Deputy Director, Public Service
Knows the requirements exist. Structures his workflow so the compliance question never formally reaches him. Ambiguity is his exit.
Jasmine W.
Administrative Assistant, Parks & Recreation
Publishes constantly, wants to do it right, and reads WCAG language as a foreign language. Freezes rather than guesses, then publishes anyway because the event is Saturday.
Brian K.
IT Web Developer, Technology
Has the skills and assumes compliance is someone else’s assignment. Accessibility work reaches him only when it arrives as a ticket, and it almost never does.
Marcus J.
Program Coordinator, Development
Same freeze pattern as Jasmine with a different trigger: volume. Dozens of documents a month, each one a small unanswerable question.
Denise O.
Training Coordinator, Human Resources
Will execute any process the city hands her, precisely. The problem is that no process existed to follow. She was the easiest user to design for and the clearest proof of the gap.
Karen M.
Compliance Lead, Technology
Trusts nothing that self-reports. Her challenge, “what stops someone from just clicking yes,” became the validity problem I carried through the rest of the project.
Marcus D.
Project Manager, construction firm
Opened the session treating accessibility as scope creep someone was trying to bill him for. One sentence of legal context changed his posture entirely. That moment became a finding.
Priya N.
Document Lead, architecture firm
Wants to comply and cannot. Her firm’s Revit exports produce PDFs with broken reading order that she has no tooling to fix. Good faith with no pathway is still a FAIL.
A note on method. These eight sessions were conducted as structured, persona-based research sessions built from composite profiles of the editors and vendors I work with in my role, not as interviews with live human subjects. The behavior patterns are drawn from years of direct operational experience; the named participants are research constructs that let me study those patterns systematically. I am flagging this plainly because a case study about compliance should not blur its own methodology.
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
The CONDITIONAL problem
I designed three outcomes and assumed FAIL was the dangerous one. The research broke that assumption. A FAIL is clear: stop, fix, escalate. A CONDITIONAL result, something is wrong but fixable, turned out to be where compliance quietly dies. Participants treated it as permission with an asterisk, and the asterisk never got resolved. Ambiguous outcomes accumulate; unambiguous ones get handled.
The pattern maps directly onto what Gollwitzer’s implementation intention research has shown for decades: intentions without a specified when, where, and who mostly do not convert into action. So the tool now refuses to leave a CONDITIONAL open-ended. It requires a named owner and a deadline before the result can close.
The legal framing insight
Marcus D. spent the first part of his session pushing back on accessibility as an invented requirement. Then the walkthrough surfaced one sentence of context: this is a federal legal obligation under ADA Title II, with a deadline, and the submission record protects his firm as much as the city. His posture flipped from resistant to cooperative in the space of that sentence. Years of training materials had never moved editors the way one line of well-timed context moved a skeptical vendor.
That explanation landed.
Vendor session, the moment one sentence outperformed years of training
The guessing problem
Karen M. was right. The calculator asks people to self-report, and an uncertain user who guesses “yes” on a question they do not understand produces a result screen that looks exactly as authoritative as an accurate one. Watching sessions made this concrete: people guessed to keep moving, not to cheat. The fix could not be a lecture. The tool now offers “I’m not sure” as a first-class answer, flags the result’s confidence accordingly, and routes genuinely uncertain checks to a human instead of laundering a guess into a verdict.
The post-result gap
The diagnostic function worked. People reached a result and believed it. Then the sessions kept going and I watched the tool’s real weakness: the moment after the result. Knowing a document failed is not the same as knowing what to do at 4:45 on a Friday with a Monday deadline. The treatment function, remediation guidance, escalation, exception handling, is where most of the later design effort went, and honestly, where the work remains unfinished.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
All six checks satisfied. Publish or submit, with the decision logged automatically.
Clear, and rare on first attempts
Fixable issues within the deadline. Cannot close without a named owner and a due date, by design.
Where compliance quietly dies
A critical check failed or the fix cannot happen in time. Escalation contact and exception pathway provided.
Clear, and clarity gets handled
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.
- 1 The result explains itself in plain language and states exactly what closing it requires. No status label without a pathway.
- 2 “I’m not sure” is an honest answer, not a failure. It flags the result’s confidence instead of laundering a guess into a verdict. This is the response to the guessing problem.
- 3 A CONDITIONAL cannot close without an owner and a deadline. This is the implementation intention finding built directly into the interface.
- 4 Escalation is a named contact with a response time, never a generic directive to find the appropriate department.
- 5 Documentation happens at the point of decision. Any step that depends on an editor’s initiative under deadline pressure gets skipped by everyone, every time.
06 · Iterations
One pivot, two inflection points
-
Early scope
The pivot away from one platform
The original framing centered on a single department’s engagement platform. Advisor feedback made it clear that angle was too platform-specific to transfer anywhere else. Pivoting to a citywide decision framework was uncomfortable in the moment and right in retrospect. It is the reason this project matters beyond one department.
-
Mid-research
The CONDITIONAL realization
Session data broke the symmetry between the three outcomes and changed the tool’s architecture. CONDITIONAL now requires a deadline and an owner before it closes, rather than leaving those elements implied and unenforced.
-
Scope expansion
The vendor expansion
Adding external vendors complicated an already complex project and produced the perspective internal research could not: someone with no institutional context, no training, no organizational backup, and a submission deadline. The exception pathway and document-type-aware guidance both trace back to this expansion.
What testing changed in the calculator itself
The walkthroughs pushed one version change after another. The moment I keep returning to is a four-minute pause. An editor reached a question, stopped, and sat with it. She was not confused by the interface. She was encountering a decision she had been avoiding for months, and the tool had made the avoidance impossible to continue. That pause was the whole problem made visible, and it convinced me the tool’s job is to surface decisions, not just score documents.
Before (v1)
Technical language: “contrast ratio,” “alt attribute,” “tag structure.”
Yes or no answers only, so uncertainty became a silent guess.
Result screen ended with a status label and nothing else.
After (v2)
Plain questions: “Is this image purely decorative?” “Can you read this text easily?”
“I’m not sure” accepted, flagged, and routed to a human reviewer.
Every non-PASS result carries next steps, a named contact, and required closure fields.
Replace with a walkthrough screenshot or session artifact
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.
Reflection
About the problem. Accessibility compliance in government is not an expertise gap. It is a decision infrastructure gap. People need structure more than they need training, and a well-timed piece of context can outperform both.
About design. A tool that requires expertise to use defeats its own purpose. The harder I pushed toward plain language, the more useful the calculator became. And the most important design work happened somewhere I did not initially think of as design at all: the moment after the result.
About research. Following an inconvenient thread is worth the disruption. The vendor expansion produced the findings that matter most at the edges of the system, where city staff hand off to contractors and contractors hand work back.
What I would do differently. Start with the vendors, not end with them. Design the post-result experience before the checks, since that is where the tool succeeds or fails. And instrument the calculator from the first prototype, because a project about closing measurement gaps should not have opened one of its own.
The city made a commitment to accessibility. The people publishing its content deserved a way to keep it.
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.
