Accessibility that opens the door to your whole audience
About one in four adults in the United States lives with a disability. If your site fights them, you are not reaching a slice of your market, you are turning it away. We audit, we fix, and we build to WCAG 2.2 AA and Section 508 from the first wireframe.
Why this is worth doing
Not because someone might come after you. Because the people you are shutting out are customers, patients, donors, residents, and students.
An inaccessible site quietly filters your audience. The person using a screen reader gives up on your booking form. The person with low vision cannot read your light gray phone number. The person with a hand tremor cannot hit a 14 pixel link. None of them contact you to complain. They just leave.
Accessible sites are also better sites for everyone. Clear headings, real labels, honest contrast, and keyboard support make a page easier to use on a cracked phone in bright sun, and easier for search engines and AI assistants to understand. The work pays for itself in more than one place.
See how structure helps search and AI visibility →What we build to
- WCAG 2.2 AA as the working standard on every build
- Section 508 for government and agency projects
- Hand testing with a keyboard and a screen reader, not just an automated scan
- Real contrast math on every color pair, including hover and disabled states
- Focus that is always visible and never hidden behind a sticky header
- Touch targets sized for real hands, not for a mouse pointer
What we actually do
Two ways in. Fix what you have, or build it right from the start.
Accessibility audit
A page by page review with a keyboard, a screen reader, and contrast tooling. You get a prioritized list of what is broken, where, and what it takes to fix.
Accessibility audit: see how it worksRemediation
We do the fixing, on sites we built and sites we did not. Markup, focus order, labels, contrast, components, and templates, corrected in the site itself.
Remediation: see how it worksAccessible builds
New sites designed to WCAG 2.2 AA from the wireframe. It is far cheaper to build it in than to bolt it on later.
Accessible builds: see how it worksDocument accessibility
PDFs, agendas, and reports are where public sector sites usually fail. We tag, structure, and correct the documents people actually need.
Document accessibility: see how it worksTeam guidance
A short working session so the people adding content week to week know how to write alt text, structure headings, and not undo the work.
Team guidance: see how it worksOngoing checks
Accessibility drifts every time content is added. Our care plans keep it checked instead of letting it quietly rot.
Ongoing checks: see how it worksWe do not use overlay widgets
You have probably seen the accessibility widget: a little floating icon that promises to make a site compliant with one line of JavaScript. We do not install them, and we do not recommend them.
An overlay sits on top of the problem. It cannot fix a heading structure that was never written, a form field with no label, or a custom component that does not tell a screen reader what it is. Many screen reader users actively turn them off, because the overlay fights the tools they already know how to use.
We fix the site. It costs more up front and it is the only thing that actually works.
Straight answers on scope
- We do audits and remediation on sites we did not build
- We work on government and Section 508 projects
- Available as a one time project or as ongoing work
- We do not produce VPATs or accessibility statements
- We do not install overlay widgets
How a review runs
We agree on scope
Which templates, which pages, and which documents. On most sites a representative set of templates covers the majority of the problems.
We test by hand
Keyboard only, screen reader, zoom to 200 percent, and contrast checks on every state. Automated scanning catches maybe a third of real issues, so it is the start and not the finish.
You get a plain list
Every finding written so a non-developer can understand it: what is wrong, who it affects, where it happens, and what fixing it involves.
We fix it, or your team does
Most clients have us do the work. If you have an in-house developer, the report is written so they can act on it without us.
We retest
A fix that was never verified is not a fix. We check the same paths again and confirm the behavior changed.
Common questions
That depends on what kind of organization you are, and it is a question for your counsel rather than for us. Federal agencies and their contractors work under Section 508. State and local government entities are covered by the ADA Title II web rule. Private businesses sit in a less settled area that has been shaped mostly by case law.
We would rather you do this because the audience is worth having. The compliance question usually answers itself once the site is genuinely usable.
We can, and it will miss most of what matters. Automated tools reliably catch contrast failures, missing alt attributes, and some markup problems. They cannot tell you whether your alt text is meaningful, whether your focus order makes sense, whether a custom dropdown announces itself correctly, or whether a screen reader user can actually complete your form.
Every audit we do includes hand testing for that reason.
No. We do the audit and the remediation work, and we will document what we found and what we changed. Producing a formal VPAT or a published accessibility statement is not something we offer, so if your procurement process requires one you will want a separate vendor for that piece.
More than people expect. Contrast, labels, headings, alt text, focus indicators, and link text are usually fixable in place. Where it gets harder is a theme or a page builder pattern that generates bad markup on every page, or a third party widget you do not control.
After an audit we will tell you plainly whether remediation or a rebuild is the better use of your money. Sometimes the honest answer is a new site.
Neither, in most cases. Almost all of it is markup, contrast, and behavior. Where it does change the look it is usually a color that was too light to read or a focus outline that was hidden on purpose, and those changes tend to make the design stronger rather than weaker.
Find out where your site stands
Send us the URL and we will tell you what we see, in plain language, before you spend anything. If the honest answer is that you are in decent shape, we will say that too.