SimpleSense
SimpleSense met teams where they already worked. Accessibility testing usually means logging into one more tool or waiting weeks on a consultant’s report. SimpleSense delivered through a GitHub repo instead, a familiar place for the people who fix the issues.
Requests were unlimited, managed in a queue, and available at a flat monthly price. I designed the whole service, sign-up to retest, having been on both sides of an audit.
The point was to let teams test as often as they ship and learn from the fixes, rather than route accessibility through a separate track. For the teams who used it, that held up.
But I closed SimpleSense in 2025. I do accessibility everyday. I didn’t want to do it every night, too.
How the service ran
Three parties, four stages: The client out front, GitHub as the system of record, SimpleSense backstage. Left to right: sign up, request, audit and deliver, retest. The client subscribes, then opens and ranks an issue, answers in the thread, and reopens once they fix it. GitHub holds the repo and board, moves the issue to the backlog, stores findings in /audits, and carries the retest. SimpleSense provisions and onboards, pulls the top item, tests and documents, then verifies the fix.
How a request moved
A request lived in a dedicated repo from start to finish. It began in a client-ranked backlog, became the one active in-progress request, then done once the audit was committed to /audits, then archived when retired. If it needed more information it detoured to blocked and resumed when the client clarified. SimpleSense pulled the top item and committed the findings; the client shipped a fix and opened a new request for a retest.
One request, start to finish
The whole thing was asynchronous across the client, GitHub, and SimpleSense. No one waited on a meeting. The client opened a request with scope and breakpoints. It was ranked in the backlog. SimpleSense pulled it, tested by hand and with automated tools, committed the findings to /audits, and flagged it ready for review. The client implemented the fix and opened a retest. Every exchange landed in the issue thread and repo. Meetings happened only when they helped.
Everything in one repo
Each client got one private repo they owned. Intake was structured through issue templates: audit request, design review, question. A project board moved work through backlog, in progress, blocked, and done. Deliverables were versioned under an /audits folder, organized by component and issues inside them. All communication stayed in issue comment threads. No email, no separate dashboard.
Anatomy of a finding
Each issue/defect was one structured markdown file inside the component directory. The file carried a bug summary with the success criterion (e.g. 1.3.1 Info and Relationships), its conformance level (AA), a severity rating, and the plain-language impact on screen-reader users. Then reproduction details: the element, its CSS or JS selector, and the steps. Then a solution: a plain-language fix with correct-versus-incorrect code examples. It also had links to W3C techniques, WebAIM, and the Understanding docs. One reproducible file per failure, not a line in a scanner report.
Where it sat
Two axes: automated to expert, and one-off to continuous. Automated scanners and monitoring (axe, WAVE, Lighthouse) and overlay widgets sat low and one-off. Audit consultancies, freelancers, and in-house hires sat higher for expertise. SimpleSense sat top-right: a productized subscription, continuous and expert, rather than a salaried hire.
The model
Retention funded the cycle. A flat monthly fee with an unlimited backlog meant one active request at a time. That kept the work predictable and the queue batchable, so turnaround stayed fast (about 48 hours for small requests). Low churn compounded back into retention.