Approach
We test the task, not just the page
Nobody in your community cares how many rules your site passes. They care whether they can pay the bill, pull the permit, or find out when the board meets. We work backward from that.
How a project runs
1
Scan
We run automated tests across every page type to get a baseline. It's quick, and it's only part of the answer: automated tools detect a subset of WCAG failures, and many success criteria require human judgment or hands-on testing.
2
Test with people
We try to finish your common tasks with a keyboard only, then again with a screen reader. When the stakes are high, we bring in people who use those tools every day of their lives.
3
Rank by what actually blocks people
We sort problems by how badly they stop someone, not by how many times a rule trips. One broken payment form beats a thousand missing alt-text warnings on decorative images.
4
Fix it in the code
We fix things in the page template so the repair holds everywhere, not just on the one page someone complained about. You get working code and a short note on what changed and why.
5
Write it down and keep watching
We write your accessibility statement, date it, and record the testing behind it. Then we keep an eye out as your staff go back to posting agendas, minutes, and PDFs.
What we won't do
- We won't bolt an accessibility widget onto your site and call it done.
- We won't try to sell you a new website platform.
- We won't hand your one-person IT shop a dashboard with 1,400 issues on it and call that a deliverable.